Why Is MCP the Wrong Abstraction for AI Agents with Too Many Tools?

TL;DR

Too many directly exposed MCP tools can make AI agents worse because choosing among overlapping functions becomes an additional task that can produce mistakes and stalls. Trey showed weaker output while exposing numerous tools, whereas Codex presented only four in the demonstrated configuration. Cloudflare proposes converting MCP tools into a TypeScript API that the model calls through generated code. Read on for the comparisons, proposed abstraction, and suggested benchmark.

Transcript

I talk a lot about AI stuff on this channel, but there's a couple AI things you might notice I haven't mentioned a lot. One of those is MCP, the model context protocol. You might assume this is because I have some crazy hatred for anthropic and I'm just avoiding talking about their stuff, but it's not that. It comes down to something much simpler. ... Read More

Key Insights

• Selection becomes hidden work: Every directly exposed function creates another choice the model must evaluate before addressing the user’s task. When choices are numerous or overlapping, the agent can spend effort choosing a mechanism, make unnecessary calls, or get stuck. The presenter treats this selection burden as a likely cause of lower-quality behavior.
• Standardization is not rejected: The criticism targets how MCP capabilities are commonly presented to models, not the goal of making tool access portable. MCP can expose tools through a web service or internet-connected resource whose definition is copied into an AI product. The disputed question is whether every capability should appear as a direct callable function.
• Code changes the abstraction: Cloudflare’s approach represents MCP tools as a TypeScript API and has the language model write code against it. This shifts the model from repeatedly selecting individual direct tools toward composing operations through a programming interface. The presenter considers the idea promising, while explicitly waiting to see how it performs in real-world use.
• Trey revealed tool overload: Trey, described as ByteDance’s from-scratch VS Code fork and all-in-one AI coding IDE, delivered poorer output than comparable products during the presenter’s testing. It also became stuck calling various functions. Asking Trey to enumerate its capabilities exposed a broad inventory that may help explain those observed failures.
• Sub-agents add more choices: Trey can call three separate sub-agents, including a documentation-oriented agent and two code-development agents. Those agents sit alongside many ordinary functions. The model therefore must decide not only which operation to perform, but also whether to delegate the work and which specialized agent should receive it.
• Search overlap creates ambiguity: Trey includes generic search, regex search, file viewing, folder viewing, and multiple editing operations. Similar functions can force the model to distinguish among partially overlapping paths before solving the development problem. The presenter contrasts this with the relatively limited search and discovery interfaces used by Claude and Cursor.
• Four tools can cover much: In the demonstrated configuration, Codex exposes shell execution, plan updates, image viewing, and patch application. Despite that compact list, the presenter reports significantly better behavior than Trey. The comparison supports his claim that broad practical capability does not require a separate narrowly defined tool for every possible operation.
• Tool calls enable agency: A model can output a prescribed tool name and arguments, stop generating, wait for code to run, receive a response, and then continue. The presenter describes this loop as central to why AI editors have become powerful. His argument concerns how to structure that loop, not whether models should use tools at all.
• Configurations can vary by model: Cursor changes available tools according to the model being used. Its to-do tool was withheld from GPT-5 after causing problems, then restored when a cleaned-up system prompt improved its behavior. This example shows that the effectiveness of a tool depends partly on the model and surrounding instructions.
• Tool inventories can be inspected: Users can ask a coding agent to list every tool it can access and write the inventory to a file. If an interface does not expose that information clearly, the presenter suggests asking the agent to generate a website describing its tools. This makes otherwise hidden design choices visible for comparison.
• A controlled benchmark is possible: The presenter proposes comparing an agent equipped only with the correct tools against a similar agent that also receives nonsense tools. Differences in task performance could test whether irrelevant options cause measurable harm. This would move the claim from repeated observation toward a direct comparison under deliberately changed tool inventories.
• Models tolerate complexity differently: The presenter says most models appear to behave worse as tool inventories grow, but Sonnet 4.5 seems more capable of handling many tools than previous models. That exception matters because it suggests overload is not identical across models. Tool design should therefore account for model behavior rather than assuming one universal inventory.

Questions & Answers

Q: Why do too many MCP tools make AI agents worse?

Too many directly exposed tools give the model an additional selection problem before it can complete the actual task. Overlapping search, file, command, deployment, and service-specific functions increase the chances of unnecessary or incorrect calls. The presenter connects Trey’s extensive inventory with weaker output and repeated stalls. Smaller, clearer interfaces reduce those choices, which is why he associates Codex’s four demonstrated tools with better behavior.

