Case study 03
MCP Router
One shared local MCP router instance for multiple coding-agent hosts, with cached capability lookup, isolated plugin runtimes, and measurable routed-vs-direct overhead.
clients
Clients
router
one mcp-router instance
resolve · cache · isolate · measure
cache / runtime / events
Cache
Runtime
Events
Fast proof
One local router instance lets multiple agents share the same MCP entry point while preserving measurable routing behavior and contained plugin failures.
One shared setup
Hosts point at the same router command instead of each carrying separate MCP/plugin wiring.
Context economy
Route cache and benchmark tools compare discovery-heavy calls with direct, explicit routed calls — economical routing stays measurable without claiming unreviewed savings.
Contained failures
Plugin drift, runtime errors, and stale manifests become warnings, doctor checks, and update commands.
Problem
Coding-agent hosts often duplicate MCP setup across every tool connection. A shared router reduces that sprawl by giving each host one stable MCP surface while keeping plugin routing, lifecycle, and recovery behavior explicit.
What it proves
Jeff can reduce agent-tool sprawl into one measurable local platform boundary, then use benchmarks and lifecycle checks to keep the convenience from hiding cost or failure modes.
Reliability pattern
Expose one stable router boundary for hosts, then resolve capabilities, isolate plugin runtimes, and measure routed paths before making efficiency claims.
Sanitized evidence
The benchmark receipt on this page is a sanitized shape of the comparison workflow. It shows the paths that are compared without publishing private benchmark exports or unreviewed numeric savings.
Privacy notes
This case study uses domain-safe labels for agent hosts, documentation context, repository intelligence, and plugin targets. It does not expose private repositories, internal plugin package names, hostnames, tokens, or raw benchmark exports.
View next case study
Small agents. Deterministic gates. Reviewable delivery.
Instead of loading every tool and rule into one agent, Pi routes repeatable work through CLI recipes, gives focused agents only the context they need, and requires isolated validation before QA handoff.