Server tools

Normally the calling harness owns the tool loop. With server tools, BitRouter advertises selected tools, intercepts their calls, executes them, appends the results, and calls the model again. The caller receives one final response.

Two gates

A server tool runs only when both conditions are true:

1. The deployment enables its implementation under server_tools.
2. The request declares that tool.

This prevents a configured capability from appearing on every request and prevents a caller from invoking an implementation the operator did not enable.

server_tools:
  max_iterations: 8
  advisor: true
  subagent: true
  mcp_servers: [workspace]

{
  "tools": [
    {"type": "bitrouter:advisor", "args": {"model": "anthropic:claude-opus-4.8"}}
  ]
}

Provider-defined declarations are carried by APIs that preserve provider tools, including Responses and Messages. Chat Completions accepts function tools only; use the bitrouter/fusion model alias when you need the Fusion shorthand on that surface.

Loop bounds

The default loop permits 10 tool rounds, 30 seconds per tool, 120 seconds for the turn, and three consecutive tool-error rounds. server_tools.max_iterations is the deployment-level override exposed in bitrouter.yaml.

Reaching a bound stops the loop instead of allowing unbounded model calls. Nested calls, searches, and fetches still consume their normal provider or backend quota.

Tool families

Toolsets keep those implementations provider-agnostic. Each toolset decides whether to advertise on a request and owns calls to its names; tools from different MCP servers are namespaced to avoid collisions.