Dakera MCP Memory Server: Setup Guide for Claude, Cursor, 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 3300:3300   -e DAKERA_PORT=3300   -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:3300/health

{"status":"healthy","version":"0.11.55"}

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
dakera-mcp --version

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 — full-text search across all stored memories.
• dakera_forget — remove specific memories when they are no longer relevant.
• dakera_namespace_create — organize memories into separate namespaces per project.

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",
      "args": ["--url", "http://localhost:3300", "--api-key", "my-dev-key"]
    }
  }
}

Step 4: Configure Claude Code

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300", "--api-key", "my-dev-key"]
    }
  }
}

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300", "--api-key", "my-dev-key"]
    }
  }
}

Namespaces for multi-project setups

If you work across multiple projects, you can pass a --namespace argument to isolate memories per project:

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": [
        "--url", "http://localhost:3300",
        "--api-key", "my-dev-key",
        "--namespace", "my-project-name"
      ]
    }
  }
}

This ensures that memories from one project do not bleed into another during recall.

Step 5: Configure Cursor

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300", "--api-key", "my-dev-key"]
    }
  }
}

Step 6: Configure Windsurf

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300", "--api-key", "my-dev-key"]
    }
  }
}

Step 6.5: Choose Your Tool Profile (DAKERA_MCP_PROFILE)

Dakera exposes 86+ MCP tools total, but loading all of them wastes context window tokens. The DAKERA_MCP_PROFILE environment variable (or --profile CLI flag) controls which tools appear in tools/list:

Set via environment variable in your MCP config:

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300", "--api-key", "my-dev-key"],
      "env": {
        "DAKERA_MCP_PROFILE": "power"
      }
    }
  }
}

Or via CLI flag: dakera-mcp --profile power

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 (12 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:

curl -H "Authorization: Bearer my-dev-key"   http://localhost:3300/v1/memories?limit=5

This returns the most recent 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:3300/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 3300.

Authentication errors (401 Unauthorized)

• API key mismatch: Ensure the --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

• Namespace mismatch: If you configured a --namespace in one tool but not another, memories will not be shared between them. Use the same namespace across tools, or omit the flag to use the default namespace.
• 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, verify the tool list with dakera-mcp --list-tools.
• 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 namespace sizes via the API
curl -H "Authorization: Bearer my-dev-key"   http://localhost:3300/v1/namespaces | jq '.[] | {name, memory_count}'

To reduce memory, configure decay settings to prune old memories and set per-namespace maximums. 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 use the same API key and the same namespace (or omit the namespace flag to use the default). If you configure different namespaces per tool, memories will not be shared between them.

Shared Namespace 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",
      "args": [
        "--url", "http://localhost:3300",
        "--api-key", "my-dev-key"
        // No --namespace flag = all tools share the default namespace
      ]
    }
  }
}

Project-Scoped Shared Memory

For a more organized setup, use per-project namespaces and ensure all tools use the same namespace when working on that project. You can switch namespaces per project by changing the --namespace value in each tool's project-specific config:

# .mcp.json in your project root (Claude Code reads this automatically)
{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300",
               "--api-key", "my-dev-key",
               "--namespace", "acme-backend"]
    }
  }
}

# .cursor/mcp.json (Cursor reads this automatically for the project)
{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300",
               "--api-key", "my-dev-key",
               "--namespace", "acme-backend"]  // Same namespace!
    }
  }
}

Now Claude Code and Cursor share the acme-backend memory space. 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",
      "args": [
        "--url", "https://memory.internal.yourcompany.com",
        "--api-key", "team-shared-key",
        "--namespace", "acme-backend"
      ]
    }
  }
}

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)

# Step 2: Verify the memory exists via the API
curl -H "Authorization: Bearer my-dev-key"   -X POST http://localhost:3300/v1/memories/search   -H "Content-Type: application/json"   -d '{"query": "database PostgreSQL", "limit": 3}' | jq '.results[].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-small-en-v1.5 embedding model running locally via ONNX. You can switch to a different model for different accuracy/speed trade-offs. Configure the model in your Dakera server's configuration or via environment variable:

