> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcprouter.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Whitepaper overview

> Why agent reasoning and tool execution need separate responsibilities, and what mcprouter implements today.

# mcprouter: Separating agent reasoning from governed tool execution

> **Documentation for v0.0.1.** Additional guides and API reference coverage are being expanded.

Whitepaper revision 3 · October 27, 2026 · SDK scope: published `0.0.1`

**A bounded execution layer for tool-using agents.** Keep reasoning in the host, make the decision to dispatch explicit, and use MCP as the interoperability boundary.

## Abstract

An agent can produce a plausible plan without having permission to carry it out. Connecting a language model to business tools therefore creates two distinct problems: selecting a useful action and deciding whether that exact action may execute. Treating both as prompt instructions leaves the application without an explicit enforcement point.

mcprouter separates these responsibilities. It is an in-process Node.js SDK for Model Context Protocol (MCP) tool discovery, ranking and governed execution. The host supplies trusted identity, policy, tool connections and optional model adapters. Models can propose actions; the router validates inputs, checks the current tool binding and applies host policy before dispatch.

This separation makes a specialized routing model an architectural option, not a prerequisite. Exact calls need no model. Model-assisted execution can abstain or request clarification and permits at most one governed tool call per `execute` operation. The host retains responsibility for planning, approvals, multi-step workflows and recovery.

Current evidence supports a qualified warm lexical-filtering result and finite routing-evaluation outcomes. It does not establish a universal speedup, cost reduction, small-model advantage or guarantee of semantic correctness. The contribution is an explicit execution boundary that applications can inspect and test independently of a model's reasoning ability.

## Executive summary

Tool-using agents retrieve records, query databases, call business APIs and change external state. Planning those activities is different from checking the current tool contract, validating arguments, applying policy and handling a transport failure. Making a reasoning model responsible for both mixes open-ended judgment with operations that need explicit rules.

The execution-layer approach moves those checks into application infrastructure. A host can change its reasoning model without delegating authority to that model, and it can use the same governed call path for actions selected by ordinary application code. Model-assisted selection remains optional; multi-step planning remains outside the router.

The design has three aims. They describe mechanisms and evaluation questions, not three measured benefits:

> **Efficiency**
>
> Expose a relevant, eligible tool scope instead of every schema. Measure whether reduced model work outweighs selection and routing overhead.

> **Reliability**
>
> Check schemas, current bindings and structured outcomes explicitly. A valid call can still be the wrong action or fail in the underlying service.

> **Governance**
>
> Apply host policy to the exact action before dispatch. Approval, identity, audit retention and service-side access controls remain host responsibilities.

MCP, JSON-RPC, JSON Schema, retrieval and authorization are established technologies. This paper explains their composition and operating boundaries; it does not claim that each component is novel or that the composition makes model behavior deterministic.

## The problem: capability is not authority

MCP standardizes how clients discover and call tools. A tool's schema describes its inputs; it does not establish who may use it, which customer records they may access, or whether an operation requires approval. The [MCP tool specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) describes access-control and confirmation responsibilities alongside the protocol.

As a catalogue grows, applications also need to select relevant tools without treating every description as trusted instruction. Retrieval can reduce the candidate set presented to a model, but a high relevance score is not an access decision. A model may choose the right tool with the wrong resource identifier, or a valid request may target a tool whose binding has changed.

mcprouter addresses these cases by separating discovery, relevance, proposal, validation and authorization. This does not eliminate model errors or replace security controls in the underlying service. It makes the application's decision to dispatch explicit rather than implicit in generated text.

## Two responsibilities, not two classes of model

The terms **System 1** and **System 2** serve here as architectural analogies. System 2 describes the host's deliberative role: interpreting goals, choosing plans and deciding when more information is needed. System 1 describes a constrained action-selection role operating within a host-defined tool and policy scope. Neither term is an API mode, a psychological claim about software, or a measured latency category.

```mermaid theme={null}
flowchart TB
  H[System 2: host reasons and plans] -->|Goal or exact call plus trusted context| R[System 1: mcprouter selects, validates and governs]
  R -->|Allowed tool call via MCP| S[MCP server: tools and services]
  S -->|Tool result| R
  R -->|Outcome or no dispatch| H
```

