​

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: 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 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. 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 and execution sequence for placement and checks.

​

Different workloads, different contracts

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: 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. 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 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 explains discovery, model selection, execution ordering and trust boundaries.
2. Evidence and limitations 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: 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, integration choices and security and trust boundaries. The SDK is a published Node.js ESM package, not a hosted router, browser runtime or bundled local-inference service.