🛠️ Twilight of the MCP Idols

How to Philosophize with a Protocol (part one)

Platforms are still rolling out MCP support like it’s the future. GitHub Copilot added MCP integration in mid-February. Supabase launched the ability to install MCP servers on Claude web and desktop. The announcements keep coming, partnerships keep forming, with Model Context Protocol being treated like the inevitable standard for AI tool integration. But, the paradigm it was built for is already being superseded.

Model Context Protocol was designed for a world where agents call predefined tools with known interfaces. It seemed like a good idea at the time.™ You build a server, expose capabilities, agents discover and invoke them. It’s clean, it’s standardized, it’s infrastructure you can reason about. It was supposed to be the future. Still is, depending who you ask. But 15 months later, it hasn’t really taken off the way it was supposed to. Spoiler: it’s taking off in a completely different way.

It doesn’t just demand predefined tools; it necessitates a curated registry. And registries live or die by discovery. But discovery is a trap; it entails organization, which in turn entails hierarchies, namespaces, and naming conventions. Every one of those layers, built out of metadata. To ensure a model actually picks the right tool, you have to account for every schema, every argument, and every edge case with somewhat agonizing clarity. All that overhead, the names, the descriptions, the structural scaffolding, is eventually shoved into the context window. Before the agent has even begun to think, it’s already choking on the user manual for its own toolbox.

Model Context Problematic

MCP externalizes complexity into structure, and that structure has to live inside the model’s operating bandwidth.

While tool-centric models sound elegant in theory, in practice this paradigm creates drag. Each new edge case requires another tool. Every tool expands the registry. Context explodes. Maintenance spirals. And inevitably, agents encounter work that requires a capability that simply doesn’t exist yet. At some point the system stalls, not because the agent lacks reasoning ability, but because the infrastructure hasn’t pre-approved the interface, or the overhead overwhelms the model’s ability to call it.

This is where organizations committed to MCP are running into a wall. It’s often framed as an operational overhead problem: too many tools, too much maintenance. But that’s just the surface effect; the deeper issue is a stack-level misalignment: MCP pushes capability description into the prompt layer, where it has to compete with the model’s limited operating bandwidth. Every capability must be named, documented, parameterized, and injected into the context window before it can be used. The result is a compounding context tax of tens of thousands of tokens spent not on reasoning, but on explaining to the model what it’s allowed to do.

That overhead creates a second-order problem: selection. As the registry grows, agents don’t just gain capability, they inherit ambiguity. Developers respond by gating exposure, turning tools on and off, segmenting registries by task, user, or environment just to keep the model from making the wrong call. What was supposed to be a universal interface collapses into manual routing. (And routing is always problematic.)

This creates a structural auth problem. Friction arises because we are asking the tool registry to carry the weight of the entitlement model: to keep the agent moving, you are forced to over-provision it. Because the registry lacks a unified model for composition, you end up granting broad, ambient credentials simply to avoid a permission-check stall mid-task. It’s the choice between a safely lobotomized agent or a dangerously over-privileged one. By treating authority as an external dependency rather than an architectural constraint, the registry creates a surface area that is technically integrated but morally incoherent. It can validate the call, but it cannot verify the intent. The result is a system that scales its surface area faster than it scales its usability: more tools, more tokens, more routing logic, more auth edge cases. At some point, the agent doesn’t fail because it lacks capability; it fails because the infrastructure required to describe that capability overwhelms it.

Critics often point to MCP’s ‘externalization’ of authentication as a design flaw, but that’s an architectural misreading: MCP isn’t an Identity Provider (IdP); it’s a transport protocol. Think of MCP as providing the Passport, but it doesn’t issue the Visa. And when the visa is missing, the system doesn't stall gracefully, it hands an agent the keys to the kingdom. Structurally, ambient credentials are granted not because the agent earned them, but because the alternative is a permission-check stall at every border crossing.

The Tool Generation

The real architectural shift is not from heavy to disposable infrastructure; it’s from registry management to execution governance.

The engineering response to this structural failure hasn’t been unified. Two distinct approaches have arrived at the same wall from different directions, carrying different diagnoses and different remedies.