*Figure 1. Reasoning, governed execution and MCP interoperability. The host sets the goal and trusted context; mcprouter returns an outcome, including cases where no action starts. This conceptual MCP path is not a timing diagram or a separate hosted router. Local handlers are another dispatch option. See the [topology](https://docs.mcprouter.dev/whitepaper/architecture.md#mcp-connects-capabilities-the-host-owns-the-application) and [execution sequence](https://docs.mcprouter.dev/whitepaper/architecture.md#the-execution-sequence) for placement and checks.*

### Different workloads, different contracts

| Dimension | Reasoning workload | Governed execution workload |
| - | - | - |
| Primary objective | Interpret an ambiguous goal and choose a strategy | Dispatch only a structurally valid, currently bound and permitted action |
| Information need | Task history, domain context and alternative plans | Selected tool contract, arguments and trusted authorization context |
| Failure mode | Misunderstood intent or an unsuitable plan | Invalid arguments, stale bindings, denied access or uncertain side effects |
| Optimization target | Quality of decisions and task completion | Validity, policy enforcement and bounded work; measure latency separately |

These responsibilities complement each other. Execution checks cannot repair a mistaken goal; a good plan cannot substitute for authorization. The execution layer uses **explicit, code-enforced checks**, not prompt-only instructions. Schema checks can be deterministic for fixed inputs; current bindings and host policy decisions can depend on changing state. The architecture does not promise repeatable model choices, identical external results, constant latency or exactly-once effects. Host policy code must itself be trustworthy.

Three variables must remain separate:

| Variable | Meaning | What it does not establish |
| - | - | - |
| Model size | Parameter count, architecture and deployment footprint | Accuracy on a particular tool catalogue |
| Reasoning budget | Inference settings, token budget and permitted processing | Authorization or a fixed relationship to model size |
| Architectural role | The scope of decisions delegated to a component | A requirement to use a small or local model |

A model with 1–8 billion parameters could be evaluated for the routing role. The measurements in this paper do not qualify that size range. A larger model with a limited output budget is not evidence for a smaller model, and constrained output is not proof of correct intent interpretation.

## The frontier-model tax: three sources of overhead

The original framing calls this the **Frontier Model Tax**: model work spent on low-level tool mechanics rather than deciding what the user needs. It is architectural shorthand, **not a measured industry metric**. These costs can affect smaller models too; the term does not establish that a frontier model is the wrong choice.

> **Context tax**
>
> Tool names, descriptions and schemas compete with task context. Narrowing the exposed set may reduce prompt work, but retrieval has its own cost.

> **Generation tax**
>
> Model-generated arguments consume output tokens. An exact host call avoids that inference step only when application code already knows the action and inputs.

> **Recovery tax**
>
> Malformed calls or missing facts can add repair attempts or host turns. Bounded repair and clarification make these paths explicit; they do not eliminate them.

Moving work changes where costs occur; it does not make them disappear. A routing model adds inference, discovery may require network activity, and validation and policy consume runtime work. Compare complete workflows, including failed and abandoned attempts, before claiming savings. The [cost-accounting method](https://docs.mcprouter.dev/whitepaper/evidence-and-limitations.md#economics-must-include-the-complete-workflow) separates these costs from the retained filtering benchmark and the illustrative small-model scenarios.

## Where the separation is useful

The design fits applications that need multiple tool sources, explicit tenant or resource restrictions, and a consistent record of whether an action started. Examples include customer-support assistants, internal operations tools and domain-specific copilots. These are use cases, not claims of production adoption.

Consider a balance enquiry. The host authenticates the customer and restricts the eligible billing tool. A routing model may propose the balance lookup and its arguments. Before dispatch, policy checks the proposed customer identifier against trusted host context. If the identifier is missing, clarification is preferable to fabrication; if it belongs to another customer, schema validity does not make access permissible.

Not every application needs model-assisted routing. If application code already knows the exact action and arguments, a direct governed call avoids an unnecessary inference step. If a workflow needs a directed acyclic graph (DAG), parallel tools, transactions or a browser agent, the host must supply that orchestration. mcprouter `0.0.1` does not implement those capabilities as an autonomous runtime.

## Document scope and reader guide

This is a technical explanation for agent developers, engineering leaders and security reviewers, not a catalogue of guaranteed production outcomes. This overview and two companion chapters cover the published SDK's boundaries, qualified evidence and open design questions:

1. [Architecture](https://docs.mcprouter.dev/whitepaper/architecture.md) explains discovery, model selection, execution ordering and trust boundaries.
2. [Evidence and limitations](https://docs.mcprouter.dev/whitepaper/evidence-and-limitations.md) separates measured results from hypotheses and sets out a practical evaluation method.

Use this map to follow the original paper's seven questions without reading seven separate documents:

| Topic | Reader question | Start here |
| - | - | - |
| Foundations | Why separate reasoning from tool execution? | [Responsibilities](https://docs.mcprouter.dev/whitepaper/overview.md#two-responsibilities-not-two-classes-of-model) |
| Architecture | Where does the router sit relative to MCP? | [MCP topology](https://docs.mcprouter.dev/whitepaper/architecture.md#mcp-connects-capabilities-the-host-owns-the-application) |
| Execution | How do selection, validation, policy and dispatch interact? | [Execution sequence](https://docs.mcprouter.dev/whitepaper/architecture.md#the-execution-sequence) |
| Security | Who controls identity, approvals and side effects? | [Security and trust](https://docs.mcprouter.dev/guides/security-and-trust.md) |
| Evaluation | What has been measured, and what is still hypothetical? | [Evidence and limitations](https://docs.mcprouter.dev/whitepaper/evidence-and-limitations.md) |
| Operations | What must the application own in deployment and recovery? | [Operational ownership](https://docs.mcprouter.dev/whitepaper/architecture.md#deployment-choices-and-operational-ownership) |
| Future directions | How should a specialized small-model router be qualified? | [Open hypothesis](https://docs.mcprouter.dev/whitepaper/evidence-and-limitations.md#the-small-model-hypothesis-remains-open) |

Future directions are evaluation proposals, not a release commitment. The public paper uses explanatory prose and aggregate results; it does not distribute private datasets, model weights, raw traces or the original PDF.

For implementation rather than architectural analysis, use [installation](https://docs.mcprouter.dev/start/install.md), [integration choices](https://docs.mcprouter.dev/start/choose-integration.md) and [security and trust boundaries](https://docs.mcprouter.dev/guides/security-and-trust.md). The SDK is a published Node.js ESM package, not a hosted router, browser runtime or bundled local-inference service.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.