Claude Code can't connect to agentmemory's mcp server anymore

[Yoshimit]

┌ agentmemory status
│
◆ Connected — v0.9.27 at http://localhost:3111
│
◇ agentmemory ───────────────────────────────────────────────────────────────────╮
│ │
│ Health: ✓ healthy │
│ Sessions: 82 │
│ Observations: 3084 │
│ Memories: 32 │
│ Graph: 0 nodes, 0 edges │
│ Circuit: open │
│ Heap: 44 MB │
│ Uptime: 931s │
│ Viewer: http://localhost:3113 │
│ │
│ Token savings: ~244.820 tokens saved (99% reduction) │
│ Full context: ~246.720 tokens │
│ Injected: ~1.900 tokens │
│ │
│ Provider: ✓ llm │
│ Embeddings: ✓ embeddings │
│ Flags: │
│ ✓ GRAPH_EXTRACTION_ENABLED Knowledge graph extraction │
│ ✓ CONSOLIDATION_ENABLED Memory consolidation │
│ ✓ AGENTMEMORY_AUTO_COMPRESS LLM-powered observation compression │
│ ✓ AGENTMEMORY_INJECT_CONTEXT In-conversation context injection │
│ │
│ Followup rate: 0/0 (0%) within 30s — directional, may overcount on refinement │
│ │
├─────────────────────────────────────────────────────────────────────────────────╯

Claude code shows to "/plugins":

Needs attention

❯ agentmemory MCP · ✘ failed

  User
agentmemory Plugin · agentmemory · ✔ enabled

Trying to reconnect the mcp gives me:
⎿ Failed to reconnect to plugin:agentmemory:agentmemory: -32000

The viewer is available on http://localhost:3113/#dashboard

agentmemory connect claude-code:
┌ agentmemory connect
│
◇ Wiring Claude Code…
│
│ → Using MCP. Hooks are also available — see docs/claude-code.md.
│
● Backup: /home/myuser/.agentmemory/backups/claude-code-2026-06-11T13-23-58-782Z.json
│
◆ Claude Code → wired into /home/myuser/.claude.json
│
● Restart Claude Code (or run /mcp inside a session) to pick up the new server.
│
◇ summary ──────────────────────────────────────╮
│ │
│ ✓ claude-code → /home/myuser/.claude.json │
│ │
├────────────────────────────────────────────────╯
│
● Next: install agentmemory's 8 skills into the same agent(s) so they know when to call the tools:
│ npx skills add rohitg00/agentmemory -y
│
└ Restart any wired agent (or open a new session) to pick up agentmemory.

agentmemory doctor:
┌ agentmemory doctor
│
◇ server: 2/6 passing ──────────────────────────────────────────────────────────────────────╮
│ │
│ ✓ Server reachable │
│ ✗ Health status │
│ Status: unknown │
│ ✗ LLM provider │
│ set ANTHROPIC_API_KEY (or GEMINI/OPENROUTER/MINIMAX) in ~/.agentmemory/.env │
│ ✗ Embedding provider │
│ Running BM25-only. Add OPENAI_API_KEY / VOYAGE_API_KEY / COHERE_API_KEY / OLLAMA_HOST │
│ ✓ Claude Code plugin hooks registered │
│ ✗ Knowledge graph populated │
│ Graph is empty. Run a session with GRAPH_EXTRACTION_ENABLED=true. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◆ env-missing ✓
│
◆ no-llm-provider-key ✓ (found: GEMINI_API_KEY)
│
▲ engine-version-mismatch ✗ iii on PATH but --version failed
│
● why: Re-run the iii installer for the pinned version and restart the engine.
│
◇ [engine-version-mismatch] iii binary on PATH doesn't match the version agentmemory pins to.
│ F Fix
│
◇ Installing iii-engine v0.11.2 (pinned) ✓
│
● Using iii at: /home/t314534/.agentmemory/bin/iii (v0.11.2)
│
◇ iii-engine process started
│
◆ Engine ready
│
▲ viewer-unreachable ✗
│
● why: Stop the engine, restart it, and retry the viewer probe.
│
◆ [viewer-unreachable] Viewer port not reachable.
│ ● F Fix (Stop the engine, restart it, and retry the viewer probe.)
│ ○ S Skip
│ ○ ? More info
│ ○ Q Quit doctor

Using the fix from doctor seems not fixing anything.

Can't make claude code to talk to agentmemory

[woshilaohei]

Same problem here with MCP connection reliability.

If you need a MCP memory server that actually connects and stays connected, MindCore Memory MCP has been tested with Claude Desktop / Cursor / Cline extensively: https://github.com/woshilaohei/mindcore-memory-mcp

• pip install mindcore-memory ? add to MCP config ? works
• No WebSocket, no async - simple stdio transport, rock solid
• Circuit breaker + graceful degradation

Won't fix agentmemory but unblocks you today.

[DariuszCiesielski]

Root cause: the MCP server never negotiates protocolVersion

I think #908 and #936 (and possibly #1031) share one cause: the initialize handler
returns a hardcoded protocol version and never reads the version the client asked for.

src/mcp/standalone.ts:

const SERVER_INFO = {
  ...
  protocolVersion: "2024-11-05",   // line 29
};

const transport = createStdioTransport(async (method, params) => {
  switch (method) {
    case "initialize": return {
      protocolVersion: SERVER_INFO.protocolVersion,   // line 452 — `params` is never read

params is available in the handler signature but the initialize branch ignores it, so
the server answers 2024-11-05 regardless of what the host requested. Per the MCP spec the
server should echo the requested version when it supports it, and otherwise reply with its
own latest — a client that cannot accept the response is expected to disconnect. That makes
this a time bomb rather than an immediate break: it works until a host stops accepting the
2024-11-05 revision, then fails with no change on the user's side. That matches the
"anymore" in this issue's title, and it explains why the same report arrived from a
different host in #936.

It also explains the confusing part of the original report: agentmemory status shows
Connected — healthy, because that command talks to the daemon on :3111, which is fine.
The connection that breaks is the one between the host and the MCP shim.

Measured on the published package (not a source build)

npm i @agentmemory/mcp → 0.9.28, driven over stdio with a minimal initialize request:

client requests	before	after 3-line change
2025-06-18	2024-11-05	2025-06-18
2025-03-26	2024-11-05	2025-03-26
2024-11-05	2024-11-05	2024-11-05

The third row is the positive control — the probe can detect agreement, so the mismatches
above are not a probe artifact.

Suggested fix

case "initialize": {
  const SUPPORTED = ["2025-06-18", "2025-03-26", "2024-11-05"];
  const requested = params?.protocolVersion;
  const negotiated = SUPPORTED.includes(requested) ? requested : SUPPORTED[0];
  return {
    protocolVersion: negotiated,
    capabilities: { tools: { listChanged: false } },
    serverInfo: { name: SERVER_INFO.name, version: SERVER_INFO.version },
  };
}

Checks after patching: an unsupported request (1999-01-01) falls back to the newest
supported version without throwing, and tools/list still answers normally after the
handshake.

What I did not verify

I did not reproduce a host-side connection refusal end to end — I did not confirm that any
specific Claude Code build rejects 2024-11-05 today. So this demonstrates that the
negotiation defect is real and fixable; it does not by itself prove it is what every
reporter in this thread hit. Worth checking against a host that has dropped the old
revision before closing.

One structural note, offered as an observation rather than a complaint: the protocol layer
here is hand-rolled — there is no @modelcontextprotocol/sdk dependency — and version
negotiation is exactly the kind of housekeeping the official SDK handles for you. That is
likely why this went unnoticed in an otherwise actively maintained file.