MCP Memory Server Setup for Claude, Cursor and Windsurf

By the end of this guide you will have a running Dakera memory server on your machine, connected to your AI coding tools via the Model Context Protocol (MCP). Every conversation you have with Claude Desktop, Claude Code, Cursor, or Windsurf will be able to store and recall persistent memories — project context, decisions, preferences, and facts that survive across sessions.

The entire setup takes under 10 minutes. You will use Docker to run the Dakera server, install a single binary for the MCP bridge, and add a few lines of JSON configuration to each tool.

Prerequisites

Before you begin, make sure you have the following installed on your system:

• Docker — any recent version (20.10+). Verify with docker --version.
• Rust toolchain — needed to install the MCP server binary via Cargo. Install from rustup.rs if you do not have it.
• One or more AI tools — Claude Desktop, Claude Code, Cursor, or Windsurf installed and working.

Step 1: Start the Dakera Server

docker run -d --name dakera -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":"0.12.2", ...}

Understanding the configuration

Here is what each environment variable does:

• DAKERA_PORT — the port the HTTP server listens on inside the container.
• DAKERA_ROOT_API_KEY — the API key required to authenticate requests. All MCP clients will use this key.
• DAKERA_STORAGE — the storage backend. filesystem is the simplest option for local development; Dakera also supports S3-compatible backends for production.
• DAKERA_STORAGE_PATH — the directory inside the container where data is written. The -v flag maps this to a persistent Docker volume.

Step 2: Install the MCP Server Binary

cargo install dakera-mcp

# Verify the installation
which dakera-mcp

What the MCP server exposes

Once connected, the MCP server provides your AI assistant with tools including:

• dakera_store — save a new memory with optional metadata and tags.
• dakera_recall — retrieve relevant memories using hybrid search (vector + BM25).
• dakera_search — search one agent's memories with tag, type and importance filters.
• dakera_forget — remove specific memories when they are no longer relevant.
• dakera_session_start / dakera_session_end — group the memories of one conversation or task.

Your AI assistant decides when to call these tools based on the conversation context. You do not need to manually trigger memory storage — the assistant handles it automatically.

Step 3: Configure Claude Desktop

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

Step 4: Configure Claude Code

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

claude mcp add --scope user dakera \
  -e DAKERA_API_URL=http://localhost:3000 \
  -e DAKERA_API_KEY=my-dev-key \
  -- dakera-mcp

Namespaces for multi-project setups

Dakera isolates memories per agent: every memory tool takes an agent_id, and each agent's memories live in their own namespace (_dakera_agent_{agent_id}). To keep a project separate, use one agent ID per project, for example by calling dakera_store and dakera_recall with agent_id: "my-project", or have the AI assistant include it in tool calls. The MCP config itself only needs the server URL and API key:

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

You can then instruct your AI assistant to always use a project-specific agent ID when storing and recalling memories, keeping each project's context separate.

Step 5: Configure Cursor

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

Step 6: Configure Windsurf

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

Step 6.5: Choose Your Tool Profile (DAKERA_MCP_PROFILE)

Dakera exposes 100+ MCP tools total, but loading all of them wastes context window tokens. The DAKERA_MCP_PROFILE environment variable controls which tools appear in tools/list:

Set via environment variable in your MCP config:

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

Or per request: a client can pass {"profile": "power"} in the tools/list params.

Tip: Start with core. Every profile includes dakera_discover_tools and dakera_load_tools — meta-tools that let your agent browse and load additional tool schemas on demand without switching profiles.

Step 7: Verify the Connection

After configuring your preferred tool and restarting it, verify that the MCP connection is active.

In Claude Desktop

Open a new conversation. You should see a tools icon (hammer) in the input area indicating MCP tools are available. Click it to confirm dakera_store, dakera_recall, and other Dakera tools appear in the list.

Test it by typing:

Remember that my preferred programming language is Rust and I deploy to Hetzner Cloud.

Claude should invoke dakera_store to save this preference. In a new conversation, ask:

