MCP works because tools are dumb. That assumption has an expiry date.
We're building the last generation of human-designed protocols for AI. Agents won't need them.
A personal agent and a restaurant agent walk into a conversation.
The personal agent says: “I need a table for four on Saturday evening, somewhere with outdoor seating and a good wine list. We have a shellfish allergy in the group.”
The restaurant agent responds: “I have a 7:30 PM table on the patio. Our sommelier can recommend pairings, and the kitchen can accommodate shellfish allergies across the full menu. Shall I hold it?”
The personal agent checks its principal’s calendar, confirms the time works, and replies: “The 7:30 works, but can we push to 8? One person is coming from the airport.”
The restaurant agent checks availability, adjusts the reservation, and confirms.
No API was called. No MCP server was invoked. No schema was defined. Two agents negotiated a reservation through natural language — the same way two humans would on a phone call.
This interaction doesn’t exist yet. But every piece of it is technically possible today. And when it becomes commonplace, the Model Context Protocol won’t be the thing that enables it. It might be the thing it replaces.
MCP: What It Is, What It Solved, and Where It Sits
MCP is a protocol Anthropic open-sourced in November 2024 to standardize how AI models connect to external tools and data sources. Your AI app (say, Claude Desktop or Cursor) connects to MCP servers — small services that each expose a specific capability, like reading files, querying a database, or calling an API. The AI model discovers what tools are available and calls them through a standardized interface.
Before MCP, every integration was bespoke. A GitHub connector, a Salesforce connector, a Google Drive connector. MCP proposed a universal interface: build one server per tool, any model can use it. The adoption has been extraordinary — over 10,000 MCP servers published, supported natively by Claude Code, Cursor, VS Code, ChatGPT, Gemini, and Microsoft Copilot. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI. It’s been called “the USB-C of AI.”
That analogy is more revealing than its proponents intend. USB-C exists because physical devices can’t negotiate how to talk to each other. They need a predetermined protocol because they lack the intelligence to figure it out on the fly. AI agents have exactly that intelligence.
MCP excels at agent-to-tool communication — and it solved the N×M integration mess elegantly. The question is whether MCP, or any human-designed protocol, is the right architecture for the next layer: agent-to-agent communication.
Think of it as three phases. Phase 1 was custom integrations (2020–2024) — fragmented and unsustainable. Phase 2 is standardized protocols (2024–now) — MCP for agent-to-tool, Google’s A2A for agent-to-agent. A massive improvement, but still human-designed interfaces that predefine what agents can do. Phase 3 is emerging: agents negotiate communication on the fly, using natural language or dynamically agreed formats. The protocol becomes emergent rather than predefined.
MCP and A2A live in Phase 2. The question is how long Phase 2 lasts.
The Expedia Problem
Consider what happens when an agent needs to book a flight on Expedia.
With MCP today: Expedia’s team builds an MCP server exposing structured tools — search_flights(origin, destination, date), book_flight(flight_id, passenger_info). Your agent calls these tools via the protocol. It works, but only because Expedia invested engineering resources to build and maintain that interface.
With A2A: Your agent discovers Expedia’s agent via an Agent Card, then exchanges structured messages to negotiate the booking. Better for this use case, but still requires Expedia to implement the protocol and define capabilities upfront.
With a browser agent: The agent opens Expedia.com, reads the page, enters search criteria, and completes the booking. No MCP. No A2A. This works today.
With direct agent communication: Your agent contacts Expedia’s agent. “I need the cheapest direct flight from Brisbane to Sydney on February 20 for one adult.” Expedia’s agent — with direct access to its own inventory — responds with options. They negotiate. Done.
Here’s the insight that matters: Expedia’s own agent doesn’t need MCP to access Expedia’s systems. It has direct, trusted access. MCP is valuable when your agent needs to reach across a trust boundary into Expedia’s systems. It’s the protocol for the boundary, not the interior.
But when both sides of that boundary have intelligence, do you need a rigid protocol? Or can the boundary itself become intelligent?
Follow the logic one step further. Today, your agent needs MCP to query Expedia’s database because Expedia doesn’t have an agent — it has a dumb tool. MCP bridges the gap between an intelligent agent and an unintelligent endpoint. But the moment Expedia ships its own agent — and they will — your agent talks to Expedia’s agent. No MCP needed.
The same applies locally. Claude needs MCP to read your files because your file system is a dumb tool. But Apple, Microsoft, and Google are all building OS-level agents. Once your file system is fronted by a local agent, Claude talks to that agent instead.
MCP’s entire value depends on the other side of the conversation being unintelligent. That assumption has an expiry date.
The Strongest Evidence Is from MCP’s Own Creator
When Anthropic released Agent Teams in early 2026, they made an architectural choice that speaks louder than any protocol specification.
Agent Teams spawns multiple independent Claude Code instances working simultaneously on a shared codebase. Each teammate loads its own context — including MCP servers for tool access. One agent writes API endpoints. Another builds React components. A third reviews the code the other two produce.
The agents coordinate with each other through natural language messages, shared task lists, and file-system-level collaboration. Not through MCP. Not through A2A. Through conversation.
Anthropic — the company that created MCP — chose natural language as the inter-agent communication layer for their own multi-agent system. MCP handles the tool layer. Natural language handles the coordination layer. That architectural decision is the strongest evidence that MCP’s creators see the same boundary this article describes.
CLI agents reinforce the pattern. Claude Code uses MCP to connect to GitHub and Postgres, but runs git push and npm test directly in the terminal. OpenClaw — the fastest-growing GitHub repo in history, now exceeding 200K stars — orchestrates agents across messaging platforms, file systems, and browsers without predefined schemas. Agents default to the most direct interface available. MCP when they need it. Terminal when they can. Natural language when they’re talking to each other.
The Hard Problems (Honestly)
The obvious counterargument deserves a serious answer, not hand-waving.
Latency and cost. A structured MCP tool call is fast — JSON in, JSON out, microseconds. Two agents negotiating in natural language means LLM inference calls per exchange. Orders of magnitude more expensive today.
Determinism. book_flight(id=123) returns a 200 OK or an error. An agent interpreting “book me on the morning flight” could misunderstand “morning” or hallucinate a confirmation.
Security and auditability. MCP provides scoped permissions, auth tokens, and audit trails. When two agents communicate in natural language, who enforces the boundaries?
These are real constraints. They’re why MCP works well today. But they’re engineering problems with clear trajectories. Inference costs have dropped roughly 10x per year since 2023. Structured output modes already let agents negotiate in semi-structured formats that combine natural language flexibility with machine-parseable reliability. A five-turn agent negotiation that costs $0.50 today might cost $0.005 in two years. At that price point, the calculus changes fundamentally.
Where Protocols Break Down
Agent-to-agent interactions aren’t simple tool calls. They involve negotiation, ambiguity, and multi-step reasoning. A candidate’s agent negotiating remote work flexibility with a company’s hiring agent. A purchasing agent comparing offers from three supplier agents with different constraints. A personal agent rebooking a disrupted travel itinerary across airline, hotel, and car rental agents.
These interactions require understanding intent, handling ambiguity, making judgment calls — exactly what LLMs are good at. Forcing them through predefined schemas loses the intelligence that makes agents valuable.
Google recognized this with A2A — launched April 2025, now at version 0.3 with 150+ partner organizations, contributed to the Linux Foundation. A2A correctly identifies the problem: agents need to talk to agents, not just tools. But it solves it the same way engineers always have: with a predefined protocol. Agent Cards. Task state machines. Artifact schemas. It’s a well-designed Phase 2, not Phase 3.
The irony is that AI’s core capability is understanding unstructured input. Building rigid protocols for AI communication is like requiring two fluent conversationalists to communicate exclusively through a predetermined set of flash cards.
What This Means for Companies
I’ve watched companies spin up MCP integration teams, hire MCP specialists, build entire platform strategies around it — treating it as permanent infrastructure. This is rational in the short term. MCP works today. It has massive ecosystem support.
The risk is treating MCP as the answer for agent-to-agent communication — building architectures where every inter-agent interaction flows through predefined schemas. That’s building for Phase 2 when Phase 3 is already emerging.
The companies that will adapt best are those building agent capabilities rather than protocol infrastructure. If your Expedia agent can reason about flights, negotiate with customers, and execute bookings — it doesn’t matter whether the communication layer is MCP, A2A, or natural language. The intelligence is in the agent, not the protocol.
The companies most at risk are those whose entire AI strategy is “build more MCP servers.” They’re investing in the connector, not the intelligence.
The Uncomfortable Prediction
Remember the restaurant reservation from the opening? That interaction doesn’t require MCP or A2A. It requires two intelligent systems that can understand intent, handle ambiguity, and reach agreement. The protocol is the conversation itself.
MCP won’t disappear tomorrow. For now, it remains the best way to connect an intelligent agent to an unintelligent tool — and most tools are still unintelligent. A2A won’t disappear either. For enterprise orchestration where auditability matters, predefined protocols provide real value today.
But both protocols share the same underlying assumption: that one side of the conversation is too dumb to negotiate. As tools get fronted by agents — as Expedia ships its own agent, as your OS gets a local agent, as every SaaS product becomes an agentic endpoint — that assumption erodes. Every interaction becomes agent-to-agent. And agents don’t need humans to design their conversations.
We may be building the last generation of human-designed communication protocols for AI. Not because MCP or A2A are bad — they solved real problems at exactly the right time. But because the thing these protocols connect — AI models — are exactly the thing that makes rigid protocols unnecessary.
The protocol of the future is most likely natural language. The one thing it probably won’t be is a static specification written by humans in 2024.
I’m Niraj Kothawade, product leader and founder of MasterPrep AI. We build evaluative voice AI where agents conduct, assess, and score enterprise interviews — a domain where orchestration architecture matters more than API convenience. Previously Senior Director Product at Deputy, with 15+ years building products at Flipkart, Yahoo, and PubMatic. Find me on LinkedIn or on Substack.