The first alternative sidesteps the registry entirely by dropping to a lower level of abstraction. Simon Willison has been the most sustained and credible voice here, and while he introduced the argument in early 2023, before MCP was a glimmer in David Soria Parra’s eye, it's having a viral renaissance. The driver is a back-to-basics rebellion against registry bloat: when an MCP server requires 50,000 tokens of schema to do what a CLI command does in 200, the context tax drives you into contextual bankruptcy. CLI doesn't replace the registry with a better execution model; moisturized and unbothered, it just ignores it. Shell commands have no registry entry. A Unix pipe chain requires no curated namespace. You write it, the model executes it. And critically: the model is good at this in a way that is not equally true of composing novel tool call chains. MCP isn’t represented in the model’s training set because it was literally invented at the end of 2024. But models have been trained on the entire public history of Unix shell scripting, however: every pipe, every flag, every composition pattern ever documented in every O'Reilly bible relegated to your back closet or donated to your local hacker house, since you can ask an LLM faster than you can look anything up. That’s a deep prior, and it shows in practice. Perplexity CTO Denis Yarats recently announced (internally) they were abandoning MCP in favor of CLI. Shell-native agent patterns are architecturally underrated precisely because they draw on capability the model already has, not needing to be injected at runtime through schema descriptions.

But where the CLI relies on existing priors, a second tradition replaces static infrastructure with adaptive infrastructure: tool-generation. Instead of humans defining every interface in advance, the AI defines the interface in response to the problem. This shift, from tool-calling to tool-generation doesn’t so much extend MCP as pressure it toward its final boss form.

Pydantic’s Monty, a Python interpreter in Rust purpose built specifically for AI, flips the direction of abstraction. Agents don’t call tools from a predefined registry; they generate them. They write the code, execute it inside a constrained environment, retrieve the result, and discard the artifact. There is no persistent catalog to maintain, no discovery layer to inject into context, no long-lived interface contracts to curate. The capability exists only for the duration of the task and disappears when the task completes. That is obviously a materially different operating model. What’s less obvious is whether this approach requires abandoning the protocol or simply rethinking what it’s for.

It would be naïve, however, to suggest that tool generation “just” requires a sandbox. A trusted execution environment is necessary, but it’s not sufficient. Models can hallucinate logic, make incorrect assumptions, write inefficient or dangerous code, or attempt operations outside their intended scope. The real architectural shift is not from heavy to disposable infrastructure; it’s from registry management to execution governance. Instead of maintaining an ever-expanding inventory of predefined capabilities, you constrain what can be executed (by enforcing strict runtime guarantees: resource limits, capability gating, I/O control, and isolation boundaries.)

Overcoming Structural Inertia

Momentum is flowing from the compounded accumulation of persistent catalogs toward operationalized containment.

The difference is quintessentially structural. Tool registries accumulate surface area over time. They grow, ossify, and eventually become a maintenance burden embedded directly inside the model’s context window. Tool generation, by contrast, avoids persistent capability sprawl but demands a tightly controlled execution substrate. One model compounds through accumulation. The other operates through containment. That’s the architectural tradeoff, and it’s not exactly trivial in either direction.

The platforms adding MCP support in 2026 aren’t wrong to do so. MCP still solves real problems for enterprise contexts where predefined tools with audit trails matter. Financial services doesn’t want agents generating ad-hoc database queries. Healthcare doesn’t want agents writing tools that touch patient data without explicit permission models. For regulated industries, tool use with its paper trail and defined boundaries is a feature, not a limitation, though it does come with a cost.

But for the majority of use cases? From data transformation and API calls to file operations and computation, tool generation promises to be faster, simpler, and doesn’t require increasingly crufty infrastructure. Why maintain an MCP server that exposes a CSV parsing tool when the agent can just write the parser it needs for the specific CSV format it encountered? The salient question at that point is why not just use a CLI tool.

The momentum behind MCP might just be inertia. Organizations announced support months ago. Engineering teams built integrations. Product roadmaps got written. None of that stops just because the paradigm shifted. The question is whether we’re seeing genuine adoption or just the slow realization that the architecture doesn’t fit the problem anymore. Desktop clients like Creature.run perfectly illustrate the inertia vs. momentum thesis. They let teams build and share interactive MCP Apps (React widgets as predefined tools) with slick tabbed UIs and shared state between human/agent. Enterprise catnip (local storage, SOC2, per-seat pricing) but potentially pure inertia: more beautiful scaffolding compounding registry surface area, seducing teams to invest in exactly what MCP can’t sustain. Meanwhile momentum is flowing from the compounded accumulation of persistent catalogs toward operationalized containment.

Architecture and Morality

If your agents are going to generate and execute code, you need a runtime that can’t be exploited even when the code is wrong.

The trust boundary is where the CLI and tool-generation traditions stop being parallel conversations and start mapping onto a two-dimensional space: flexibility on one axis, governance on the other.