What is my preferred programming language?

Claude should invoke dakera_recall and respond with "Rust" based on the stored memory.

In Claude Code

Start a new Claude Code session in a project with the .mcp.json configured. You should see Dakera tools listed when the session initializes. Look for output like:

MCP server "dakera" connected (14 tools available)

In Cursor and Windsurf

Open the AI chat panel and check that MCP tools are listed. The exact UI varies by version, but you should see Dakera-related tools in the tool list or settings panel.

Verify from the command line

You can also confirm the server has stored memories by querying the Dakera API directly:

# Agents your tools have stored memories for, with their memory counts
curl -H "Authorization: Bearer my-dev-key" \
  http://localhost:3000/v1/agents | jq '.[] | {agent_id, memory_count}'

# The memories of one agent
curl -H "Authorization: Bearer my-dev-key" \
  "http://localhost:3000/v1/agents/my-project/memories?limit=5"

This lists the memories stored by your AI tools.

Troubleshooting

MCP tools do not appear after restart

• Check the binary is in PATH: Run which dakera-mcp in your terminal. If it returns nothing, the binary is not in your PATH. Add ~/.cargo/bin to your shell profile.
• Check the config file path: Each tool looks for its MCP config in a specific location. Double-check you are editing the correct file for your OS and tool.
• Check JSON syntax: A missing comma or bracket in the config file will silently fail. Validate your JSON with jq . < config-file.json.

Connection refused errors

• Verify Docker is running: Run docker ps and confirm the dakera container is listed and healthy.
• Check port mapping: Run curl http://localhost:3000/health. If this fails, the container may not have started correctly. Check logs with docker logs dakera.
• Firewall rules: On Linux, ensure your firewall allows localhost connections on port 3000.

Authentication errors (401 Unauthorized)

• API key mismatch: Ensure the DAKERA_API_KEY value in your MCP config matches the DAKERA_ROOT_API_KEY environment variable you passed to the Docker container exactly.
• Trailing whitespace: Some editors add invisible characters. Copy the key value directly from your terminal command to avoid discrepancies.

Memories not being recalled

• Agent ID mismatch: If you used one agent_id when storing memories in one tool but a different one when recalling in another, memories will not appear. Use the same agent ID across all tool calls.
• Empty database: If you just set up the server, it has no memories yet. Store a few facts first, then test recall.
• Container restart: If you ran docker run without the -v dakera-data:/data flag, your memories are lost when the container stops. Re-run with the volume flag to persist data.

Slow startup or compilation

The cargo install dakera-mcp command compiles from source, which can take 2-5 minutes depending on your machine. This is a one-time cost. Subsequent updates are faster due to incremental compilation. If you need a faster path, download the pre-built binary from the releases page.

MCP tool calls fail silently

If the AI assistant appears to not be using memory (not calling dakera_store or dakera_recall even when you expect it to), check these causes:

• Profile too restrictive: The default core profile exposes 14 tools. If your assistant is selecting tools at startup and Dakera's tools are not listed, check that the server is reachable and accepts the key: curl -H "Authorization: Bearer my-dev-key" http://localhost:3000/v1/capabilities should answer 200.
• System prompt overrides: Some AI tool configurations include system prompts that explicitly disable third-party tool use. Check your tool's settings for any such restrictions.
• MCP version mismatch: Ensure your dakera-mcp binary version is compatible with the MCP protocol version your AI tool expects. Upgrade with cargo install dakera-mcp --force to get the latest.

High memory usage on the Dakera container

If the Docker container is consuming more RAM than expected, the primary cause is a large HNSW index. The HNSW index is kept in memory for fast nearest-neighbor search. Use Docker stats to check current consumption:

docker stats dakera --no-stream
# CONTAINER ID   NAME      CPU %   MEM USAGE / LIMIT
# abc123         dakera    0.3%    312MiB / 7.77GiB

