Claude Context

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.