CLI sits at maximum flexibility, minimum governance. The system’s Hands. For an agent operating within a single principal's environment on reversible operations, CLI is not merely functional, but naturally self-enforcing. CLI enforces correctness architecturally, with no room for ambiguity. Exit codes are a contract. Stderr is a first-class signal. Idempotency is baked into the conventions. Piped commands either compose or they fail loudly; there is no silent middle state where something half-worked and left the system corrupted. The architecture itself is the governance layer. You don't need an entitlement model when the operations are atomic, reversible, and scoped to a single principal's environment, because the shell will tell you exactly what happened and exactly what didn't. This deep structural virtue of CLI is why shell-native agent patterns work as well as they do in contained contexts.

But that virtue only holds when the environment is contained. CLI has no entitlement model because it never needed one. MCP’s process isolation, scoped credentials, and audit trails are an answer to the question CLI was never designed to ask: on whose authority did this agent act, and how do we know? Underneath the registry MCP was being asked to maintain, authority and capability are distinct layers with different operational envelopes, and conflating them in the same interface was the registry’s fatal mistake. When the agent is operating on a production database twelve teams depend on, ambient correctness becomes ambient liability. Nothing in the architecture distinguishes a reversible operation from an irreversible one, a local file from a shared dependency, a test environment from production. Allowing CLI to be the entitlement layer is what produces ‘delete root’ hallucinations: the architecture was never designed to ask who authorized the action in the first place.

Tool-generation without a protocol is the mirror failure. A brain without a passport is ungovernable at scale. Ephemeral code execution is powerful precisely because it is opaque, synthesized on the fly, discarded after one-time use. This same opacity is a feature in a single-principal context and a liability in a multi-principal one. It’s a Rumsfeldian problem: you cannot audit what has left no trace of its execution.

In Runtime We Trust

Inertia tends to force tradeoffs. Momentum tends to favor convergence.
MCP governs the envelope; runtime governs its execution.

Anthropic’s Programmatic Tool Calling (announced 18 Feb) points toward a synthesis. Instead of agents discovering tools at runtime through MCP, you define tool schemas programmatically and the model decides when to invoke them. Halfway between predefined tools and generated tools: structured enough for audit trails, flexible enough to adapt to context. Whether it becomes the new standard or just another transition point depends on whether it solves the trust problem.

Because that’s what MCP always needed to solve: trust. (Thankfully, no one suggested using a blockchain for this.) If agents are going to operate autonomously, humans need to understand what capabilities they have access to. Predefined tools with known interfaces provide that understanding. Generated tools are opaque until they execute. The trust model breaks.

Except the trust model already broke. Agents with access to MCP servers can chain tool calls in ways humans didn’t anticipate. The illusion of control through predefined interfaces dissolves the moment agents start composing tools creatively. At which point, it’s less about what MCP was actually preventing and more what MCP becomes when the boundaries it drew are enforced at the runtime level instead.

Because the control plane has moved. In traditional software architecture it lives in your infrastructure: the code you wrote, the permissions you configured, the boundaries you drew. In agentic architecture it migrates into the agent’s reasoning layer. The agent decides what to do, when to do it, and how to compose its capabilities. That shift means the governance layer constraining those decisions cannot be ambient. It must be explicit, verifiable, and auditable after the fact.

A passport only works if something real is checking it at the border. When agents generate code inside a governance envelope, you need a runtime that can’t be exploited even when the code is wrong. But in the ‘OG’ MCP paradigm, the passport is checked at the Registry level (Is this agent allowed to see the ‘Delete Database’ tool?) In a world of tool-generation, that border shifts to the Execution Substrate: Instead of gating access to functions, we gate access to resources (I/O, Memory, Network) inside the sandbox.

This is where the shift from C to Rust stops being an infrastructure preference and becomes a mandate. The momentum behind porting critical infrastructure from C to Rust has been building for years, but AI acceleration is forcing the timeline. Monty is the first clear realization: AI-generated Python executing in a Rust-hardened sandbox, with memory safety guaranteed at the runtime level. If the agent generates a script to exfiltrate data, it shouldn’t fail because it lacks the “Exfiltrate Tool”; it should fail because the Runtime (a Rust-hardened container like Monty or a Deno isolate) detects an unauthorized outbound socket. As that same substrate appears inside MCP itself, the convergence becomes visible: MCP governs the identity of the agent making the request; the Runtime governs the integrity of the action. The passport finally has a trust border.

Convergence Not Collapse

Asking the wrong layer to do another layer’s job is what produces collapse. Asking the right layer to operate within its domain is what produces convergence.

