MCP isn't the API layer for AI agents. It's the UI layer.
I initially dismissed MCP as unnecessary overhead. Another protocol when OpenAPI already exists? Just a standard for calling REST APIs differently? Redundant tech for VC-backed startups to differentiate themselves.
I was wrong.
The Model Context Protocol represents something far more fundamental: a paradigm shift in how we build intelligent systems. It's not primarily about connecting models to APIs—it's about reimagining UIs for the age of AI agents.
I've been living under a rock, what is MCP?
Anthropic's Model Context Protocol was designed to solve the "M×N integration problem" of connecting AI models to external data sources. Before MCP, connecting M different AI applications to N different tools required M×N separate integrations—an exponentially complex problem.
MCP uses a client-server architecture with three main components:
- Hosts: AI-powered applications like Claude or development environments
- Clients: Protocol clients that communicate with servers
- Servers: Lightweight programs exposing specific capabilities
The key innovation is MCP's dynamic discovery capabilities. AI models explore available tools at runtime rather than requiring predefined knowledge of integrations.
Wrapping REST APIs in MCP is missing the point
Everyone and their mother is taking existing APIs and wrapping them in MCP. This offers minimal value—agents already understand OpenAPI specs and can make REST API calls natively. If you have a weather API that takes a location parameter and returns temperature, MCP actually complicates things.
Research shows MCP can even reduce accuracy in simple tool calling scenarios compared to direct API access. It requires both provider and consumer to expose MCP clients, adds complexity, and solves a problem that doesn't exist for straightforward API integrations.
MCP's killer app: replacing browser agents
MCP's true value proposition becomes clear when you realize what it's actually replacing: browser automation.
Today's approach to complex workflows like booking flights involves agents firing up browser automation to navigate UIs. These UIs were designed for humans, not machines, leading to brittle, high-maintenance automation that breaks with the slightest change.
MCP transforms this landscape by providing an AI-native interface layer between consumer and provider agents. It replaces browser-based navigation with structured, turn-based interactions over text and structured outputs.
Example: Flight booking reimagined through MCP
Consider flight search—a complex interaction typically handled through web UIs like Google Flights or Skyscanner. It requires:
- Searching by varied criteria (origin, destination, dates, price ranges, airlines)
- Further filtering and sorting results
- Selecting among different flight options
- Choosing seat classes and extras, that vary depending on the flight you chose
Today, agent builders handle this by automating browser navigation. With MCP, the interaction becomes a structured, multi-turn conversation:
Consumer agent:
{
"jsonrpc": "2.0",
"id": 0,
"method": "client/initialize",
"params": {
"mcpVersion": "2025-03-26",
"capabilities": { "tools": {} }
}
}
Flight server:
{
"jsonrpc": "2.0",
"id": 0,
"result": {
"mcpVersion": "2025-03-26",
"capabilities": { "tools": {} }
}
}
Consumer agent:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}
Flight server (only the “search_flights” tool is initially available):
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "search_flights",
"description": "Find flights between two cities",
"inputSchema": {
"type": "object",
"properties": {
"origin": { "type": "string" },
"destination": { "type": "string" },
"departure_dates": {
"type": "array",
"items": { "type": "string", "format": "date" }
},
"return_dates": {
"type": "array",
"items": { "type": "string", "format": "date" }
},
"preferred_class": { "type": "string" }
},
"required": [
"origin",
"destination",
"departure_dates",
"return_dates"
]
}
}
]
}
}
Consumer agent:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "search_flights",
"arguments": {
"origin": "NYC",
"destination": "London",
"departure_dates": ["2025-05-20", "2025-05-21", "2025-05-22"],
"return_dates": ["2025-05-27", "2025-05-28", "2025-05-29"],
"preferred_class": "business"
}
}
}
Flight server (returns results for the search):
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [
{
"type": "text",
"text": "I found several flight options for your NYC–London trip in business class."
},
{
"type": "json",
"json": {
"available_dates": {
"outbound": ["2025-05-20", "2025-05-21", "2025-05-22"],
"return": ["2025-05-27", "2025-05-28", "2025-05-29"]
},
"route_options": [
{ "direct": true, "duration": "7h05m" },
{ "direct": false, "stops": 1, "duration": "8h40m" }
],
"price_range": { "min": 2400, "max": 5800 }
}
}
]
}
}
Flight server (notification that the tool list has changed):
{
"jsonrpc": "2.0",
"method": "tools/list_changed",
"params": { "reason": "flight_search_results" }
}
Consumer agent (asks for the updated list):
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/list",
"params": {}
}
Flight server (now exposes “filterflights” and “selectflight”):
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"tools": [
{
"name": "filter_flights",
"description": "Filter flights by date or directness",
"inputSchema": {
"type": "object",
"properties": {
"outbound_date": { "type": "string", "format": "date" },
"return_date": { "type": "string", "format": "date" },
"direct_only": { "type": "boolean" }
},
"required": ["outbound_date", "return_date"]
}
},
{
"name": "select_flight",
"description": "Select a flight for seat view, booking, or details",
"inputSchema": {
"type": "object",
"properties": {
"flight_id": { "type": "string" },
"action": {
"type": "string",
"enum": ["view_seats", "proceed_to_booking", "request_details"]
}
},
"required": ["flight_id", "action"]
}
}
]
}
}
Consumer agent (use the new “filter_flights” tool):
{
"jsonrpc": "2.0",
"id": 4,
"method": "tools/call",
"params": {
"name": "filter_flights",
"arguments": {
"outbound_date": "2025-05-21",
"return_date": "2025-05-28",
"direct_only": true
}
}
}
Flight server (filtered results):
{
"jsonrpc": "2.0",
"id": 4,
"result": {
"content": [
{
"type": "text",
"text": "Here are the direct flights for 21 May 2025 outbound and 28 May 2025 return."
},
{
"type": "json",
"json": {
"flights": [
{
"id": "BA178-BA175",
"outbound": {
"date": "2025-05-21",
"departure": "JFK 18:30",
"arrival": "LHR 06:35+1",
"airline": "British Airways",
"flight_number": "BA178"
},
"return": {
"date": "2025-05-28",
"departure": "LHR 14:15",
"arrival": "JFK 17:05",
"airline": "British Airways",
"flight_number": "BA175"
},
"price": 3200,
"class": "business",
"seats_available": 4
}
]
}
}
]
}
}
Consumer agent (select the flight and view seats):
{
"jsonrpc": "2.0",
"id": 5,
"method": "tools/call",
"params": {
"name": "select_flight",
"arguments": {
"flight_id": "BA178-BA175",
"action": "view_seats"
}
}
}
Flight server (seat-map response):
{
"jsonrpc": "2.0",
"id": 5,
"result": {
"content": [
{
"type": "text",
"text": "Seat map retrieved—four business-class seats remain available."
},
{
"type": "json",
"json": {
"seat_map_url": "https://example.com/seatmap/BA178-BA175"
}
}
]
}
}
And so the conversation continues—a structured negotiation between agents that mirrors human interaction with flight booking interfaces but operates through AI-native protocols rather than fragile UI automation.
The paradigm shift: negotiated intents through conversation
This is where MCP excels: complex, multi-turn workflows where consumer and server agents need to negotiate to map user intent into what the service can provide. It creates a middle ground between rigid APIs and brittle browser automation.
The key patterns emerging in successful MCP implementations:
1. Progressive disclosure - Revealing options gradually as the conversation narrows
2. Contextual persistence - Maintaining state across multiple interactions
3. Dynamic discovery - Exploring available capabilities at runtime
4. Negotiated refinement - Working with the user to clarify and specify needs
The transitional advantage that won't last
Currently, MCP enjoys another advantage: Cursor, Claude, and other agents are building directories to make MCP servers easily installable. While convenient, this is likely temporary. Over time, agents will autodiscover and use OpenAPI files (e.g., in /api/yaml routes in web domains), removing MCP's discovery advantage for basic API integrations.
The enduring value of MCP lies in its conversational UI paradigm for complex workflows—not in its application to simple API calls.
The future is agent-to-agent UI
The revolution here isn't about connecting models to data—it's about replacing human-oriented UIs with agent-oriented conversation protocols. We're witnessing the birth of an AI-native interface layer that will transform how we think about building online services.
MCP isn't winning because it's a better API standard. It's winning because it's the first UI standard designed for the age of AI agents.