Routing · category
What Is an MCP Routebook?
Dynamic routing is easy to build and impossible to review. A routebook trades a little cleverness for the ability to answer, on one screen, which servers can serve payment_capture and in what order.
The short answer
An MCP routebook is a declared, versioned artefact listing the candidate servers for each capability, in preference order, with the eligibility condition for each candidate and an explicit statement of what happens when none are eligible. It differs from a dynamic router in being readable and diffable, and from a registry in describing where a capability may run rather than what is approved to exist. Eight fields per entry, the eligibility-versus-preference distinction, and the fallback rule that prevents silent privilege escalation.
Key takeaways
- 01Declared beats derived. A routebook is reviewable on one screen; a dynamic router is only knowable by running it.
- 02Separate eligibility from preference. Residency and credential scope are filters. Cost and latency are tie-breaks. Confusing the two is how a compliance breach gets optimised into existence.
- 03The no-eligible-route clause is mandatory. Most routebooks omit it, and it is the field that matters at 3am.
- 04A fallback may never widen authority — equal or narrower credential scope, equal or stricter approval, or refuse.
- 05A routebook is code: owned, versioned, reviewed, rolled back. Not configuration in a console.
- 06Routebook and registry answer different questions. Registry: may this exist? Routebook: where may this run?
Why declare routes at all
Once two servers can serve the same capability, something has to choose. The obvious approach is to compute the choice at call time from live signals: health, latency, cost, load. This works, and it produces a system whose behaviour nobody can describe.
Ask a dynamic router which servers can serve payment_capture, in what order, under what conditions. The honest answer is that you would have to run it, with various inputs, and observe. That is a fine property for a load balancer moving stateless reads. It is a poor property for a layer that decides where money moves and in which jurisdiction.
A routebook makes the same decisions from a declared candidate set. Signals still choose among candidates, but the candidates, their conditions and their order are written down. You gain review, diff, rollback and the ability to answer the question on one screen. You lose the ability to automatically discover a route nobody authorised — which is not a loss.
This is the same trade that made static routing tables preferable to clever dynamic protocols in most enterprise networks, and declarative deployment preferable to imperative scripts. Predictability is worth more than adaptivity once consequences are real.
Key facts
- ▸A routebook is declared; a dynamic router is derived. Only the former can be reviewed before it runs.
- ▸Live signals still apply — they select among declared candidates rather than discovering candidates.
- ▸The question “which servers can serve this capability, in what order?” should be answerable without executing anything.
Eight fields per entry
One entry per capability. Eight fields, and the fifth is the one most implementations omit.
| Field | Example | Why it exists |
|---|---|---|
| Capability | payment_capture | The logical name the agent sees. Not a server-specific tool name, or the routebook breaks whenever a vendor changes theirs |
| Candidates, ordered | eu-payments-1, eu-payments-2 | The complete set of places this may run, in preference order. Nothing outside this list is reachable |
| Eligibility per candidate | region=EU, health=green, scope=capture-only | Hard filters. Applied before any optimisation, and never traded away |
| Preference signals | latency p95, then unit cost | How to choose among the eligible. Ordered, so ties resolve deterministically |
| No-eligible-route behaviour | refuse, alert on-call, do not widen scope | The clause that prevents a quiet failover into a broader credential. Mandatory |
| Approval requirement | amount > 5000 requires human approval | Route choice and approval threshold are adjacent decisions; keeping them in one artefact stops them drifting apart |
| Owner and version | v4, payments platform team | A routebook is code. It has an owner, a version and a review history |
| Review date | 2026-11-01 | Routebooks encode assumptions about capacity, cost and jurisdiction. All three change |
One capability from a real-shaped payments estate. Note that residency and credential scope appear as eligibility, never as preference — and that the fallback is narrower than the primary, not broader.
Candidate 2 is deliberately more constrained than candidate 1 — it carries an amount ceiling. That is the correct direction for a fallback. A fallback with a wider scope than the primary is a privilege-escalation path that presents itself as resilience engineering.
Eligibility is not preference
This is the single most important distinction in the artefact, and getting it wrong produces exactly the failure a routebook exists to prevent.
Eligibility is a filter. A request carrying EU personal data routes to an EU instance or it does not route. A write requiring capture-only scope goes to an instance whose credential is capture-only or nowhere. These are not weighted against anything. There is no cost saving that makes processing EU data in Virginia acceptable, and no latency improvement that justifies executing a payment on an instance with broader authority than the operation needs.
Preference is a ranking applied to what survives the filter. Cost, latency, load, freshness. All legitimate, all secondary.
Systems that model everything as a weighted score will, eventually, produce a high-scoring illegal route. Not through a bug — through working as designed, because a sufficiently large cost advantage outweighed a residency penalty that should never have been a penalty in the first place. Once a constraint has a price, it will be paid.
| Signal | Eligibility or preference? | Why |
|---|---|---|
| Data residency / jurisdiction | Eligibility | A legal fact, not a trade-off. It has no exchange rate |
| Credential scope match | Eligibility | Routing to a broader-scoped instance is privilege escalation |
| Health / circuit state | Eligibility | An unhealthy route is not a slower route; it is not a route |
| Data classification compatibility | Eligibility | Whether this instance may see PII is binary |
| Measured latency | Preference | Genuinely a trade-off, and it should be measured rather than inferred from region labels |
| Unit cost | Preference | A tie-break. Cost-first routing produces cheap wrong answers |
| Current load | Preference | Legitimate balancing among equals |
| Data freshness | Depends | Preference for reporting; eligibility when correctness depends on it, such as reconciliation |
Fallback chains that stay safe
Failover exists to preserve availability, and availability logic says find any route that works. Applied to agent actions with real consequences, that logic quietly upgrades privilege: the constrained instance is unhealthy, so the request lands on the general-purpose one whose credential can do considerably more. Nothing alerts, because from an availability standpoint the system did exactly what it was told.
Three rules keep a fallback chain honest.
- 01Monotonically narrowing authority. Each successive candidate has credential scope equal to or narrower than the one before it, and approval thresholds equal or stricter. Never wider. This is checkable statically — a linter can enforce it, and should.
- 02Refuse rather than widen. If no candidate is eligible, refuse. A refused payment is an operational problem somebody fixes in the morning; a payment executed by an over-scoped instance is an incident with a regulator attached.
- 03Test the chain by removing the primary, deliberately. An untested fallback is a hypothesis, and in practice it usually turns out to have been configured for a different purpose eighteen months ago by someone who has left.
- 04Alert on fallback use, every time. Falling back is not normal operation. If your dashboard shows steady fallback traffic, the primary is broken and nobody has noticed because the system is heroically compensating.
The linter point is worth dwelling on. Because a routebook is a declared artefact, “no candidate may have wider scope than its predecessor” is a static check you run in CI. That is a property a dynamic router simply cannot offer, and on its own it justifies the declarative approach for anything touching money or personal data.
Built on this thinking
Routebooks as versioned artefacts, not console settings
Barzel Central Gateway holds routebooks as versioned, reviewable artefacts — eligibility evaluated as filters before cost and latency tie-breaks, explicit no-route behaviour, and the selected route recorded alongside the policy decision in the audit line.
Routebook, registry, router
Three artefacts, three questions. Conflating them is common and it produces architectures where nobody can say which component owns a decision.
Registry — may this exist?
The catalogue of approved servers and tools, with owner, risk class, pinned version and entitlement. Governs existence and permission. See the enterprise MCP registry.
Routebook — where may this run?
Candidate routes per capability with eligibility and order. Governs placement. Reads from the registry: a server not approved cannot be a candidate.
Router — where is it running right now?
The runtime component that applies the routebook, evaluates live signals and selects. Governs execution, and holds no policy of its own.
The dependency runs one way: registry → routebook → router. A candidate that is not in the registry is not a candidate, and a router with routes not in the routebook is a router that has escaped review. Both of those are checkable, and both are worth an alert.
Five mistakes worth naming
No no-route clause
The omission that produces the 3am incident. State it explicitly, and make it refuse.
Fallbacks with wider scope
Resilience engineering that is actually privilege escalation. Lint for monotonic narrowing.
Server-specific tool names as capability keys
The routebook then breaks whenever a vendor renames something. Use logical capability names.
Routebook in a console, not in version control
Unreviewable, undiffable, and impossible to roll back cleanly. It is code.
Entries with no review date
They encode assumptions about cost, capacity and jurisdiction. All three expire.
Where a routebook is the wrong tool
For a single-server estate a routebook is pure overhead. One capability, one place it runs, nothing to declare. Write one when a second candidate appears — not in anticipation.
Routebooks are also poorly suited to genuinely high-cardinality routing: thousands of shards, per-tenant instances, ephemeral compute. Declaring candidates by name stops scaling somewhere in the low hundreds. At that point the right shape is a declared rule for deriving candidates plus declared eligibility, which keeps the reviewable property while dropping the enumeration.
And a routebook is only as truthful as its eligibility metadata. If a candidate is labelled scope=capture-only and the credential actually permits refunds, the routebook confidently enforces a fiction. Eligibility claims need to be verified against the backing system periodically, not trusted because someone typed them once.
Frequently asked questions
What is an MCP routebook?
A declared, versioned artefact listing the candidate servers for each capability in preference order, with the eligibility condition for each candidate and an explicit statement of what happens when none are eligible. It makes route selection reviewable before it runs.
What is the difference between a routebook and a dynamic router?
A routebook declares the candidate set, their conditions and their order, so it can be read, diffed, reviewed and rolled back. A dynamic router derives the choice at call time, so its behaviour is only knowable by running it with various inputs and observing.
What fields does a routebook entry need?
Eight: capability name, ordered candidates, eligibility condition per candidate, preference signals, no-eligible-route behaviour, approval requirement, owner and version, and a review date.
What is the difference between eligibility and preference in routing?
Eligibility is a hard filter — data residency, credential scope match, health, data classification. Preference is a ranking applied to whatever survives the filter, such as measured latency and unit cost. Modelling residency as a weighted preference means a large enough cost advantage will eventually outweigh it.
What should happen when no route is eligible?
Refuse, with a distinct error code, and alert. Never widen a constraint to find a match. This clause is the one most routebooks omit and the one that matters during an incident.
Can a fallback route have wider permissions than the primary?
No. Each successive candidate must have credential scope equal to or narrower than its predecessor, and approval thresholds equal or stricter. Because a routebook is declared, this is a static check you can enforce in CI — which a dynamic router cannot offer.
What is the difference between a routebook and an MCP registry?
The registry answers whether a server may exist and who may use it. The routebook answers where a capability may run. The dependency runs one way: a server not approved in the registry cannot be a routebook candidate.
Should a routebook live in version control?
Yes. A routebook is code — it has an owner, a version, a review history and a rollback path. Held in a vendor console it becomes unreviewable and undiffable, which removes the property that made declaring routes worthwhile.
When is a routebook unnecessary?
For a single-server estate, where there is one place each capability runs and nothing to declare. Write one when a second candidate appears rather than in anticipation.
Do routebooks scale to thousands of routes?
Enumerating candidates by name stops scaling in the low hundreds. Above that, declare a rule for deriving candidates plus declared eligibility conditions — this keeps the reviewable property while dropping the enumeration.
Glossary
- MCP routebook
- A declared, versioned artefact listing candidate servers for each capability in preference order, with eligibility conditions and explicit no-route behaviour.
- Eligibility condition
- A hard filter a candidate route must satisfy to be considered at all, such as data residency or credential scope — never traded off against cost or latency.
- Preference order
- The ranking applied among candidates that have already passed every eligibility filter.
- No-route behaviour
- The declared action when no candidate is eligible: refuse and alert, never widen a constraint to find a match.
- Capability
- The logical action an agent wants to perform, distinct from the specific tool or server implementing it.
Sources and further reading
The declared-over-derived argument follows established routing and policy-as-code practice, cited below. The routebook artefact, its eight fields and the eligibility/preference separation are our own design, implemented in Barzel Central Gateway.
- 01 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 02 · Kubernetes projectKubernetes — cluster architecture ↗The canonical control-plane / data-plane separation, and the closest well-understood analogue.
- 03 · CNCFOpen Policy Agent — documentation ↗Reference implementation of decoupled policy decisions and policy as code.
- 04 · GoogleGoogle SRE — Service Level Objectives ↗Why an estate needs objectives and error budgets, not just dashboards.
- 05 · EU AI Act (unofficial consolidated text)EU AI Act — full text ↗Obligations around logging, human oversight and traceability for higher-risk systems.
- 06 · OpenTelemetryOpenTelemetry — GenAI semantic conventions ↗Emerging standard attribute names for model and tool-call telemetry.
- 07 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 08 · SemVerSemantic Versioning 2.0.0 ↗The versioning contract tool schemas should honour but frequently do not.
Last reviewed 2 September 2026. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). What Is an MCP Routebook?. Real Biz Digital. https://realbizdigital.net/insights/mcp-routebook/
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so an evaluation costs an afternoon rather than a purchase order.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Community | Free | 1,000 tool calls/mo · full policy engine, registry, audit | Evaluating the estate, or a single team proving the path works |
| Starter | $10/mo | 10,000 calls/mo | One or two production agents against a handful of servers |
| Team | $79/mo | 100,000 calls/mo | A platform team governing an estate of 5–20 servers |
| Business | $149/mo | 250,000 calls/mo | Estate-wide governance with SIEM evidence and multi-team routing |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.