How to Give Claude Persistent Memory (MCP Setup, 2026)

By default, Claude starts fresh every session. No memory of your project conventions, past decisions, team context, or what you debugged last week. This guide shows you how to fix that — using Dakera's MCP server to give Claude (Desktop, Code, Cursor, or Windsurf) production-grade persistent memory that runs entirely on your own infrastructure.

Why Claude forgets — and what that costs you

Claude's context window gives it excellent within-session recall. But the moment you close a conversation, everything is gone. The next session starts blank. This creates a real productivity tax:

• Re-explaining project context at the start of every session
• Re-discovering architectural decisions already made
• Repeating preferences (Tailwind, not vanilla CSS; pnpm, not npm; strict ESLint)
• Losing debugging breakthroughs that took hours to reach
• Starting from zero when switching between Claude Desktop, Claude Code, and Cursor

Claude's built-in CLAUDE.md and auto-memory features help at the project level, but they're designed for static instructions — not for accumulating knowledge across hundreds of sessions, across multiple projects, or across a team. That's what a dedicated memory server handles.

Dakera vs. cloud-only alternatives

Several services offer Claude memory through MCP. Here's how the approaches compare:

Dakera's 88.2% accuracy on the LoCoMo benchmark — a 30-turn conversation recall test covering temporal inference, entity tracking, and cross-session knowledge — means it reliably surfaces the right memory at the right time. Simpler approaches based on keyword search miss semantically related context.

Step-by-step: Give Claude persistent memory in 10 minutes

docker run -d \
  --name dakera \
  --restart unless-stopped \
  -p 3000:3000 \
  -e DAKERA_PORT=3000 \
  -e DAKERA_ROOT_API_KEY=my-dev-key \
  -e DAKERA_STORAGE=filesystem \
  -e DAKERA_STORAGE_PATH=/data \
  -v dakera-data:/data \
  ghcr.io/dakera-ai/dakera:latest

curl http://localhost:3000/health
# {"status":"healthy","version":"..."}

# Install via npm (recommended)
npm install -g @dakera-ai/dakera-mcp

# Or install via Cargo
cargo install dakera-mcp

# Or via Homebrew
brew install dakera-ai/tap/dakera-mcp

# Verify
dakera-mcp --version

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "env": {
        "DAKERA_API_URL": "http://localhost:3000",
        "DAKERA_API_KEY": "my-dev-key"
      }
    }
  }
}

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "env": {
        "DAKERA_API_URL": "http://localhost:3000",
        "DAKERA_API_KEY": "my-dev-key"
      }
    }
  }
}

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "env": {
        "DAKERA_API_URL": "http://localhost:3000",
        "DAKERA_API_KEY": "my-dev-key"
      }
    }
  }
}

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "env": {
        "DAKERA_API_URL": "http://localhost:3000",
        "DAKERA_API_KEY": "my-dev-key"
      }
    }
  }
}

What Claude can do with persistent memory

Once connected, Claude's behavior changes in ways that compound over time. A few examples from real workflows:

Project context that survives restarts

Claude learns your stack — Next.js with app router, Postgres via Drizzle, deployment on Fly.io — and starts with that context every session. No re-briefing. No copy-pasting your README.

Architectural decisions that stick

"We decided to use Edge Runtime for API routes because of latency constraints from Southeast Asia users." A week later: "What was the reasoning behind Edge Runtime?" — Claude knows, because it stored the decision when you discussed it.

Cross-session debugging continuity

That auth token expiry bug you spent three hours diagnosing? The root cause, the workaround, and the permanent fix are stored with high importance. The next time a related issue appears, Claude retrieves that context automatically.

Team memory via shared Dakera instance

Point multiple developers at the same Dakera server (on your internal network or a cloud VM). Your team accumulates a shared knowledge graph — API conventions, deployment runbooks, past incident learnings — that any agent can query.

Understanding the 14 core memory tools

In the default core profile, Claude gets 14 tools covering everything most workflows need. The key ones:

• dakera_store — Persist a memory with content, importance score (0.0–1.0), tags, and optional metadata. High-importance memories decay slowly; low-importance ones fade naturally.
• dakera_recall — Semantic recall by query. Returns the most relevant memories ranked by a composite of vector similarity, importance, and recency — not just keyword match.
• dakera_search — Filtered search across memories with metadata constraints (tags, date range, agent ID).
• dakera_forget — Remove specific memories when they're outdated or incorrect.
• dakera_session_start / dakera_session_end — Group related memories under a session for structured retrieval.
• dakera_knowledge_graph — Build a graph of entities and relationships extracted from stored memories.

For entity extraction, graph traversal, and advanced search, use the power or all profile via DAKERA_MCP_PROFILE=power in your MCP config. See the MCP server docs for full profile details.

Privacy: why self-hosted matters

When you store project context, architectural decisions, or debugging notes in a cloud memory service, that data leaves your infrastructure. For professional developers working on proprietary codebases, that's a meaningful risk.

Dakera is open-core and self-hosted by default. The memory server runs on your machine or your team's internal infrastructure. Memory content is never sent to Dakera's servers; the engine sends product telemetry by default, which one setting turns off (details). The MCP server, SDKs and deployment files are public on GitHub.

Troubleshooting common issues

The memory tools don't appear in Claude. Restart Claude after editing the MCP config. Verify the dakera-mcp binary is in your PATH: which dakera-mcp. Check that the Dakera server is running: curl http://localhost:3000/health.

Claude stores but doesn't recall. Semantic recall works best when the query is conceptually related to the stored content, not necessarily keyword-matching. Try querying with a broader concept. Also check that the agent_id matches — memories are namespaced by agent.

Memories don't persist between Docker restarts. Make sure you're using -v dakera-data:/data in your Docker command. Without the volume mount, data is stored in the container's ephemeral filesystem and lost on restart.

Port 3000 is already in use. Change the host port to 3301: -p 3301:3000. Update the DAKERA_API_URL in your MCP config to match: http://localhost:3301.