[jeffgage]

Hi, thanks for adebench. I'm running its Hindsight, mem0, cognee and engram adapters unmodified (at 6b23060, Python 3.11, macOS arm64) from a currency benchmark for the Particles memory project. On the way I hit three setup gaps in the MCP-based adapters. None of them changes a result once it's worked around, but each one cost a failed start, and the first two hit anyone who installs fresh today. This PR fixes all three.

1. The mcp requirement wasn't documented. The README says each memory's install is described in its adapter's docstring. engram.py, hindsight.py and aionforge.py import mcp inside the adapter, but none of their docstrings names it. In a fresh venv the first connection raises ModuleNotFoundError: No module named 'mcp'; for engram that shows up only as health() returning False. Each docstring now has a pip install line: mcp>=1.24 for the two HTTP adapters (see 2), and plain mcp for engram, whose stdio client hasn't changed.

2. mcp 2.x removed streamablehttp_client. hindsight.py and aionforge.py imported mcp.client.streamable_http.streamablehttp_client. In mcp 2.3.0 that module exports only streamable_http_client, so an unpinned pip install mcp gives an ImportError on connect. The new function takes headers through an httpx client rather than a headers= argument. It also yields two streams in 2.x, where 1.x yielded three (the third was the session-id getter). Both adapters now:

• build the client with create_mcp_http_client(headers=...), so the bearer still goes on every request;
• enter it on the existing exit stack, so it is closed with the session;
• take the first two streams, which works on either version.

Both names exist from mcp 1.24.0 on, hence the floor.

3. The engram adapter failed on a data directory that didn't exist yet. The docstring asks for a FRESH ENGRAM_DATA_DIR, and EngramAdapter uses that directory as the working directory of both engram mcp (_conn) and the CLI (_cli). A subprocess can't start in a missing directory, so a fresh path made health() return False, and examples/engram_import.py stopped with "Engram does not answer", which doesn't point at the directory. Both paths now call os.makedirs(self.data_dir, exist_ok=True) first. I put it there rather than in __init__ so that building an adapter never creates ~/.engram.

Testing

• python -m pytest -q: 274 passed with mcp 1.30.0 and with 2.3.0.
• Both HTTP adapters' _Mcp connected to a local FastMCP streamable-HTTP server, listed its tools and called one, with mcp 1.24.0, 1.30.0 and 2.3.0. The server saw the Authorization header on every request.
• With a fresh nested ENGRAM_DATA_DIR, EngramAdapter._cli now creates the directory and runs.
• I haven't run a full adebench pass against a live Hindsight or Aionforge on mcp 2.x. On 1.30.0 the engram and Hindsight adapters ran clean end to end for me before this change.

🤖 Generated with Claude Code

[adecubed]

Thanks, Jeff. All three are real, and the write-up made them quick to check. I went through the diff against mcp 1.27.1: both names exist there, the bearer still goes on every request through the client, and create_mcp_http_client’s default timeouts (30 s, 300 s read) match what streamablehttp_client used, so Hindsight’s long sync_retain calls are unaffected. Creating the engram data dir at first use rather than in init is the right place. Merging.

Glad the adapters are useful for the Particles currency benchmark. If you publish numbers from them, a link here would be welcome