codebase-bridge-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BRIDGE_HOST | No | HTTP bind address (default: 127.0.0.1) | 127.0.0.1 |
| BRIDGE_PORT | No | HTTP listen port (default: 8765) | 8765 |
| BRIDGE_REPO | No | Path to the repository (default: current directory) | . |
| BRIDGE_MODEL | No | Default model for new threads/ephemeral calls (default: Claude Code default) | |
| BRIDGE_TOKEN | No | Bearer token for http transport (required if transport=http, unless --insecure-no-auth is set) | |
| BRIDGE_TIMEOUT | No | Per-call wall-clock cap in seconds (default: 240) | 240 |
| BRIDGE_TRANSPORT | No | Transport type: 'stdio' or 'http' (default: stdio) | stdio |
| BRIDGE_THREAD_TTL | No | Idle seconds before a thread session is dropped (default: 1800, 0 = never) | 1800 |
| BRIDGE_MAX_THREADS | No | Live-thread cap before LRU eviction (default: 256) | 256 |
| BRIDGE_CONFINE_READS | No | Confine reads to repo (1 = yes, 0 = no) (default: 1) | 1 |
| BRIDGE_MAX_CONCURRENT | No | Cap on concurrent claude subprocesses (default: 4) | 4 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ask_codebaseA | Ask a natural-language question about the local codebase, with turn-based steering. Headless Claude Code explores the repo READ-ONLY (Read/Grep/Glob) and returns a synthesized answer with file:line references -- no need to attach or paste files. thread: optional name (e.g. "auth-investigation"). Reuse the SAME name across questions to STEER: each follow-up keeps the prior session's context, so you can redirect ("no, the token check is in middleware.py -- re-check there") and it stays cheap (prompt-cache hits). Omit for a one-off fresh session. model: optional model (e.g. "sonnet", "opus"). For a thread it BINDS on the first call; a DIFFERENT model on an existing thread is refused, because switching forces a full-context reprocess -- start a new thread instead. Ephemeral (no-thread) calls just use the given model. effort: optional reasoning effort -- low, medium, high, xhigh, max. Per-call (safe to vary within a thread; unlike model it does not invalidate the cache). Lower = cheaper/faster; raise it for hard cross-file reasoning. show_steps: when true, append the exploration trail (which files it read, what it grepped) so you can see HOW it reached the answer and steer the next turn. Each answer ends with a [bridge] cost footer (call cost + cache hit rate, plus the thread's running total). Call bridge_cost for the full ledger. |
| bridge_costA | Report cumulative API cost of ask_codebase calls in this server process, broken down by thread plus a grand total. |
| bridge_forgetA | Drop a thread's session so the next call to that name starts fresh. Pass a thread name to forget just that one, or omit it to forget ALL threads. A call already in flight for that thread finishes but its state update is discarded. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools have clearly distinct purposes: ask_codebase for Q&A with turn-based steering, bridge_cost for cost reporting, and bridge_forget for thread management. There is no overlap in functionality.
Tool names follow a predictable pattern with an underscore separator, though the primary tool uses 'ask_' while the auxiliary tools use 'bridge_' prefix. This is a common and acceptable namespace convention but slightly deviates from a fully uniform verb_noun pattern.
With three tools, the count is appropriate for the server's focused scope of codebase Q&A with supporting cost and thread management. Each tool serves a necessary function without redundancy.
The toolset covers the full workflow: asking questions with thread support, tracking costs, and forgetting threads when needed. No obvious gaps exist for the stated purpose of exploring a codebase with a conversational agent.