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

┌ 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

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.

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.

Navigation Menu

Repository navigation

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

Root cause: the MCP server never negotiates `protocolVersion`

Measured on the published package (not a source build)

Suggested fix

What I did not verify

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Activity

woshilaohei commented on Jun 14, 2026

DariuszCiesielski commented on Aug 15, 2026

Root cause: the MCP server never negotiates protocolVersion

Measured on the published package (not a source build)

Suggested fix

What I did not verify

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Root cause: the MCP server never negotiates `protocolVersion`