Context Engine: an MCP server that gives coding assistants semantic search over your repo

The retrieval gap Context Engine targets in AI coding assistants

Most coding assistants read files you point them at and grep for strings you name. That works until a question spans several files, or until the answer lives in a symbol that no text search would surface. Context Engine is built for that second case: the repository describes it as "semantic code search, memory, and symbol intelligence for AI coding assistants", and the tool list in the README backs the claim with search, symbol_graph, cross_repo_search, pattern_search and memory_store.

The audience is narrow and specific. You need an MCP-capable client (Claude Code, Claude Desktop, Codex, Cursor, Windsurf, Augment Code or Gemini), a codebase large enough that naive grep wastes context, and a willingness to run a Qdrant instance plus an indexer. A solo developer working in a 2,000-line project will get nothing from this that their editor's built-in search does not already give them.

How the indexer, Qdrant and the MCP bridge fit together

The data flow has three parts. An indexer walks the workspace, parses source with tree-sitter, and writes vectors and symbol metadata into Qdrant. The MCP server exposes tools over stdio or HTTP that query that store. The bridge (ctxce) is the piece that authenticates, triggers indexing, watches for file changes, and starts the MCP server your assistant talks to.

The dependency list makes the parsing story concrete: tree_sitter plus separate packages for Python, JavaScript, TypeScript, Go, Rust, Java, C, C++, Ruby, C#, Bash, JSON, YAML, HTML, CSS and Markdown. Symbol graph queries are therefore language-aware rather than regex-based. The requirements file pins qdrant-client to >=1.15.0,<1.16.0 with a comment explaining that 1.16 removed the .search() method and broke OpenLit instrumentation, so the version ceiling is deliberate, not incidental.

The repository ships several Dockerfiles (Dockerfile, Dockerfile.indexer, Dockerfile.llamacpp, Dockerfile.mcp, Dockerfile.mcp-indexer, Dockerfile.upload-service) and the base Dockerfile describes a "unified" image supporting memory, indexer, watcher and llamacpp roles, defaulting to the memory server. That is a deployment choice worth noting: the same image can take different roles depending on the command, which keeps the Kubernetes story simpler but means one image carries every dependency.

Installing the bridge and running a first index

The README splits installation into two tracks. If you use VS Code, you install the Context Engine Uploader extension from the marketplace. If you use a terminal-based MCP client, you install the MCP bridge globally from npm. The bridge is the path documented with commands, so it is the one to follow here.

Install the bridge globally:

npm install -g @context-engine-bridge/context-engine-mcp-bridge

Then authenticate against your account and index a workspace. The README shows the connect command with an API key and a workspace path:

ctxce connect <your-api-key> --workspace /path/to/repo

For a long-running setup, the same command takes --daemon. The README recommends this mode:

ctxce connect <your-api-key> --workspace /path/to/repo --daemon

Daemon control is two more subcommands. ctxce status reports whether the daemon is running and ctxce stop shuts it down. Useful flags listed in the README table include --workspace / -w (defaults to the current working directory), --interval for the file watch interval in seconds (default 30), --no-watch / --once to index once without watching, and --skip-index / --auth-only to authenticate without indexing. After that, point your client at the MCP server, either over stdio with ctxce mcp-serve --workspace /path/to/repo or over HTTP with ctxce mcp-http-serve --workspace /path/to/repo --port 30810. Auth is shared through ~/.ctxce/auth.json and daemon logs land in ~/.context-engine/daemon.log.

The second half of setup is teaching your assistant which tools exist. For Claude Code the README recommends adding the plugin marketplace and installing the skill:

/plugin marketplace add Context-Engine-AI/Context-Engine
/plugin install context-engine

Cursor picks up .cursorrules automatically when the file sits at the workspace root, and Codex can install the skill from the GitHub URL on request or by copying the .codex/skills/context-engine/ directory into ~/.codex/skills/. If your assistant supports nothing but plain custom instructions, the fallback is to copy skills/context-engine/SKILL.md into the project and tell the assistant to read it.

Where the hosted dependency and the tool surface become a problem

The clearest constraint is the account. The README's first line under the logo says to get a free account at dev.context-engine.ai, and the CLI quick start takes an API key as a positional argument. There is no documented path in the README for running the bridge against a purely local index without authenticating. The repository does contain a docker-compose.yml that builds an MCP search service from Dockerfile.mcp alongside a Qdrant container, and that service reads auth settings from environment variables with CTXCE_AUTH_ENABLED defaulting to 0, so a self-hosted auth-disabled arrangement appears to exist. But the README does not walk through it, and the compose file is labelled as development testing for the remote upload system. Treat the self-hosted route as something you would have to read the compose files and scripts to assemble.