# If memory is excessive, check how many memories each agent holds
curl -H "Authorization: Bearer my-dev-key" \
  http://localhost:3000/v1/agents | jq '.[] | {agent_id, memory_count}'

Decay lowers importance but never deletes a memory, so it does not shrink the index. To reduce memory, set a TTL per memory type in the agent's memory policy, batch-forget low-importance memories, and cap a namespace with a quota (max_vectors). See the memory decay documentation for configuration details.

Connecting Multiple MCP Clients Simultaneously

One of the most powerful aspects of this setup is that all your AI tools share the same Dakera backend. A memory stored by Claude Desktop is immediately available to Claude Code, Cursor, or Windsurf — no synchronization required, because they all read from and write to the same server.

How Multiple Clients Work Together

Each MCP client (Claude Desktop, Claude Code, Cursor, Windsurf) runs its own dakera-mcp process that connects to the single Dakera server via HTTP. Multiple client processes can connect simultaneously without conflict — Dakera handles concurrent connections safely:

To enable this, all clients must connect to the same Dakera server with keys that reach the same agents. When the tools store and recall under the same agent_id, memories stored by Claude Code are immediately visible to Cursor and Windsurf without any extra configuration.

Shared Memory Configuration

For a fully unified memory layer across all tools, use identical configuration in each tool's MCP config file:

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

Project-Scoped Shared Memory

For a more organized setup, you can instruct your AI assistants to store and recall memories under a specific agent ID for each project. Both Claude Code and Cursor will then keep memories for that project separate from your other work. Use identical config for all tools, and tell the assistant which agent ID to use:

# .mcp.json in your project root (Claude Code reads this automatically)
{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "env": {
        "DAKERA_API_URL": "http://localhost:3000",
        "DAKERA_API_KEY": "my-dev-key"
      }
    }
  }
}

Now Claude Code and Cursor share the same memory store. Context you store in one tool is immediately available to the other — architecture decisions, naming conventions, past debugging notes, and more.

Team-Wide Shared Memory

For teams where multiple developers should share a common memory base, deploy Dakera to a shared server (instead of localhost) and point all developers' MCP clients at the same URL. Each developer still runs their own dakera-mcp process locally, but they all connect to the shared Dakera server:

# Shared server deployment (team setup)
# Dakera runs on: https://memory.internal.yourcompany.com

# Each developer's MCP config
{
  "mcpServers": {
    "dakera-team": {
      "command": "dakera-mcp",
      "env": {
        "DAKERA_API_URL": "https://memory.internal.yourcompany.com",
        "DAKERA_API_KEY": "team-shared-key"
      }
    }
  }
}

For the self-hosted setup required for a team deployment — including TLS, authentication, and monitoring — see the complete self-hosting guide.

Verifying Cross-Tool Memory Sharing

To confirm two tools are sharing memory, store a fact from one tool and retrieve it from another:

# Step 1: In Claude Desktop, say:
# "Remember that our database uses PostgreSQL 16 on RDS in us-east-1"
# (Claude will call dakera_store with your project's agent_id, e.g. "my-project")

# Step 2: Verify the memory exists via the API
curl -H "Authorization: Bearer my-dev-key" \
  -X POST http://localhost:3000/v1/memory/recall \
  -H "Content-Type: application/json" \
  -d '{"agent_id": "my-project", "query": "database PostgreSQL", "top_k": 3}' | jq '.memories[].content'

# Step 3: In Cursor, ask:
# "What database are we using?"
# Cursor's dakera-mcp will call dakera_recall and return the stored fact

Advanced Configuration

Custom Embedding Models

By default, Dakera uses the bge-large embedding model (1024 dimensions) running locally via ONNX; it ships in the image. You can switch to a different model for different accuracy/speed trade-offs. Dakera is configured by environment variables only, so set DAKERA_MODEL:

# On-device ONNX models (DAKERA_MODEL) and their embedding size:
# bge-large              1024-dim (default)
# bge-m3                 1024-dim, multilingual
# modernbert-embed-base  768-dim
# bge-small, e5-small, minilm  384-dim, smaller and faster
# GET /v1/capabilities lists the models your server knows, with their dimensions

