MCP is the wrong abstraction

Model Context Protocol (MCP) is getting a reality check: flooding AI agents with tool definitions and tool-call syntax often degrades performance, and the industry may be better served by letting models write code against real APIs instead of forcing them to emit brittle “tool call” formats. Cloudflare’s new direction—turning MCP tools into a TypeScript API and then having the LLM generate TypeScript to call those APIs inside a sandbox—aims to cut context bloat, reduce token waste, and make multi-step tool use more reliable.

The core complaint is practical. Many agent systems expose every available action as an MCP tool, and the transcript argues that “more tools” correlates with worse outcomes: agents get distracted, choose poorly, or fail to execute the right sequence. Concrete comparisons across coding assistants illustrate the pattern. A complex agent setup (e.g., Trey’s nested agents and a long list of file operations, command controls, and even third-party tool access) is contrasted with a smaller, more focused tool set (e.g., Codex listing only a handful of functions like shell execution, plan updates, image viewing, and patch application). Other assistants show the same theme: when tool counts are kept tight and search/execution are clearly defined, behavior improves; when tool catalogs balloon, quality drops.

That tool-count problem connects to a deeper mechanism: traditional MCP requires the model to output special tool-call tokens in a format it has mostly seen in synthetic training, not in real-world code. The transcript describes how tool calling works under the hood—LLMs emit structured “tool call” sequences that a harness interprets as JSON-RPC-like requests, then feeds tool results back into the model for another generation. Each tool call becomes its own generation cycle, so intermediate outputs accumulate in the conversation history. The result is context bloat: even if each step starts small, repeated reasoning-plus-tool-result loops can inflate input tokens into the thousands or tens of thousands.

Cloudflare’s proposed workaround reframes the interface. Instead of exposing dozens of MCP tools directly, the agent SDK fetches the MCP server schema and converts it into a TypeScript API with documentation. The model then writes code that calls those APIs, and that code runs in a secure, isolated sandbox (Cloudflare isolates/V8-based). This shifts the “multi-step orchestration” from repeated model generations into a single code execution path, so the agent can read only the final results it needs rather than re-ingesting every intermediate tool call.

The transcript also argues MCP’s value is partly structural rather than semantic: MCP provides a uniform way to discover and connect to APIs with attached documentation and standardized connectivity/authorization. But it’s still treated as a patch—useful when legacy systems can’t be represented as code-first configuration. The speaker’s broader skepticism is that hype cycles may be outpacing real adoption, and that long-term, teams will prefer configurations that live directly in the codebase (Terraform/infra-as-code analogies, plus examples like Convex where configuration is local and file-based).

In short: MCP may remain useful for interoperability, but Cloudflare’s TypeScript-API-plus-sandbox approach targets the biggest pain points—too many tools, brittle tool-call syntax, and runaway context growth—by letting LLMs do what they’re increasingly good at: writing code to orchestrate deterministic actions.