Agents Don't Need MCP to Figure Things Out. But They Do Need Something Better.
MCP isn't the destination. It's a waypoint.

Search for a command to run...
MCP isn't the destination. It's a waypoint.

No comments yet. Be the first to comment.
The Mental Tax Nobody's Pricing Into AI-Augmented Engineering In December, Andrej Karpathy — the guy who coined the term "vibe coding" — posted this: "I've never felt this much behind as a programmer. The profession is being dramatically refactored ...

Software Verification Has Become the New Development Bottleneck in 2026 We can generate entire applications from screenshots in minutes, but it still takes hours to verify they actually work. The real constraint isn't writing code anymore: it's provi...

Teaching Your AI Tools Instead of Just Using Them Every bug fix you make without updating your AI's knowledge base is engineering work you'll do twice. While most developers treat AI as a fancy autocomplete, a growing cohort is building something dif...
Why Most AI-Assisted Development is Just Expensive Autocomplete Your $240-per-year GitHub Copilot subscription is making you feel productive while keeping you trapped in the same fundamental bottlenecks that have plagued software development for deca...
Building Compound Engineering Systems That Learn From Every Bug Fix Most AI coding tools give you short-term speed boosts then reset to zero knowledge. You write code, ship features, fix bugs, and next week you're back to explaining the same patterns...
Give a capable agent enough time and tokens, and it will work out most things on its own.
I have watched this in production work. An agent navigating an API it was never explicitly told about, piecing together the right endpoints from documentation, making it work. No MCP. No custom tooling. Just the model, some context, and enough runway.
That is not a reason to abandon structured agent tooling. It is a reason to get clearer about what that tooling is actually for.
The MCP conversation right now is too binary. Either you are building MCP servers for everything, or you are on the "MCPs were a mistake, bash is better" side. Both camps are missing the point.
DHH ran a clean experiment in February that illustrates where this is heading. He gave an agent a computer, no MCPs, no APIs configured, and a single task. The agent got its own email address, completed a signup flow, sourced images, and joined a Basecamp account from an email invite. No special equipment. Just the model navigating the open web.
His read: agents are heading toward a world where they do not need custom integration layers to interact with their environment.
I think he is right about the direction. I do not think it means MCP is dead.
For complex operations on internal systems, structured tooling still makes sense. When an agent needs to write to a database, modify records, or execute a transactional workflow where partial failure is a real problem, I want a clean, controlled interface between the agent and the system.
The question is not "should I build an MCP server." It is "what is the cost of the agent figuring this out alone versus having a defined interface, and what happens if it gets it wrong."
Low stakes, read-only, web-native: let the agent navigate. High stakes, write operations, internal systems: wrap it properly. That logic is not new. It is the same abstraction decision we made when designing APIs for human developers.
Here is the part that does not get enough attention.
The 2025 State of AI Agents report found that 46% of teams cite integration with existing systems as their primary challenge. That number will come down as models improve at self-directed navigation. But the deeper constraint will remain: how many tokens does it take to get from a task to a correct result.
Every layer of tooling is a tax on that. Large tool definitions consume context. Poorly designed interfaces force extra calls to clarify what the agent should already know. I have seen agent runs where 40% of the token spend was the model navigating its own tooling rather than doing the actual work. That is a badly designed interface, not a smart agent.
The agents that perform best in production are not the ones with the most tools. They are the ones where every interface is designed around what the agent actually needs to know, in the format it most naturally reasons about.
Most MCP servers today are not that. They are API wrappers with JSON schemas bolted on, built for human-readable documentation that got reformatted for tool calls.
MCP is a waypoint, not a destination. The pattern we are converging on is some kind of interface standard designed from the ground up for how models process information, not how REST APIs were designed for developers.
What that looks like exactly, nobody knows yet. But the direction is clear: agent tooling will evolve toward making the right data available in the most token-efficient, latency-minimal way possible. APIs and tooling should accelerate agents, not become another layer they have to work around.
The ones that are not accelerants will get replaced. Not by agents brute-forcing the open web, but by better-designed interfaces that treat the model as the primary consumer.
Build for that.