Server tools

Normally your agent runs the tool-calling loop: the model asks to call a tool, your harness executes it, appends the result, and calls the model again. Server tools move that loop into Routeplane. You declare a set of tools, Routeplane advertises them to the model, and when the model calls one, Routeplane executes it and feeds the result back itself — looping until the model stops calling them. To the caller it looks like a single response.

How the loop runs

Routeplane injects the declared tools into the outbound request, intercepts the model’s calls to them, runs them, appends the results, and re-calls the upstream — repeating until the model returns an answer with no tool calls, or a bound is hit. The loop is bounded so it can’t run away:

Bound	Default	Meaning
`max_iterations`	10	Maximum tool rounds before the loop stops.
`tool_timeout`	30s	Per-tool execution timeout.
`total_budget`	120s	Wall-clock budget for the whole loop.
`max_consecutive_errors`	3	Stop after this many back-to-back tool failures.

Before each call, an approval policy decides whether the tool may run. The default allows everything; a denied call returns an execution-denied result to the model instead of running.

Enabling server tools per request

You turn server tools on by declaring them in the request’s tools array — no config change required. Routeplane recognizes three built-in, model-backed tools and only advertises the ones you declare:

{
  "tools": [
    { "type": "routeplane:advisor",  "args": { "model": "anthropic/claude-opus-4.8", "instructions": "..." } },
    { "type": "routeplane:subagent", "args": { "model": "openai/gpt-4o-mini", "instructions": "..." } },
    { "type": "routeplane:fusion",   "args": { "panel": [{ "model": "..." }], "judge": { "model": "..." } } }
  ]
}

A fourth built-in, Web search, works the same way — declare routeplane:web_search to give the model a search backed by a key you bring.

MCP-server tools are wired through configuration instead — set server_tools.mcp_servers to the servers whose tools Routeplane should run inside the loop.

Model-backed tools

Three of the built-ins wrap a nested model call instead of an external side effect. Each gets its own page:

Advisor — the running model consults a stronger model on one hard sub-question mid-generation, without escalating the whole request.
Sub-agent — the model delegates a self-contained task to a cheaper, faster worker that runs in isolation and returns only its result.
Fusion — a panel of models answers in parallel, a judge compares (not merges) their answers, and the calling model writes the final reply from that analysis.

Advisor, Sub-agent, and Fusion are each backed by model calls nested inside your request. They cost what their underlying model calls cost, and they appear in your usage history like any other call.

How tools are bundled: toolsets

A toolset is the seam that makes router-run tools provider-agnostic. Each toolset answers two questions for a request — which tools to advertise, and how to run a call to one of them — and Routeplane composes several into the single set the model sees.

Routeplane keeps a registry of toolsets; when the model calls a tool, the registry routes the call to the toolset that owns that name. Because several toolsets can be active at once, tool names are prefixed to avoid collisions — the search tool from the demo server is advertised as demo__search.

Toolsets come in three kinds:

MCP-backed — one per upstream MCP server; its tools are the server’s tools, run through the gateway.
Model-backed — Advisor, Sub-agent, and Fusion, each wrapping a nested model call.
In-process — tools implemented directly in the router.

A toolset doesn’t have to advertise on every request. It can check what the caller declared and stay silent otherwise — which is how the model-backed tools work: Advisor only appears when the request declares routeplane:advisor, and likewise for Sub-agent and Fusion. The model only ever sees the tools that request actually opted into.