The second issue is surface area. The README lists 30+ MCP tools and the skill file is the only complete reference. That is a lot of tools for a model to choose among, and the README itself frames the fix as teaching the assistant to use search as the default with auto-routing to the right backend. If your client does not load the skill, the model sees the raw tool list and has to guess. The batch tools (batch_search, batch_symbol_graph, batch_graph_query) are described as saving 75%+ tokens, a figure the README states without showing the measurement behind it.

Finally, the version pinning cuts both ways. Holding qdrant-client below 1.16 protects OpenLit instrumentation but also freezes you out of whatever the 1.16 line adds. The comment in requirements.txt is honest about why, which is more than most projects manage, but it is still a maintenance debt that someone has to revisit.

How this compares with running your own retrieval stack

The obvious alternative is Sourcegraph with its code intelligence, or a homegrown combination of ripgrep plus an embedding index you maintain yourself. The difference is where the work sits. A ripgrep-plus-embeddings setup gives you full control over the store, the chunking strategy and the model, and it never phones home. Context Engine trades that control for a packaged tool surface: symbol graph traversal, cross-repo boundary tracing, git history search via search_commits_for and change_history_for_path, and persistent memory across sessions through memory_store and memory_find. Those last two are the part you would find hardest to replicate cheaply, because session memory is a product decision, not an indexing one.

A closer comparison is Augment Code, which also ships context tooling for assistants. The related searches list phrases like "augment context engine alternative" and "context engine mcp augment", which suggests people evaluate the two together. Context Engine's distinguishing move is that it is MCP-native and open source under MIT, so the tool definitions and the indexer are inspectable, while the bridge still routes through a hosted account. If you want the retrieval logic auditable but do not mind the hosted auth, that combination is the reason to pick it.

Licence, releases and what a fork inherits

The repository is MIT licensed, with copyright attributed to Context Engine Inc. and John Donalson. MIT means you can fork, modify and redistribute, including commercially, provided the copyright notice and permission notice travel with the code. It does not cover the hosted service, the account, or any data you index into it; those are governed by whatever terms apply to dev.context-engine.ai, and the README does not link to them. If your organisation has rules about where source code may be sent, that distinction matters more than the licence itself.

The repository also carries a NOTICE file and a THIRD_PARTY_LICENSES file, which is where the tree-sitter grammar packages and the rest of the dependency licences are accounted for. Two releases are listed: v1.0.0 on 2026-07-03 and v1.0.1 on 2026-07-08. The last push to the default branch was on 2026-07-08, so the project has not seen a commit in roughly two and a half months. That is not abandonment, but it does mean the default branch is not moving while you evaluate it, and any bug you hit is one you may have to fix in a fork.

What to check before wiring it into a team workflow

Start by confirming the bridge package resolves and the version you get matches what the README describes. The README does not state a bridge version, so npm is the source of truth there. Next, decide which of the two deployment shapes you are actually testing: the hosted bridge path with an API key, or the docker-compose stack with Qdrant on ports 6333 and 6334 and the MCP service built from Dockerfile.mcp. They have different auth stories and the README only documents the first in detail.

Then verify the skill loads. The value of 30+ tools collapses if your assistant never reads SKILL.md, and the cheapest way to confirm is to ask your assistant a symbol-level question (who calls a given function) and see whether it reaches for symbol_graph or falls back to grep. If it greps, the skill is not loaded.

Finally, watch the token accounting on your own workload. The README's 75%+ savings claim for batch queries is stated without a methodology, so treat it as a design goal rather than a measured result until you reproduce it against your repository.

Editorial conclusion

Adopt Context Engine if your team already runs an MCP-capable assistant and wants symbol-level and cross-repo retrieval without building an indexer. Do not adopt it if you need a fully offline, account-free setup, because the CLI path authenticates against a hosted service and the README points to dev.context-engine.ai for an account. Before committing, verify the bridge version on npm resolves, check that the Qdrant port 6333 in docker-compose.yml does not collide with an existing instance, and confirm which of the 30+ tools your client actually exposes.

Frequently asked questions

Official sources

1. Context-Engine-AI/Context-Engine on GitHub
2. License: MIT
3. Project website
4. README
5. Releases