Q: Why does the presenter call MCP the wrong abstraction?

He finds MCP insufficiently useful in his daily work and objects to the usual pattern of exposing every function directly to the model. That pattern makes the language model interpret and choose among a growing inventory before solving the user’s problem. He still recognizes MCP’s purpose of standardizing access to dynamic tools. His objection is therefore about the direct-tool abstraction, not the goal of interoperable tool access.

Q: What alternative does Cloudflare propose for MCP tools?

Cloudflare converts MCP tools into a TypeScript API and asks the language model to write code that calls the API. The model can then compose operations through code instead of receiving every MCP capability as a separate direct function. This could reduce the burden of repeatedly choosing among a large flat tool list. The presenter is excited by the concept but says its real-world results remain to be seen.

Q: How do Trey and Codex differ in their tool inventories?

Trey exposes three sub-agents along with numerous search, file, command, preview, deployment, web, Stripe, Supabase, and configuration functions. Codex exposes four tools in the demonstrated setup: shell execution, plan updates, image viewing, and patch application. The presenter observed Trey producing weaker output and getting stuck on calls. He reports that Codex behaves significantly better despite presenting a much smaller interface.

Q: How does an AI tool call work?

A developer gives the model a defined output format containing a tool name and required values. The model emits that structured request, stops, and waits while external code performs the requested action. The result is returned to the model, which then continues generating its response. The presenter describes this interaction pattern as a core reason AI agents and coding editors can perform useful external tasks.

Q: Why are overlapping search and file tools harmful?

Overlapping functions require the model to decide among similar mechanisms before it can work on the underlying code task. Trey offers generic search, regex search, file viewing, folder viewing, and several editing choices. Poorly differentiated options can lead the agent toward inefficient calls or leave it stuck. Clearer boundaries reduce ambiguity and let the model focus its effort on solving the requested development problem.

Q: Can tool availability be customized for different models?

Yes, the transcript says Cursor changes its available tools depending on the model. Cursor temporarily withheld its to-do tool from GPT-5 because the tool was causing problems. After the system prompt was cleaned up, the tool worked better and was restored. The example shows why tool configuration and prompting should be evaluated together for each model rather than treated as fixed.

Q: How could tool overload be tested objectively?

The presenter proposes benchmarking an agent with only the correct tools against a comparable agent that also receives nonsense tools. Both versions would attempt tasks while the tool inventory is the deliberately changed condition. If irrelevant functions reduce performance, the result would support the claim that extra choices harm agents. The suggested test formalizes observations that most models struggle more with larger inventories, although Sonnet 4.5 appears more capable than previous models.

Summary & Key Takeaways

• Questioning MCP’s practical value: The presenter rarely discusses Model Context Protocol because it has not been particularly useful in his daily work. MCP aims to standardize tool access, especially by exposing capabilities through services that can be connected to an AI product. The concern is not standardization itself, but the common implementation pattern of listing every available function as a direct tool for the language model to select.

• Introducing Cloudflare’s alternative: Cloudflare tested a different abstraction by converting MCP tools into a TypeScript API and asking the language model to write code that calls it. The presenter finds this concept exciting because it could preserve access to capabilities without placing every function directly in the model’s tool list. He credits Sunil and Cloudflare’s work while emphasizing that its real-world effectiveness still needs to be demonstrated.

• Pausing for Depot’s pitch: The sponsor segment argues that development teams can create pull requests five times faster with AI while builds remain slow. Depot reportedly reduced PostHog’s build time from more than an hour and a half to under 6 minutes, and made Mastodon’s build 38 times faster, from almost 2 hours to under 3 minutes. Its service costs 20 dollars a month.

• Explaining tools and MCP: A tool call lets a model emit a structured request, pause while external code runs, receive the result, and continue generating. The presenter uses a weather lookup format as a simple illustration. This mechanism underlies much of what makes agents and AI editors powerful. MCP extends the pattern by standardizing dynamic tools that can be exposed online and connected to an AI product through their definitions.

• Comparing coding-agent inventories: After Trey produced weaker results and became stuck calling unexpected functions, the presenter asked it to list every available tool. Trey exposed multiple agents plus search, file, command, preview, deployment, web, Stripe, Supabase, and configuration functions. By contrast, Codex showed four tools: shell execution, plan updating, image viewing, and patch application. The presenter associates the smaller, clearer interface with substantially better agent behavior.