# In your docker run command, set via environment:
docker run -d --name dakera -p 3000:3000 \
  -e DAKERA_MODEL=bge-m3 \
  -e DAKERA_ROOT_API_KEY=my-dev-key \
  -e DAKERA_STORAGE=filesystem \
  -v dakera-data:/data \
  -v dakera-models:/app/models \
  ghcr.io/dakera-ai/dakera:latest

A store records the model that embedded it. When you restart an existing store with another model, Dakera (v0.12.1 and later) re-embeds it in the background, one agent namespace at a time; until its turn, each namespace keeps answering with the model its memories are in, so recall stays correct. Pull the new model first so the switch does not wait on a download, then watch the progress:

# Pull the model into the models volume before switching
docker run --rm -v dakera-models:/app/models ghcr.io/dakera-ai/dakera:latest models pull bge-m3

# After the restart, watch the background re-embed
curl -s http://localhost:3000/health | jq '.embedding_model_change'
curl -s -H "Authorization: Bearer my-dev-key" \
  http://localhost:3000/v1/capabilities | jq '.reembed_pending'

# Where the background change cannot run (DAKERA_TIERED=1, late-interaction scoring),
# start with DAKERA_ALLOW_MODEL_CHANGE=1 and re-embed explicitly (runs as a job):
curl -X POST http://localhost:3000/admin/namespaces/migrate-dimensions \
  -H "Authorization: Bearer my-dev-key" \
  -H "Content-Type: application/json" \
  -d '{"target_dimension": 1024, "reembed_same_dimension": true}'

Rate Limiting

For shared deployments where multiple developers or tools write to the same Dakera instance, configure rate limits to prevent any single client from overwhelming the server. Dakera limits requests server-wide (a token bucket per node) and, optionally, per namespace; give each tool its own API key, limited to the agents it needs:

# Server-wide limit, set when you start Dakera (defaults shown)
#   -e DAKERA_RATE_LIMIT_RPS=100 -e DAKERA_RATE_LIMIT_BURST=50

# One key per tool, pinned to the agent namespaces it may use (root key required)
curl -X POST http://localhost:3000/admin/keys \
  -H "Authorization: Bearer my-dev-key" \
  -H "Content-Type: application/json" \
  -d '{"name": "claude-desktop-key", "scope": "write",
       "namespaces": ["_dakera_agent_my-project"], "expires_in_days": 90}'

# Per-namespace caps on stores and recalls per minute (memory policy)
NS=_dakera_agent_my-project
curl -s -H "Authorization: Bearer my-dev-key" \
  http://localhost:3000/v1/namespaces/$NS/memory_policy \
  | jq '.rate_limit_enabled = true | .rate_limit_stores_per_minute = 60 | .rate_limit_recalls_per_minute = 120' \
  | curl -X PUT http://localhost:3000/v1/namespaces/$NS/memory_policy \
      -H "Authorization: Bearer my-dev-key" \
      -H "Content-Type: application/json" -d @-

Rate limiting is particularly useful when your AI tools are configured to be aggressive about storing memories — some assistant configurations store context very frequently. Without rate limits, a busy coding session could generate hundreds of store operations per hour.

Configuring Memory Decay for MCP Use

MCP-based usage naturally accumulates memories quickly — every conversation can add dozens of new facts. Configure decay so that working memory from last month doesn't crowd out fresh context from this week:

# Decay curve per memory type, in the agent's memory policy.
# PUT replaces the whole policy, so read it, change the fields, write it back.
NS=_dakera_agent_my-project
curl -s -H "Authorization: Bearer my-dev-key" \
  http://localhost:3000/v1/namespaces/$NS/memory_policy \
  | jq '.episodic_decay = "exponential" | .working_decay = "exponential" | .semantic_decay = "flat"' \
  | curl -X PUT http://localhost:3000/v1/namespaces/$NS/memory_policy \
      -H "Authorization: Bearer my-dev-key" \
      -H "Content-Type: application/json" -d @-

