MCP server and core library that index codebases into a Milvus/Zilliz vector database and expose semantic code search to coding agents.
github.com/zilliztech/claude-context · 2026-10-05 · 6fc318b
Defense-in-depth score
4.1 / 10
A narrow code-search server: it runs no code and loads no plugins, and it keeps dotfiles and .env files out of its index. Around that core it has few safeguards. Any directory the user can read can be indexed and uploaded to the embedding provider and vector database, the destructive clear tool carries no risk labels for hosts, and search results return indexed code (including third-party code) unmarked. The index persists and re-syncs in the background, with no audit log of the server's own.
Claude Context runs no code, loads no plugins and keeps dotfiles and .env files out of its index. It has no read-only mode, no approval step of its own and no limit on which directories it reads, so the safest setup narrows its keys and its view of your files from the outside.
| Setup | How | What it gives you |
|---|---|---|
| A cluster-scoped database token | Set MILVUS_TOKEN to a token scoped to one dedicated cluster, in place of an account-level Personal Key | The vector database itself keeps the server's writes and deletions inside that one cluster C1 |
| A dedicated, low-limit embedding key | Give the server its own embedding-provider key with a spending limit set at the provider | Indexing spend has a ceiling, and a leaked key reaches only this one use C10 |
| Local embeddings | EMBEDDING_PROVIDER=Ollama with OLLAMA_HOST pointing at an Ollama server you run | Your source code is embedded on your own machine instead of at a third-party provider C8 |
| Indexing on request | CLAUDE_CONTEXT_BACKGROUND_SYNC=false | Tracked codebases stop re-indexing on a timer, so spend and index contents follow your own calls C6 |
| Only the projects you mean | Run the server in a container or as an OS user that can read only the repositories you want indexed | Whatever the model asks for, only those directories can reach the index and the embedding provider C3 |
| A kept server log | Have your MCP host save the server's stderr to a file the agent can't modify | A record of index runs, searches and clears that outlives the session C9 |
0.23 / 1.00
The server runs as the local OS user and holds two long-lived service keys: an embedding-provider key (OpenAI by default) and a vector-database key, which the README tells users to fill with their Zilliz Cloud Personal Key. Every tool uses the same shared clients, and there is no authorization step: any directory the OS user can read can be indexed, and any indexed codebase can be searched or cleared. Nothing narrows the keys per tool or per request.
0.10 / 1.00
The server gives the host nothing to base an approval decision on. None of the four tools carries MCP risk annotations, so a host cannot tell the read-only search and status tools from clear_index, which drops a codebase's collection, or index_codebase, which with force=true deletes and rebuilds an index and uploads file contents to the embedding provider. The only safeguard is tool-description text asking the model to confirm with the user before a forced re-index. The destructive actions affect derived index data that can be rebuilt by re-indexing.
0.35 / 1.00
The tools are narrow (index, search, clear, status) and there is no shell, generic HTTP or file-write tool. Validation is light: paths are made absolute and checked to be existing directories, the splitter is checked against an enum, search results are capped at 50 and snippets at 5,000 characters, and indexing is limited by a default extension allowlist that skips dotfiles and .env files. There is no containment to a project root, so any readable directory can be indexed, and the model-supplied extension and ignore-pattern lists are taken without checks, which lets a caller widen what gets indexed.
N/A · full credit 1.00 / 1.00
The server never executes code. It parses source files with bundled tree-sitter grammars and sends text to the embedding provider and vector database; there is no subprocess, eval or dynamic code path in the server or core library.
0.10 / 1.00
Search results return raw code chunks from whatever repositories were indexed, which may include cloned third-party code containing instructions aimed at the model. Results carry a file location but no untrusted marking, and they are mixed with the server's own guidance text; the tool descriptions also contain directives to the model. On the other side, the server has no outbound channel an attacker can choose (it only talks to the operator's configured embedding provider and vector database) and its destructive action only removes rebuildable index data, but it can put any readable code into the host's context, where the host's other tools could leak it.
0.30 / 1.00
The vector index is a persistent retrieval store: whatever indexed files contain, including instructions planted in third-party code, is returned in later sessions, and background sync re-indexes every tracked codebase every five minutes by default without review. Each codebase gets its own collection, and the local tracking file and settings live in the user's home directory, not the workspace. Workspace ignore files can only change which files are indexed, not security settings. The local tracking list is also reconciled with the collections found in the vector-database account, so codebases discovered there are added and then re-synced without a user decision. Entries can be purged with clear_index.
N/A · full credit 1.00 / 1.00
The server loads no plugins, launches no other MCP servers and installs nothing at runtime; it only uses its fixed npm dependencies (tree-sitter grammars, the Milvus SDK and embedding SDKs). The README's npx ...@latest launch is the host's supply-chain choice, not something the server does.
0.38 / 1.00
API keys come from environment variables or a plaintext ~/.context/.env file, and startup logs only show whether each key is set, never its value. Dotfiles and .env files are always skipped during indexing, which keeps the most common secret files away from the embedding provider and the index. There is no telemetry. Source code itself, including any secrets inside it, is sent to the embedding provider and stored in the vector database by design, there is no secret scanning, and the debug-level logs on stderr include search queries and file paths. Both keys are long-lived and the vector-database key is often account-wide.
0.33 / 1.00
The only record is free-text console output redirected to stderr: index starts, search queries and clear operations are all logged, but without structure, caller identity or a durable file of the server's own. Whether anything is kept depends on the host capturing stderr.
0.33 / 1.00
The server enforces some bounds of its own: search returns at most 50 results with snippets truncated to 5,000 characters, indexing stops at 450,000 chunks, and clear_index cancels an in-flight indexing run before dropping the collection. There are no rate limits, the directory walk and per-call embedding requests have no server-set timeouts, and background sync re-indexes every tracked codebase every five minutes by default, spending embedding credits with no budget.
SafetyCard