# MCP = Mega Context Problem Matt Carey, Cloudflare | AI Engineer Europe 2026 | 22:42 Source: https://www.youtube.com/watch?v=YBYUvGOuotE Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/mcp-mega-context-problem Published: 2026-04-25 Tags: context-engineering, mcp, security, tool-use ## TL;DR - Giving an agent every endpoint as an MCP tool can overwhelm its context window, so complete API access needs progressive discovery. - CLIs, tool search, and code mode offer different ways to expose large APIs without loading every tool definition at once. - Code mode depends on isolated execution with explicit permissions, while API providers also need rate limits and lightweight, stateless MCP integrations. ## Summary Matt Carey argues that MCP itself is not the source of the context problem. The problem comes from loading too many tool definitions into an agent at once. Cloudflare tried splitting its API into product-specific MCP servers, but that created many services with incomplete endpoint coverage and forced users to choose the right server. Carey presents progressive discovery through CLIs, tool search, and code mode. In code mode, the agent receives concise TypeScript types and writes code against a generated SDK. That code runs in an isolated, permission-controlled environment. Carey expects agents to use programmatic tool calls, save generated scripts for later jobs, and run more often in cloud environments. He also predicts that MCP will become a lightweight middleware option in web frameworks. The talk is practical about the security and capacity work required on both sides of the connection. ## Key ideas ### Loading an entire API as tools overwhelms the agent context [02:01](https://www.youtube.com/watch?v=YBYUvGOuotE&t=121s) Carey begins with the familiar tool-calling loop, where an LLM writes a function and the system executes it. Bundled tools later became shared remote tools through MCP, giving service providers another surface beside REST, GraphQL, and CLIs. This works when an MCP server has a small number of tools. It breaks when a provider tries to expose a complete API. Cloudflare's OpenAPI specification is over 2.3 million tokens, which becomes about 1.1 million tokens when represented as tools. Carey says even the largest foundational models cannot practically accept that entire definition in context. ### Product-specific MCP servers reduce context at the cost of coverage [02:47](https://www.youtube.com/watch?v=YBYUvGOuotE&t=167s) Cloudflare responded by splitting its API into product-based MCP services. The approach reduced the amount of context attached to each connection, but it created a selection problem for users. Cloudflare quickly had 16 servers, while its API had roughly 2,600 endpoints. A product MCP server might expose six tools even though the underlying product suite has about 30 endpoints. Carey says this misses the goal of making every API available to agents. The solution he wants is progressive discovery, where tools and other capabilities enter context only when the agent needs them. ### CLIs provide self-discovery when an agent has shell access [05:33](https://www.youtube.com/watch?v=YBYUvGOuotE&t=333s) Carey presents a CLI as one route around the context limit. An agent can call Wrangler, inspect its commands, choose a command such as Wrangler D1, and use the help option to learn the required parameters. The CLI is self-discoverable and documented through its interface, so the agent does not need every possible operation loaded as separate tool definitions. Carey says CLIs are popular and generally work well. Their limitation is access: the agent needs shell access to use them. That makes the method less suitable for clients that need a structured tool interface. ### Tool search loads a small group of likely tools on demand [06:33](https://www.youtube.com/watch?v=YBYUvGOuotE&t=393s) Tool search keeps a structured interface while avoiding a full tool dump. Carey describes a search tool that receives the user's question, performs keyword matching, and adds a small set of likely tools to the context. For a request to create a worker, the client might load several worker-related tools and let the model select the relevant one. The example leaves about 2,100 tokens in context while only about 500 are used. The exact number of retrieved tools can change, but the central behavior stays the same: only tools considered relevant are loaded. ### Code mode lets the model use a complete API through compact types [07:23](https://www.youtube.com/watch?v=YBYUvGOuotE&t=443s) Cloudflare's code mode gives the model generated TypeScript types instead of thousands of individual tool descriptions. The types describe operations such as getting worker scripts or creating a worker. The model writes code against a typed SDK generated from the API or its OpenAPI specification. Carey demonstrates code that lists workers, deploys a Hello World worker, and adds Cloudflare Access. Types give the model a concise description of inputs and outputs, while the generated code can combine several API operations. This lets the agent work with the full API surface without placing every endpoint definition in context. ### Generated code needs isolation and programmable permissions [09:11](https://www.youtube.com/watch?v=YBYUvGOuotE&t=551s) Clients were slow to adopt code mode because executing untrusted model-written code creates serious security risks. The code could read files or secrets, send those secrets over the network, run forever, consume resources, or mine cryptocurrency. Carey shows Cloudflare's dynamic Workers environment, where generated code runs in an isolated V8-based execution environment. With Node compatibility disabled, even process.env is unavailable. Network access can be blocked entirely or limited to approved domains. He describes this as a programmable sandbox with programmable guardrails, rather than asking clients to execute arbitrary code directly on the user's machine. ### Agents will create scripts, so APIs must handle autonomous load [14:40](https://www.youtube.com/watch?v=YBYUvGOuotE&t=880s) Carey expects programmatic tool calling to become common on both remote and local clients. Since the model generates code, a client can save that code as a small script for reuse. A user could create a web-scraping job without knowing how web scraping works, schedule it to run repeatedly, and have an agent repair the script when the target site changes. This pattern increases the demands on service providers. A generated loop can run across several sandboxes and send many requests at once. Carey says APIs will need effective rate limiting and other protection against this traffic. ### MCP is moving toward lightweight middleware and stateless servers [20:24](https://www.youtube.com/watch?v=YBYUvGOuotE&t=1224s) Carey predicts that MCP will become a small middleware option in application frameworks. As the TypeScript SDK gets lighter, frameworks could expose an API over MCP with a simple setting, allowing one application to publish a large collection of APIs instead of maintaining separate MCP services. He expects native integrations in major TypeScript full-stack frameworks. On the client side, more agents will run in the cloud, which makes state management more important. Carey says state should be something that can be turned on or off, and the SDK must become small enough to fit into ordinary application bundles. ## Notable quotes - "The context limit is not an MCP problem. It's an agent problem." (05:00) - "We just shouldn't be dumping loads of tools into context." (05:00) - "Code is actually a very compact plan." (15:00) - "Your APIs have to be ready to take a beating because they have to have good rate limiting." (17:00) - "It will be a flag that you can flag on in your favorite framework." (21:04) ## Tools & references mentioned - Cloudflare API - MCP - Wrangler - Cloudflare Access - WorkerD - Deno - Pydantic Monty - MCP TypeScript SDK - OpenAPI - Next.js ## Who should watch - You maintain an API and are deciding whether to publish a hand-picked MCP server or expose the full API to agents. - Your agent client is running into context limits from large tool catalogs and you need options beyond manually splitting servers. - You are building an MCP client or SDK and need to think through code execution, cloud state, permissions, and repeated autonomous traffic. ## Related talks - [MCP Is Not Good Yet](https://aietalks.com/talks/mcp-is-not-good-yet) (David Cramer, Sentry, 16:41) - [Your MCP Server is Bad (and you should feel bad)](https://aietalks.com/talks/your-mcp-server-is-bad-and-you-should-feel-bad) (Jeremiah Lowin, Prefect, 54:33) - [Bending a Public MCP Server Without Breaking It](https://aietalks.com/talks/bending-a-public-mcp-server-without-breaking-it) (Nimrod Hauser, Baz, 40:50) - [Building Agents with Model Context Protocol](https://aietalks.com/talks/building-agents-with-model-context-protocol) (Mahesh Murag, Anthropic, 1:44:12) - [MCP is all you need](https://aietalks.com/talks/mcp-is-all-you-need) (Samuel Colvin, Pydantic, 15:24)