# Available on-device ONNX models:
# bge-small-en-v1.5  — 33M params, fastest, 384-dim embeddings (default)
# bge-base-en-v1.5   — 109M params, balanced, 768-dim embeddings
# minilm-l6-v2       — 22M params, fastest, 384-dim embeddings
# e5-small-v2        — 33M params, E5 family, 384-dim embeddings

# In your docker run command, set via environment:
docker run -d --name dakera -p 3300:3300   -e DAKERA_EMBEDDING_MODEL=bge-base-en-v1.5   -e DAKERA_ROOT_API_KEY=my-dev-key   -v dakera-data:/data   ghcr.io/dakera-ai/dakera:latest

Switching models invalidates existing embeddings — existing memories will be re-embedded on next access. For large memory stores, trigger a full re-indexing pass after switching:

# Trigger re-embedding of all memories (runs asynchronously)
curl -X POST http://localhost:3300/v1/admin/reindex   -H "Authorization: Bearer my-dev-key"   -H "Content-Type: application/json"   -d '{"namespace": "all"}'

# Monitor progress
curl http://localhost:3300/v1/admin/reindex/status   -H "Authorization: Bearer my-dev-key"

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. Rate limits are set per API key:

# Create a rate-limited API key for a specific tool
curl -X POST http://localhost:3300/v1/keys   -H "Authorization: Bearer admin-key"   -H "Content-Type: application/json"   -d '{
    "name": "claude-desktop-key",
    "rate_limit": {
      "stores_per_minute": 60,
      "searches_per_minute": 120
    }
  }'

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.

Adjusting the Hybrid Retrieval Parameters

The balance between vector search and BM25 keyword search is configurable. If your use case relies heavily on exact term matching (error codes, identifiers, specific version numbers), increase the BM25 weight. If you need broader semantic matching, increase the vector weight:

{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": [
        "--url", "http://localhost:3300",
        "--api-key", "my-dev-key",
        "--retrieval-mode", "hybrid",
        "--bm25-weight", "0.4",    // Default: 0.3
        "--vector-weight", "0.6"   // Default: 0.7
      ]
    }
  }
}

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:

# Set decay strategy for a namespace via the REST API
curl -X PUT http://localhost:3300/v1/namespaces/my-project/policy   -H "Authorization: Bearer my-dev-key"   -H "Content-Type: application/json"   -d '{
    "decay_strategy": "logarithmic",
    "decay_half_life_days": 30,
    "max_memories": 50000
  }'

This configuration means memories from 30 days ago have half the retrieval weight of fresh memories. After 90 days, they have about 1/8 the weight. High-importance memories (those stored with importance > 0.8) resist decay more aggressively.

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 --url flag 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",
      "args": [
        "--url", "https://memory.yourdomain.com",
        "--api-key", "your-production-key"
      ]
    }
  }
}

What to Do Next

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

Organize with namespaces

Create separate namespaces for different projects or contexts. This keeps memories focused and improves recall precision:

# In your .mcp.json, use different namespaces per project
{
  "mcpServers": {
    "dakera": {
      "command": "dakera-mcp",
      "args": ["--url", "http://localhost:3300", "--api-key", "my-dev-key", "--namespace", "acme-api"]
    }
  }
}

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:3300/v1/memories   -H "Authorization: Bearer my-dev-key"   -H "Content-Type: application/json"   -d '{"content": "Our API uses camelCase for JSON fields", "metadata": {"category": "conventions"}}'

# Search memories
curl -X POST http://localhost:3300/v1/memories/search   -H "Authorization: Bearer my-dev-key"   -H "Content-Type: application/json"   -d '{"query": "JSON naming conventions", "limit": 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 all stored memories 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.