Context Engine: an MCP server for semantic code search, with a hosted backend you have to sign up for
Context-Engine MCP - Agentic Context Compression Suite
At a glance
- What is it?
- Context Engine is a Python MCP tool suite that gives coding assistants semantic search, symbol graph navigation and persistent memory over your repository. The catch is that the repository alone is not the product: indexing, authentication and retrieval run through a hosted service at context-engine.ai.
- Who is it for?
- Adopt it if your team already pays for an AI coding assistant and wants symbol-level navigation, batch queries and cross-session memory without building a retrieval stack. Do not adopt it if you need a fully self-hosted pipeline, if your code cannot leave your network, or if you want an MCP server you can audit end to end from this repository alone.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 69 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Context Engine targets: assistants that do not know your codebase
An AI coding assistant with no retrieval layer works from whatever files you paste or whatever it can guess from filenames. On a repository with more than a handful of modules, that produces plausible-looking edits that miss the caller three directories away. Context Engine's answer is to index the codebase and expose the index over MCP, the Model Context Protocol, so the assistant can call search and navigation tools instead of guessing.
The README frames the target user narrowly: developers using Claude Code, Claude Desktop, Cursor, Codex, Windsurf, Augment Code or Gemini, who want the assistant to reach 30+ MCP tools covering semantic search, a symbol graph, memory and git history. The skills shipped in the repository are the teaching layer. They tell the assistant when to call search versus symbol_graph versus search_commits_for. Without them, the tools exist but the assistant does not know to use them.
How the pieces fit: skills, bridge, backend
There are three separable parts, and conflating them is the main source of confusion when reading the README.
The first is the skill files. These are plain directories copied into your assistant's config location: skills/context-engine/ for Claude, .cursorrules at the workspace root for Cursor, .codex/skills/context-engine/ for Codex, .augment/ for Augment, GEMINI.md for Gemini. The README also notes that skills/context-engine/SKILL.md works with any assistant that accepts custom instructions, provided you tell it to read the file. Nothing here executes; it is prompt material.
The second is the MCP bridge, distributed as an npm package, @context-engine-bridge/context-engine-mcp-bridge. This is the process that authenticates, walks your workspace, watches for file changes and serves MCP over stdio or HTTP. The README gives two serve commands: ctxce mcp-serve --workspace /path/to/repo for stdio clients such as Claude Code and Codex, and ctxce mcp-http-serve --workspace /path/to/repo --port 30810 for clients that speak HTTP.
The third is the hosted service. You sign up at context-engine.ai for an API key, and ctxce connect takes that key. The README does not describe what runs server-side. It lists Qdrant and Ollama among the repository topics, which hints at a vector store and local model inference somewhere in the stack, but the README itself does not document a self-hosted deployment path. Treat the architecture as: local watcher and MCP surface, remote retrieval and storage.
Getting it running: the two installation routes
Route one is the VS Code extension, named Context Engine Uploader in the README, which handles connecting the codebase. Route two is the CLI, which is what the README documents in detail.
The CLI install is a single global npm install:
npm install -g @context-engine-bridge/context-engine-mcp-bridge
Then a connect call that authenticates, indexes and starts watching:
ctxce connect <your-api-key> --workspace /path/to/repo
The README recommends adding --daemon to run it in the background. Daemon control is two more commands, ctxce status and ctxce stop. The connect flags table lists --workspace (alias -w, defaulting to the current working directory), --daemon (aliases -d and --bg), --interval in seconds with a default of 30, --no-watch (alias --once) to index a single time, and --skip-index (alias --auth-only) to authenticate without indexing.
State lives in two places worth noting before you run anything: credentials at ~/.ctxce/auth.json, shared between the daemon and the MCP server, and daemon output at ~/.context-engine/daemon.log. If your threat model cares about API keys on disk, that first path is the one to check.
The skill install for Claude Code uses the plugin marketplace rather than a file copy:
/plugin marketplace add Context-Engine-AI/Context-Engine /plugin install context-engine
For Codex, the README says you can ask the assistant to install the skill from the GitHub URL, or copy .codex/skills/context-engine/ into ~/.codex/skills/context-engine/ yourself.
What the tools actually change about assistant behaviour
The README's tool summary is the most concrete part of the documentation. Two items stand out.
First, search is described as the default tool that auto-routes a query to the best backend among semantic search, Q&A, symbol graph, tests and config. That routing is a design decision with a cost: you lose the ability to say precisely which index answered a question, which matters when a result looks wrong and you want to know why.
Second, the batch tooling. The README claims batch_search, batch_symbol_graph and batch_graph_query give 75%+ token savings. That figure is the project's own claim and the README gives no methodology, no baseline and no measurement conditions, so treat it as a design goal rather than a verified number. The mechanism behind it is plausible enough: one round trip carrying several queries costs fewer tokens than several round trips, because each MCP call carries its own framing overhead.
The rest of the list is ordinary but useful: symbol_graph for callers, callees, definitions, importers and subclasses; memory_store and memory_find for context that survives across sessions; cross_repo_search with boundary tracing for multi-repo setups; pattern_search for structural shapes such as retry loops, error handling and singletons across languages; and search_commits_for plus change_history_for_path for git history. The git-history tools are the ones most assistants lack natively, and they are the ones most likely to change how a refactor is planned.
The limitation that matters: the repository is not the server
The README's own framing gives the constraint away. Step one of Getting Started is sign up at context-engine.ai. The CLI takes an API key. The bridge shares auth through ~/.ctxce/auth.json. There is no documented self-hosted mode, no Docker Compose file mentioned, no configuration key for pointing the bridge at your own Qdrant instance. The topics list mentions Qdrant and Ollama, but topics are not documentation.
For a team whose code cannot leave its network, that is a hard stop, and the README does not offer a workaround. For everyone else it is a dependency question: your retrieval quality, availability and latency are now tied to a third-party service, and the MIT licence on this repository does not extend to that service. The licence covers the code here, which is the skill files and whatever Python ships in the repo. It says nothing about the hosted backend, and nothing in the README describes the terms under which the service is provided.
A second, smaller limitation is client drift. The skill files are copied into assistant-specific directories that vendors rename and restructure. A .cursorrules file at a project root and a .codex/skills/ tree are not stable interfaces. Expect to re-copy and re-check when your assistant updates, and expect the plugin marketplace route for Claude to be the only one that updates itself.
Where it sits next to Sourcegraph and plain grep-based tooling
The obvious comparison is Sourcegraph, which also indexes code and exposes search and a symbol graph to tools. The difference in approach is where the index lives and who consumes it. Sourcegraph is built as a self-hostable code intelligence platform with its own web UI and API, and its search is aimed at humans first. Context Engine is built as an MCP surface aimed at an assistant, with the index hosted by the vendor and the human-facing layer reduced to a signup page and a CLI.
That inversion explains most of the trade-offs. You get less to operate, because there is no index server to run. You also get less to inspect, because the retrieval logic is not in this repository. A second comparison point is the assistant's own built-in file search. Cursor and Claude Code already read files and follow imports. Context Engine's argument is that semantic search plus a persisted symbol graph plus cross-session memory beats that, and the batch tooling is where the token accounting would show up if it holds. If your repository is small enough that the assistant can read the relevant files directly, the indexing layer adds a service dependency for little gain.
Maintenance surface and what to check before you commit
The repository is actively pushed, with v1.0.0 on 2026-07-03 and v1.0.1 on 2026-07-08, and it is not archived. The default branch is named test, which is unusual for a project at 1.0 and worth noting if you plan to pin to a branch rather than a tag. Pin to the release tags.
Upgrade cost splits along the three parts. The npm bridge upgrades with npm and carries the daemon; a bridge update can change the MCP tool surface your assistant was taught to use, so the skill files and the bridge version need to move together. The skill files are manual copies for every client except Claude Code, so each assistant update is a re-copy. The hosted backend upgrades without your involvement, which is convenient and also means retrieval behaviour can change under you with no local diff to review.
On licensing, the repository is MIT, copyright 2025 Context Engine Inc. and John Donalson. MIT permits commercial use and modification of the code in this repository. It does not grant anything regarding the hosted service, and the README does not state service terms. If your organisation requires a signed data processing agreement before code is sent to a third party, that question is outside the scope of this repository and belongs with the vendor.
Editorial conclusion
Adopt it if your team already pays for an AI coding assistant and wants symbol-level navigation, batch queries and cross-session memory without building a retrieval stack. Do not adopt it if you need a fully self-hosted pipeline, if your code cannot leave your network, or if you want an MCP server you can audit end to end from this repository alone. Before committing, verify three things: that a free account at dev.context-engine.ai is enough for your repository size, that the npm bridge package @context-engine-bridge/context-engine-mcp-bridge is one your security team will allow on developer machines, and that the skill files under skills/context-engine/ and .codex/skills/ actually match the client versions you run.
Community notes