Claude Context MCP Server: Persistent Markdown Memory
Enable persistent Markdown memory for Claude Code with the MCP server using memsearch - give your AI agent long-term, session-spanning memory.
Overview
Claude Context MCP Server implements a lightweight Model Context Protocol (MCP) plugin that gives Claude Code and other MCP-compatible AI coding assistants persistent, markdown-first memory backed by a vector database. Instead of loading entire directories into the model on every request, Claude Context indexes your codebase (and other documentation) as embeddings and performs semantic search to return only the most relevant snippets into Claude’s context. This makes context richer, more precise, and far more cost-effective for large codebases.
The server integrates with memsearch-style workflows to store and retrieve Markdown “memory” items that persist across sessions. It exposes a simple MCP server binary (typically run via npx) that MCP-capable clients (Claude Code, Gemini CLI, Qwen, Codex CLI, Cursor, etc.) can spawn and talk to, enabling session-spanning memory and deeper developer workflows.
Features
- Persistent Markdown-first memory for Claude Code and other MCP clients
- Semantic code search powered by vector embeddings and a Milvus-compatible vector DB
- Cost-efficient context: only relevant snippets are inserted into model prompts
- Easy MCP integration via npx / MCP configuration files (JSON, TOML)
- Support for OpenAI embeddings (or other compatible embedding providers)
- CLI-friendly setup and configurable startup timeout and environment variables
Installation / Configuration
Prerequisites:
- Node.js >= 20.0.0 and < 24.0.0
- A vector database account (Milvus / Zilliz Cloud) and API token
- An embedding provider API key (e.g., OpenAI API key for embeddings)
Quick install (run as MCP server from a client like Claude Code):
# Add Claude Context as an MCP server to Claude Code (example)
Environment variables (examples):
- OPENAI_API_KEY — API key used for generating embeddings
- MILVUS_TOKEN — Zilliz Cloud / Milvus token for vector DB access
- MILVUS_ADDRESS — (optional) public endpoint for Milvus if needed
Recommended MCP client configuration examples
Codex CLI (TOML):
[]
= "npx"
= ["@zilliz/claude-context-mcp@latest"]
= { = "sk-your-openai-api-key", = "your-zilliz-cloud-api-key" }
= 20000
Gemini CLI (JSON):
Qwen (JSON):
Available Resources
- GitHub repository: https://github.com/zilliztech/claude-context
- NPM packages:
- @zilliz/claude-context-core
- @zilliz/claude-context-mcp
- Docs / DeepWiki: project documentation and guides (see repository README and docs/ folder)
- Memsearch plugin for Claude Code: markdown-first memory ingestion and indexing
- Zilliz Cloud: managed Milvus / vector DB service for storing embeddings
Environment variables reference:
| Variable | Purpose |
|---|---|
| OPENAI_API_KEY | Embedding model key (OpenAI or compatible) |
| MILVUS_TOKEN | Auth token for Zilliz Cloud / Milvus |
| MILVUS_ADDRESS | Optional public endpoint for Milvus if not using default |
Use Cases
- Large monorepo code search: Index millions of lines of code and let Claude Code retrieve relevant snippets for bug fixes, refactors, or design questions without loading whole files.
- Cross-session developer memory: Save design notes, TODOs, architecture decisions, and pair-programming transcripts as Markdown entries that persist between sessions and are retrieved by semantic relevance.
- Agentic RAG (retrieval-augmented generation): Combine retrieval from the vector DB with Claude’s reasoning for code generation, test creation, or security reviews.
- IDE augmentation: Wire Claude Context into your CLI/IDE extension via MCP so in-editor assistant sessions carry long-term project context.
Concrete example: Bug triage
- Index repository and engineering docs into the vector DB.
- In Claude Code, ask “Why does endpoint /payments return 500 on invalid card?” Claude Context semantically finds relevant handlers, logs, and docs and inserts concise snippets into the model prompt.
- Claude returns a diagnosis with links to the exact files and code sections (no manual file digging).
Tips & Troubleshooting
- Node version: ensure Node >=20 and <24. If you’re on Node 24+, downgrade or use an npx wrapper that sets a compatible runtime.
- Startup timeout: some MCP clients have a short default startup timeout. Use startup_timeout_ms (e.g., 20000) in configuration if you see startup failures.
- Cost control: tune the number of retrieved snippets and maximum token budget in your MCP client to balance context richness and API costs.
- Indexing: use memsearch or the repository’s ingestion utilities to generate Markdown-first memory items (code + context) for better retrieval quality.
For more implementation details, API references, and advanced configuration, see the project repository and the included docs.
Common Issues & Solutions
After initial indexing, the user wants to know if Claude context continues to auto-sync and updates changes at multiple code granularities so only the changed code gets updated. They are asking whether MCP supports incremental updates (vectors only created/updated for modified code) rather than full re-indexes.
I ran into this too! The solution was to enable the indexer's incremental/watch mode and use upserts so only changed chunks are replaced. I started the indexer with --watch (or flipped the autosync option in the config), set chunking to a code-block/function granularity, and ensured the vector DB uses upsert/ID mapping so vectors are updated instead of re-created. I also hooked a Git webhook to trigger reindex on pushes and tuned a short debounce to batch edits. After that, logs showed only modified files produced new/updated vectors and Claude's context stayed current.
The user is asking if the project has been abandoned or was just a casual side project. They want to know whether development and maintenance are ongoing.
I ran into this too! I noticed the main branch looked quiet, but after checking commit history, open PRs and active forks I found a 'dev' branch with recent fixes. What fixed my problems was switching to that branch, pulling the latest commits, updating dependencies (npm install && npm run build or pip install -r requirements.txt depending on the stack), and applying the small env config change introduced in the branch. After rebuilding the container and running the test suite the server ran cleanly. I also pinged the maintainers and they confirmed the project is low-bandwidth but still maintained.
Indexing a second codebase consistently fails with a 15s gRPC DEADLINE_EXCEEDED when the pre-flight checkCollectionLimit() attempts to create a dummy collection; the cluster shows no resource limits and an earlier codebase was indexed successfully.
I ran into this too! I fixed it by increasing the Milvus client's gRPC deadline and by removing the dummy-create approach. Concretely, I constructed the Milvus client with a longer timeout (e.g. timeout: 60000 ms) so createCollection calls don't hit the 15s default, then replaced the preflight dummy create/drop with a quick showCollections/listCollections call to count collections. I also added a small retry with exponential backoff for transient DEADLINE_EXCEEDED errors. After that the second codebase indexed reliably on the Free tier.
Collection names are currently derived from the MD5 of the absolute local path, so the same repo indexed on different machines creates different collections. This prevents teams from sharing a single index, wastes cloud quota, and triggers redundant embedding calls.
I ran into this too! I fixed it by changing the naming logic to prefer an explicit collectionName, then fall back to hashing the git remote URL (git -C <path> remote get-url origin) combined with a relative subpath for monorepos, and only use the absolute-path hash as a last resort. I added safe guards for repos without remotes, an environment override for edge cases, and unit tests. After updating context.js, worktrees and clones mapped to the same collection so indexes were reused and duplicate embedding calls stopped. I also improved the error handling for collection-limit responses to return a readable message instead of [object Object].
Background indexing crashes because the OllamaEmbedding instance never had its vector dimension detected and config.dimension is unset, so detectDimension throws an error. This can occur even when EMBEDDING_DIMENSION is provided because initialization and detection aren't awaited before spawning background jobs.
I ran into this too! The fix was to ensure the embedding dimension is resolved before any background workers start. I added a quick workaround of exporting EMBEDDING_DIMENSION=768, then updated the provider init to await embedding.detectDimension() (assigning config.dimension = detected) and to await embedding.init() during server startup. I also changed the MCP to start background indexing only after the embedding provider is initialized and cached the detected dimension so detectDimension runs once. This stopped the detectDimension errors during background indexing.