Server tools
Enable server-tool implementations, select MCP upstreams, and configure loop limits and web backends.
Configure server_tools in the configuration file to make implementations available. Each request must still declare the tools it wants. Server tools in Context documents those request declarations and execution behavior.
Enable implementations
server_tools:
max_iterations: 8
advisor: true
subagent: true
mcp_servers: [workspace]advisor and subagent enable nested model calls. mcp_servers selects configured upstreams for use inside the router's tool loop.
Loop limits
server_tools.max_iterations overrides the deployment's tool-round limit. The default loop permits 10 tool rounds, 30 seconds per tool, 120 seconds for the turn, and three consecutive tool-error rounds. The iteration limit is the override exposed in bitrouter.yaml.
A loop bound stops additional tool rounds. Nested calls and backend requests still consume their normal quota and cost.
MCP-backed tools
Declare transports in MCP connections, then select their ids for the server-tool loop:
server_tools:
mcp_servers: [filesystem, context7]
max_iterations: 6An upstream's presence in mcp_servers alone does not opt it into this loop.
Model-backed defaults
server_tools:
advisor: true
subagent: true
fusion:
panel:
- anthropic:claude-opus-4.8
- openai:gpt-5
judge: anthropic:claude-opus-4.8Advisor and Sub-agent use the parent request model unless their declaration pins another model. Fusion defaults come from the deployment block and can be overridden by an explicit declaration.
Web backends
server_tools:
web_search:
max_results: 5
backends:
- kind: parallel
- kind: exa
- kind: firecrawl
- kind: tavily
web_fetch:
max_content_tokens: 4000
backends:
- kind: exa
- kind: firecrawl
- kind: tavilyEach HTTP backend reads an explicit api_key or its conventional environment variable:
| Backend | Search | Fetch | Environment variable |
|---|---|---|---|
| Parallel | Yes | No | PARALLEL_API_KEY |
| Exa | Yes | Yes | EXA_API_KEY |
| Firecrawl | Yes | Yes | FIRECRAWL_API_KEY |
| Tavily | Yes | Yes | TAVILY_API_KEY |
Backends are tried in config order. Entries with no resolvable key are skipped; if none resolve, that tool remains disabled and the daemon logs why.
Web Search also supports a native backend that runs a search-capable model with its provider-native search tool. That is a nested model call rather than an HTTP search API.
Validate and apply
bro config validate -c bitrouter.yaml
bro reload -c bitrouter.yamlThen send a request with an explicit tool declaration from Server tools in Context. Verify the selected backend and any nested model calls using Telemetry.
Deployment enablement does not grant caller access, upstream credentials, network reachability, or tool approval. Keep those boundaries scoped to the callers that need them.
How is this guide?