MCP Model Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BRIDGE_AGENTS_DIR | No | Where agent definitions live. | <root>/.github/agents |
| BRIDGE_GATEWAY_URL | No | Endpoint base URL of the inference gateway. When unset (or half-configured) the server runs the mock gateway and reports gateway: mock. Example values: https://openrouter.ai/api/v1, https://api.anthropic.com, or a corporate/self-hosted gateway base path. | (unset -> mock) |
| BRIDGE_GATEWAY_AUTH | No | Auth scheme: x-api-key or bearer. Defaults per schema (anthropic-messages -> x-api-key, openai-chat -> bearer); usually leave unset. | per schema |
| BRIDGE_MODEL_POLICY | No | Tier map and allow-list. Looked up in this order: BRIDGE_MODEL_POLICY if set, then <workspaceRoot>/.github/model-policy.json, then the bundled model-policy.json. | auto-discovered |
| BRIDGE_GATEWAY_TOKEN | No | Credential for the gateway, read from the environment only. Never placed in the repository, agent file or policy file. Issued by your inference provider (e.g. OpenRouter key, Anthropic API key) or by a corporate gateway's portal. | (unset -> mock) |
| BRIDGE_GATEWAY_SCHEMA | No | Request shape spoken by the gateway: anthropic-messages (path /v1/messages) or openai-chat (path /v1/chat/completions). A base URL already ending in /v1 is not doubled. | anthropic-messages |
| BRIDGE_WORKSPACE_ROOT | No | The host project. Root for path confinement and tool access. In practice only this variable needs setting; everything else is discovered. | process.cwd() |
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 |
|---|---|
| run_agentC | Executes an agent definition from the host project against a model you name. Returns the result plus the model actually used, so routing is verifiable. |
| list_agentsB | Reports the agents the host project offers, the model policy in force and where it came from, the tier map, the allow-list, and whether the gateway is live or mocked. |
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 2 tools
list_agents is a read-only introspection operation and run_agent is an execution operation, targeting entirely different actions on the same domain. There is no plausible way for an agent to confuse the two.
Both tools follow a clean verb_noun snake_case pattern (list_agents, run_agent) with the noun 'agent' consistent across the set. Fully predictable.
Two tools is thin even for a narrow bridge surface; a discovery call plus a single execution call leaves little room for inspecting, validating, or managing runs. Still, both tools clearly earn their place given the stated purpose.
The pairing of discover-agents and execute-agent covers the core read/run lifecycle, and run_agent returns the model actually used, closing the routing-verification loop. Gaps are minor and largely handled outside the server (agent definitions live in the host project), though there is no status, cancel, or batch execution path.