Cloudflare’s Code Mode MCP server covers the entire Cloudflare API (over 2,500 endpoints) with two tools and roughly 1,000 tokens. An equivalent server built the traditional way would consume 1.17 million tokens, more than the full context window of the most advanced models available. The registry problem, in other words, doesn’t require abandoning MCP to solve. It requires abandoning the assumption that tools and capabilities need to be the same thing.

The server exposes two primitives: search() and execute(). The agent writes code against a typed representation of the API spec, runs it in a sandboxed isolate, and gets back only what it needs. No catalog. No discovery layer injected into context. No long-lived interface contracts. The capability exists for the duration of the call and disappears. That should sound familiar: it’s structurally identical to what Monty does, except that it lives entirely within MCP’s envelope.

Cloudflare’s Code Mode moves beyond tool-calling, tool-generation, or programmatic compromise by using MCP as a runtime for implementation-on-demand against a static API spec. The architectural question is no longer tool-calling versus tool-generation or a compromise mutation. It’s whether MCP, in absorbing the tool-generation substrate needed to survive, is still the thing it was designed to be. Or whether it’s transforming into something else: a governance layer, an auth boundary, a trust envelope, with code execution safely doing the actual work underneath.

The same pattern is now appearing as portable infrastructure. Port of Context (pctx-py v0.3.0) is a TypeScript code execution engine for AI agents: tool schemas for the governance layer, a sandboxed Deno runtime for execution, Rust callbacks for memory safety. Cloudflare Code Mode as a portable primitive, decoupled from any single platform, available to any agent stack. At the CLI layer, Vercel's Playwright CLI wrapper (agent-browser.dev) routes browser automation through the shell rather than a protocol abstraction, the hands doing the hands' job with near-zero context cost. Four independent implementations. One architecture: MCP as entitlement envelope, code generation as implementation substrate, CLI as the interop escape hatch for low-level systems that haven't been and shouldn't be abstracted into a protocol.

To state the architecture plainly:

• The call registry (MCP) is for entitlement. It defines who the agent is and what domain it is permitted to touch. It is the passport.

• The generator (Code Mode, Monty, pctx) is for implementation. It handles the context tax by replacing thousands of specific tools with generic primitives that synthesize logic on the fly. It is the brain.

• The shell, CLI, is for interop. It is the escape hatch for low-level systems that haven’t been abstracted into a protocol, operated by a single principal, on reversible operations. It is the hands.

The three-layer model describes the mature architecture. Most engineers are asking a more practical question: which layer should I be using? The honest answer is that the layers are not always co-present and are not equally necessary. CLI is a complete architecture for single-principal, reversible, contained operations and not merely the interop escape hatch of a larger stack. Tool generation is a complete architecture when the capability surface is dynamic and the context tax of describing it exceeds the cost of synthesizing it on demand. MCP earns its place only when trust boundaries exist between principals, when someone will eventually need to answer the on whose authority question. If there are no borders, the passport is just paperwork.

The collapse diagnostic still applies even when only one layer is present. The question is never ‘which layer am I using?’ but ‘am I asking this layer to do something it wasn’t designed for?’ Each failure has the same shape: a layer doing another layer’s job. You can see it concretely. MCP tryna carry implementation weight through predefined interfaces. CLI tryna answer for irreversible operations across principals. Tool generation tryna operate without an audit trail across trust boundaries.

“MCP is dead” is a reaction to the first collapse, specifically to registries asked to carry implementation weight they were never designed to bear. The correct response is not abandoning the protocol. It is returning MCP to its correct job and recognizing that the brain and the hands were always going to be different layers. The stack converges when the layers know their lane. It collapses when one of them doesn’t.

Framed this way, the three-layer model is not just a descriptive taxonomy; it’s a mental map for when to reach for what. Each layer dominates a domain. CLI dominates single-principal, reversible operations. Tool generation dominates dynamic capability synthesis. MCP dominates multi-principal, auditable trust boundaries. Asking the wrong layer to do the wrong job is what produces collapse. Asking the right layer to operate within its domain is what produces convergence.

What sits above all three of these layers, the reasoning layer, the behavioral expertise, the domain knowledge, the how to think about this problem that no tool registry, no execution sandbox, and no shell command was ever designed to carry, will be the subject of Part II, a special 5-part series during MCP Dev Summit week.

(Illustration by Jim Dine)

This post is an expanded articulation of of a piece originally published on CTO Lunch NYC that additionally includes a 30/60/90 playbook for CTOs.

Part two is a special 5-part series published live during MCP Dev Summit week