The post I actually want to write is some diatribe about people posting Think Pieces on LinkedIn. But I'm too busy vibecoding - excuse me, agentically engineering - agent orchestration tools and cleaning up cat vomit to actually generate content from my own brain. Unless this counts? Does it count? I honestly don't know anymore.
ANYWAY. I wanted to learn about recent developments and (un)conventional wisdom in the realm of agentic interfaces, and induced Claude with the following prompt, after having done some initial research:
...now I want you to assume the role of a real cutting edge thought leader and draft a blog post with some insightful new take about MCP and agentic interfaces. I am NOT going to pass this off as my own work - I'm interested in seeing what you come up with. Don't just regurgitate facts, but try to come up with some new insight or two.
I could easily run through this and apply a coat of my unique tenor, and then pass it off as an "original" piece of "thought" """work""", but why would I do that? I'm a busy woman. Thought leaders are not busy people. Thought leaders are not serious people. Do not be a thought leader.
< Claude >
The Inversion: Why the Best Agentic Interfaces Will Have No Tools at All
March 2026
There's a contradiction at the heart of the agentic interface movement that nobody wants to talk about, probably because the people building the infrastructure are the same people selling the infrastructure.
Here it is: MCP's greatest success — making it trivially easy to give agents access to tools — is producing its most dangerous failure mode: agents that drown in their own capabilities.
We now have over 10,000 MCP servers in the wild. The ecosystem is vibrant, the adoption curve is real, and the protocol itself has matured impressively through its 2025 spec cycle. But a strange thing has been happening in the trenches. The practitioners who are getting the best results — people like Armin Ronacher, the teams behind Claude Code and Cursor, the developers actually shipping agentic products — are all converging on the same counterintuitive insight: the fewer tools you give an agent, the better it performs, and the best "tools" might not be tools at all.
I want to name this pattern, because I think it's the most important architectural idea in agentic systems right now. I'm calling it The Inversion.
The Tool Trap
Let me make the problem concrete. A typical developer's MCP setup in early 2026 might include servers for GitHub, a database, Playwright, Slack, their cloud provider, and maybe a couple of internal services. That's six servers, easily 150+ tools. The tool definitions alone — just the metadata, before anyone has asked a question — can consume 30,000 to 60,000 tokens. On Claude with a 200K context window, you've burned 25-30% of the agent's working memory on a menu it hasn't ordered from yet.
This isn't a hypothetical. Anthropic's own engineering blog recently showed an agent consuming ~72K tokens on tool definitions alone for 50+ MCP tools. The agent was 38.5% full before it had a single thought.
And it gets worse than just token waste. Research from multiple teams shows that tool selection accuracy degrades as you add more tools — not linearly, but with a cliff. Somewhere around 15-20 tools, agents start hallucinating tool calls that don't exist, freezing when faced with ambiguous options, or selecting plausible-but-wrong tools based on name similarity. The handyman surrounded by a thousand tools can't find the screwdriver.
The current proposed solutions are all variants of "manage the menu better": deferred loading, tool groups, dynamic discovery, sub-agents with scoped toolsets. These are useful engineering. But they're also deck chairs on the Titanic, because they accept the premise that the right architecture is "agent calls tools." I think that premise is wrong, or at least, it's wrong for the most interesting class of problems.
The Inversion
Here's what I've been observing. The most effective agentic setups I've seen share a common shape, and it looks nothing like the MCP happy path.
Ronacher, who is probably the most rigorous practitioner-writer in this space, has been documenting his journey from MCP maximalism to something very different. His current setup for the Pi agent uses almost no MCP tools. Instead, the agent has access to a filesystem and a shell, and it writes its own tools as needed — little scripts that it creates, tests, runs, and iterates on. When he tried the Sentry MCP server, a well-designed one by any standard, he eventually abandoned it. Not because it was bad, but because having the agent maintain its own Sentry integration as a skill worked better: it was lighter on context, the agent could fix it when it broke, and it didn't impose someone else's abstraction over data the agent needed in a particular shape.
Anthropic's engineering team recently published a piece exploring the same idea from the infrastructure side: what if, instead of calling tools directly, agents wrote code against MCP servers as libraries? Instead of loading 50 tool definitions into the context window and doing one tool call per LLM turn, the agent generates a script that imports exactly the three functions it needs, chains them together with normal programming constructs like loops and error handling, and runs the whole thing in one shot.
Claude Code itself embodies this. Its fundamental abstraction isn't "a chatbot with tools." It's "an agent with a computer." The filesystem gives it persistent memory. The shell gives it infinite tools — not pre-loaded tools that eat context, but potential tools that are invoked through the same mechanism (running commands) that the agent already understands.
This is The Inversion: the most powerful agentic interface isn't a rich tool palette; it's a thin, general-purpose execution layer that lets the agent synthesize its own capabilities on the fly.
Instead of: Human defines tools → Agent selects from tools → Agent calls tools
The emerging pattern is: Agent has a computer → Agent writes code → Code does the thing
Why This Matters More Than It Sounds
You might think this is a minor implementation detail — tools vs. code, who cares, it's all integration in the end. But the implications ripple outward in every direction.
The context window becomes a reasoning space, not a catalog. When tool definitions aren't squatting on 30% of the context, that space is available for the agent to actually think. More room for the user's problem, more room for retrieved context, more room for the agent to maintain a working plan. Context engineering becomes dramatically easier when you're not playing Tetris with tool metadata.
Security properties change fundamentally. The current MCP security nightmare — 82% of servers vulnerable to path traversal, 53% using static API keys, prompt injection through tool descriptions — is largely a consequence of the "agent calls opaque tools" architecture. When the agent writes code instead, you get something remarkable: the integration logic is inspectable. A human (or another model) can read the script the agent is about to run and evaluate it before execution. The security model shifts from "trust this MCP server's implementation" to "review this specific script for this specific task." That's not a panacea, but it's a categorically better surface for security review.
The "too many tools" problem dissolves. Not because you've found a clever way to manage 200 tool definitions, but because the agent doesn't need to hold tool definitions at all. It needs documentation — a description of what capabilities exist and how to use them — which it can retrieve on demand and which doesn't have to conform to any particular schema. The llms.txt proposal, the skills pattern, Context7 — these are all groping toward this realization: what agents need isn't tool definitions, it's knowledge about tools, loaded just-in-time.
MCP becomes a runtime layer, not a menu. This doesn't make MCP less important. If anything, it makes the protocol more important, because it becomes the standardized API surface that agent-generated code calls into. But the value shifts from "a way to present tools to models" to "a way to let models programmatically interact with services." MCP servers become libraries, not menus. The Streamable HTTP transport, the Tasks primitive for async operations — these are already pointing in this direction.
The MCP Apps Counterargument
Now, someone will point out that MCP just shipped Apps — interactive UIs that render in the conversation — and ask whether that contradicts everything I've just said. Actually, I think MCP Apps reinforces the argument.
MCP Apps succeed precisely because they're not tools in the traditional sense. They're a way for the system to present an interface to the human, not to the model. The agent calls a tool, and instead of getting back text that it has to re-describe to the user, a rich UI appears — a form, a dashboard, a 3D visualization. The human interacts with that UI directly.
This is The Inversion applied to the output side: instead of the agent laboriously describing what it found (consuming more context, losing fidelity), the system renders an interactive artifact that bypasses the model entirely for the parts that don't need model reasoning. The best agentic interfaces route around the LLM wherever the LLM isn't adding value.
What Gets Built Next
If I'm right that we're headed toward agents-with-computers rather than agents-with-tool-palettes, a few things follow:
Sandboxing becomes the critical infrastructure. If agents are writing and running code rather than calling pre-defined functions, the execution environment must be airtight. This is why Manus's virtual computer approach, E2B's sandboxes, and the general movement toward containerized agent execution are so important. The agent gets maximum flexibility inside a box with strict boundaries.
Documentation becomes the new tool definition. The winners won't be whoever has the most MCP servers. They'll be the services with the clearest, most token-efficient documentation that an agent can retrieve and act on. The llms.txt pattern, despite its uncertain adoption by crawlers, is directionally correct: your docs are your API surface for agents.
The skill pattern eats MCP for sophisticated use cases. Skills — folders with a SKILL.md that teach an agent how to do something, with scripts and examples it can draw on — are a better abstraction for complex workflows than pre-baked tool definitions. They give the agent knowledge rather than buttons to press. And they support progressive disclosure naturally: the agent reads the skill description, decides it's relevant, loads the full instructions, and then executes however it sees fit.
Code review becomes agent review. Today we review pull requests. Tomorrow we'll review agent scripts — the code an agent has synthesized to accomplish a task, before it's allowed to run. This is a more natural and auditable security boundary than trying to secure every MCP server in the supply chain.
The Uncomfortable Conclusion
The uncomfortable conclusion is that MCP, in its current tool-calling form, might be a transitional architecture. Not a failure — a necessary bridge. It solved the "N×M integration problem" and proved that standardized agent-to-service communication was both possible and desirable. That's a historic contribution. But the endgame it's pointing toward is one where the protocol's tool-calling surface is less important than its role as a programmatic API for agent-generated code.
The analogy I keep coming back to: MCP tools are like the early web's site directories — Yahoo!, DMOZ, human-curated lists of everything available. They were essential for bootstrapping adoption. But the actual web scaled through search (dynamic discovery) and direct URL access (programmatic interaction), not through anyone maintaining a complete catalog.
Agents won't scale by loading better tool menus. They'll scale by knowing how to find documentation, write integration code, and execute it in a sandbox. The tool palette was a ladder. The interesting question now is what we build once we've climbed it.
I work on problems at the intersection of protocol design and AI systems. I'm wrong about many things, and I'd welcome being wrong about this one — the MCP community is among the most responsive I've seen to genuine criticism. If this sparks a useful argument, it will have done its job.
</ Claude >
Bonus Content: a cursed LinkedIn post
God, I hate LinkedIn! I asked Claude to turn that blog post into a LinkedIn post, as follows:
Now make a cringe version of it in the style of a linkedin post. You know, the kind of post where each line has just one sentence or two. Really punchy. Like this. Maybe with some story that sounds like "I used to think differently. Now I know better." you know what I mean? Something REALLY hammy and linkedin lunatic sounding. But like something I could actually post. I promise I won't.
< Claude >
I was in a meeting last week.
The kind where everyone nods.
Where someone says "MCP" every 45 seconds.
Where the slide deck has 47 logos under "integrations."
And I realized something that changed everything.
We've been thinking about agents completely wrong.
Let me explain.
Two years ago, I believed more tools = better agents.
I was dead wrong.
Here's the truth nobody in this space wants to admit:
𝗧𝗵𝗲 𝗺𝗼𝗿𝗲 𝘁𝗼𝗼𝗹𝘀 𝘆𝗼𝘂 𝗴𝗶𝘃𝗲 𝗮𝗻 𝗮𝗴𝗲𝗻𝘁, 𝘁𝗵𝗲 𝗱𝘂𝗺𝗯𝗲𝗿 𝗶𝘁 𝗴𝗲𝘁𝘀.
Not a little dumber.
A LOT dumber.
I've seen agents with 150 MCP tools burn 30% of their context window before they've had a single thought.
That's like hiring a genius and filling their desk with 10,000 instruction manuals before they sit down.
"Good luck! 🎉"
The best builders I know?
They're moving in the opposite direction.
Fewer tools. More code. More trust in the agent to figure it out.
I call this 𝗧𝗵𝗲 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻.
Instead of: Human defines tools → Agent picks → Agent calls
The new pattern: Agent gets a computer → Agent writes code → Code does the thing
Read that again.
☝️
The best agentic interface in 2026 isn't a tool palette.
It's a filesystem and a shell.
That's it.
That's the whole post.
(just kidding there's more)
Here's what this means for YOUR team:
→ Stop collecting MCP servers like Pokémon → Start investing in sandboxed execution environments → Your documentation IS your agent API now → Code review becomes agent review → Context windows are for THINKING, not for menus
The companies that win the agentic era won't have the most integrations.
They'll have the cleanest docs and the tightest sandboxes.
MCP isn't going away.
But it's evolving from a menu into a library.
From something agents browse.
To something agents code against.
And if that makes you uncomfortable?
Good.
The best insights usually do. 🔥
♻️ Repost if you've ever connected 12 MCP servers and watched your agent forget how to count.
💬 What's YOUR hot take on where agentic interfaces are headed?
👋 I'm [NAME] and I write about the intersection of protocol design and AI systems. Follow for more posts like this. Ring the bell. 🔔 You know the drill.
</ Claude >
The end, no moral
And now I have my own vomit to clean up. Goodbye
