MCP Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCPBRIDGE_CONFIG | No | Points the bridge at an alternative config file instead of the default ~/.config/mcpbridge/config.json |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_agentsA | List the AI agents this bridge can delegate to, and whether each one is usable right now. Check this before delegating: "available": false carries the reason, such as a CLI that is not installed or an Ollama that is not running. |
| ask_agentA | Hand a task to another AI agent and wait for its answer. One call does the whole thing. The agent starts fresh with no knowledge of this conversation and cannot see your files unless you point it at them, so make the prompt self-contained and pass workingDirectory when the task is about code in a project. If "succeeded" is false, read "diagnostics". For a job long enough to outlast this request, use start_task. |
| start_taskA | Start a delegated task and return its id immediately, for work that would outlast this request. Poll get_task with the id. Prefer ask_agent for anything that finishes in a minute or two — it is one call instead of several. |
| get_taskA | Look up a task started with start_task. While "status" is "running" the agent is still working — wait before asking again rather than polling in a tight loop. Once it is "finished", "result" holds the same shape ask_agent returns. |
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 4 tools
Each tool has a distinct role: list_agents discovers targets, ask_agent is synchronous delegation, start_task is asynchronous delegation, and get_task polls an async task. The descriptions explicitly disambiguate the one risky pair (ask_agent vs. start_task) with concrete guidance about which to prefer.
All four tools follow a consistent snake_case verb_noun pattern (list_agents, ask_agent, start_task, get_task) with matching singular/plural conventions. No mixed styles or vague verbs.
Four tools is a tight, well-scoped surface for a delegation bridge: discovery, sync call, async start, and poll. Nothing feels redundant or padded.
The core sync and async delegation lifecycle is covered, but there is no cancel/abort operation for a task started with start_task, leaving an agent stuck polling a runaway task with no exit. A cancel_task tool is an obvious gap for an async workflow.