# The half-life is server-wide: DAKERA_DECAY_HALF_LIFE_HOURS (default 168)

Each memory type can use exponential, linear, step_function, power_law, logarithmic or flat; with the power profile, the assistant can do the same through dakera_memory_policy_set. With exponential decay and the default 168-hour half-life, an episodic memory that is not recalled has half its importance after 7 days and about 1/8 after 21 days; working memories decay three times faster, semantic ones half as fast, and flat stops decay. Each recall restarts the clock. Decay never deletes a memory: importance stops at a floor of 0.01. A memory stored with a high importance (say 0.9) starts higher, so it stays above a min_importance recall filter longer, but it decays at the same rate.

Connecting to a Remote Dakera Instance

If you run Dakera on a remote server (for team sharing, or to use a more powerful machine for embedding computation), update the DAKERA_API_URL environment variable to point to the remote address. Ensure TLS is configured on the remote server before exposing it beyond localhost — see the self-hosting guide for the Caddy reverse proxy setup:

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "env": {
        "DAKERA_API_URL": "https://memory.yourdomain.com",
        "DAKERA_API_KEY": "your-production-key"
      }
    }
  }
}

What to Do Next

With Dakera connected to your AI tools, here are productive next steps:

Organize with namespaces

Use a separate agent ID, and with it a separate namespace, for each project or context. This keeps memories focused and improves recall precision:

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

Instruct the assistant to use a project-specific agent ID when storing and recalling memories. Each agent ID has its own namespace, which keeps each project's context isolated.

Store project context early

At the start of a new project, tell your AI assistant about the architecture, conventions, and decisions. These become retrievable context for all future sessions:

• Tech stack and framework choices
• Naming conventions and code style preferences
• Deployment targets and infrastructure details
• Key business logic and domain terminology
• Past decisions and their rationale

Explore the API

Dakera exposes a full REST API beyond what the MCP tools surface. You can build custom integrations, batch-import existing knowledge, or query memories programmatically:

# Store a memory via the API
curl -X POST http://localhost:3000/v1/memory/store \
  -H "Authorization: Bearer my-dev-key" \
  -H "Content-Type: application/json" \
  -d '{"agent_id": "my-project", "content": "Our API uses camelCase for JSON fields", "metadata": {"category": "conventions"}}'

# Search memories
curl -X POST http://localhost:3000/v1/memory/recall \
  -H "Authorization: Bearer my-dev-key" \
  -H "Content-Type: application/json" \
  -d '{"agent_id": "my-project", "query": "JSON naming conventions", "top_k": 5}'

Set up for production

For team or production use, consider these upgrades:

• Generate a strong API key: Use openssl rand -hex 32 instead of my-dev-key.
• Enable encryption at rest: Set DAKERA_ENCRYPTION_KEY to encrypt memory content on disk.
• Switch to S3 storage: For durability and backup, configure DAKERA_STORAGE=s3 with your bucket credentials.
• Run behind a reverse proxy: Add TLS termination with Caddy or Nginx if exposing beyond localhost.
• Monitor with the dashboard: Dakera exposes Prometheus metrics at /metrics for observability.

Use multiple tools with shared memory

One of the most powerful aspects of this setup is that all your AI tools share the same memory backend. A decision you record in Claude Desktop is instantly available to Cursor. Context you store during a Claude Code session carries over to Windsurf. This creates a unified knowledge layer across your entire development workflow.

For example, if you document your API authentication flow in one tool, every other tool will recall that context when you ask about authentication — no repetition needed.

Read the docs

The full Dakera documentation covers advanced topics including hybrid search tuning, knowledge graphs, temporal memory, multi-agent architectures, and the SDK libraries for Python, JavaScript, Rust, and Go. Visit Dakera documentation or read the MCP server reference to dive deeper.