ContextBridge
Why ContextBridge
Without CB, an AI coding agent either guesses which files are relevant, or you paste entire source files into the chat — burning thousands of input tokens on code that isn't needed. With CB, the AI calls a single MCP tool and gets back a ranked, grounded result instead.
| Without CB | With CB |
|---|---|
| Paste 10–50 raw files into context | CB returns the 3–5 files that actually matter |
| AI guesses which code is relevant | Result is grounded in your real codebase structure |
| High token cost, noisy context | Low token cost, focused context |
| Hallucinated file paths and method names | Exact file paths, symbols, and line hints |
What it does
- Indexes your codebase's real structure (via Graphify output — not raw source) into a searchable graph of files, symbols, and dependency edges
- Exposes a single primary MCP tool,
search_context_hybrid(), that any MCP-compatible AI client can call to get ranked files, symbols, and dependency chains - An optional local AI analysis stage (Ollama by default, or OpenAI/Anthropic/OpenRouter if you opt in) validates and re-ranks results before they reach your cloud AI
- Tracks UI-to-backend call mappings (dependency-edge enrichment) so frontend-to-API routing questions resolve to the real connected files, not just co-located ones
How the token savings actually happen
Without CB, answering a codebase question means the AI either pastes several full source files into its context window (often 10–50 files, tens of thousands of lines) or guesses at relevance from filenames alone. Both burn input tokens on code that usually isn't the actual answer.
CB cuts this in three stages:
- Retrieval, not dumping —
search_context_hybrid()returns only the ranked owner file(s), directly related files, matched symbols, and a dependency summary — not full file contents. - Compact result shape — the response is a structured JSON summary (facts, ranked files, symbol hits, dependency chains) instead of raw code blocks, so even the files it does surface are represented as targeted snippets and line hints, not entire files.
- Optional local AI compression — if enabled, a local model (Ollama by default) validates and re-ranks the result, decomposes multi-topic prompts, and passes a further-compressed, grounded summary to your cloud AI — so the cloud model only ever sees the distilled answer, not the raw retrieval output.
Measured result: a typical query response is ~4–8 KB, versus ~118 KB of raw source an AI would otherwise pull in to answer the same question — about a 96% reduction in tokens actually sent to your cloud AI.
Retrieval modes
- Hybrid (recommended) — keyword-first with guarded vector assist
- Semantic — vector-only, best for vague "how does X work" questions
- Keyword — pure keyword search for exact known symbol/file names
Local-first by default
Core retrieval and indexing run entirely on your machine — your code never leaves it unless you explicitly configure a cloud LLM provider for the optional analysis stage.
Works with any AI client
Claude Code, Cursor, Codex, Antigravity, Gemini CLI, or anything that speaks MCP. Supports both SSE (recommended — one shared server for multiple clients) and stdio transport, so it works with clients that only support one or the other.
Generic engine, not project-specific
All project-specific ranking logic lives in a swappable profile plugin. Out of the box
(project_profile: "default") you get pure generic scoring that works on any codebase,
any stack.
服务器配置
{
"mcpServers": {
"context_bridge": {
"url": "http://127.0.0.1:8755/sse"
}
}
}