MCP vs. REST: Why the Application Protocol Is Changing

REST has been the default protocol for application integration for two decades. Every API you’ve consumed, every webhook you’ve configured, every microservice your team operates. REST is the common language. It works. It’s well-understood. And it’s the wrong protocol for AI agents.

This isn’t a “REST is bad” argument. REST solved the problem it was designed for: giving human developers a predictable way to build client-server applications over HTTP. The problem is that agents aren’t human developers. They don’t read API documentation. They don’t hardcode endpoints. They don’t manually handle authentication flows. They discover capabilities at runtime, maintain context across dozens of interactions, and compose tools dynamically based on what’s available.

MCP was designed for that interaction model. REST wasn’t. Understanding the architectural differences tells you when each protocol is the right choice, and why the default is shifting.

The Architectural Comparison

Dimension	REST	MCP
Connection model	Stateless. Each request is independent. No memory between calls.	Persistent session. State maintained across the entire interaction.
Discovery	Developer reads API docs, writes a client library, hardcodes endpoints.	Agent queries the server at runtime: “What tools do you have?”
Communication direction	Client-only. The server only responds to requests.	Bidirectional. The server can push updates and notifications to the agent.
State management	None at the protocol level. State lives in the application layer (tokens, cookies, session IDs).	Session state is a first-class protocol concept. The server knows who it’s talking to and what happened before.
Streaming	Bolted on via SSE, WebSockets, or long-polling. Not native to the protocol.	Native. Long-running operations stream results as they progress.
Error handling	HTTP status codes plus custom error schemas that vary per API.	Structured error responses with recovery hints. Consistent across every server.
Target consumer	Human developers writing application code.	AI agents composing tool calls dynamically at runtime.
Versioning	URL paths (/v1/, /v2/), headers, or content negotiation.	Capability manifests that evolve as the server adds features.
Authentication	OAuth, API keys, JWTs (each API implements its own pattern).	Standardized auth negotiation at connection time. One handshake per session.

These aren’t minor differences. They reflect two fundamentally different assumptions about who is consuming the protocol and how they interact with tools.

Connection Model: Sessions vs. Statelessness

REST’s statelessness was a design choice, not an accident. Roy Fielding’s original dissertation made the case clearly: stateless communication simplifies server implementation, improves scalability, and makes every request self-contained. For web applications where a human clicks a link, waits for a page, and clicks another link, this works. Each page load is independent. The server doesn’t need to remember what the user did three clicks ago.

Agents don’t work this way. An agent handling a customer complaint checks the order history, reviews the return policy, looks up the customer’s tier, drafts a response, and schedules a follow-up. That’s five tool calls that build on each other. Each call needs context from the previous ones. In REST, you’d need to re-send context with every request, or build a session layer on top of a stateless protocol, which is what most production REST APIs end up doing anyway.

MCP makes the session a protocol-level concept. The agent connects once. The session maintains state across every subsequent interaction. Tool calls reference previous results. The server knows the agent’s context. Multi-step workflows execute as a coherent sequence, not a series of disconnected requests stitched together with application logic.

Discovery: Runtime vs. Build-Time

This is the difference that matters most for agent architectures.

A REST API is consumed at build-time. A developer reads the documentation, understands the endpoints, writes a client library, and deploys it. If the API adds new endpoints, the developer updates the client. If the API changes a response format, the developer fixes the code. Every change requires human intervention, a code deployment, and probably a broken test suite before things work again.

MCP is consumed at runtime. When an agent connects to an MCP server, the first thing it receives is a capability manifest: here are the tools, here’s what each one does, here are the parameters, here are the return types. The agent reads this manifest and knows how to use every capability immediately. No hardcoded endpoints. No client library maintenance. No documentation-to-code translation.

When the server adds a new tool, the agent discovers it on the next connection. When a tool’s parameters change, the manifest reflects the change automatically. The agent adapts without code deployment, without developer intervention, without downtime.

This is what makes Deep Agents practical. A deep agent orchestrating multiple domain specialists (one for CRM, one for billing, one for support) needs to discover and compose capabilities across all of them dynamically. With REST, someone has to wire up every integration by hand. With MCP, the agent reads the manifests and starts orchestrating.

Bidirectional Communication: Push vs. Pull

REST is pull-only. The client asks a question. The server answers. If the client needs to know about a change, it polls, sending the same request repeatedly, hoping for a different answer. Workarounds exist (webhooks, SSE, WebSockets), but they’re additions to the protocol, not part of it. Every implementation is slightly different.

MCP is bidirectional from the start. The server can push data to the agent without being asked. A monitoring MCP server alerts the agent when a metric crosses a threshold. A CRM server notifies the agent when a deal stage changes. A ticketing server pushes new high-priority tickets as they arrive.

For agents, this changes the operational model. Instead of an agent that runs on a schedule (“check the inbox every five minutes”), you get an agent that reacts to events in real time. The server initiates the interaction when something happens. The agent responds immediately. Latency drops from polling intervals to milliseconds.

In enterprise environments where response time matters (escalating a critical support ticket, catching a pricing anomaly, flagging a compliance issue), the difference between “we check every five minutes” and “we respond instantly” is the difference between an agent that’s useful and one that’s transformative.

Streaming: Native vs. Bolt-On

Long-running operations are a pain point in REST. A request that takes 30 seconds to complete either blocks the connection (bad for the client) or returns immediately with a job ID that the client polls for completion (better, but adds complexity). Every API handles this differently. There’s no standard pattern.

MCP handles streaming natively. A tool that runs a complex analysis, generates a large dataset, or executes a multi-step workflow streams results as they’re produced. The agent receives partial results, progress updates, and the final output through the same connection. No polling. No job IDs. No custom retry logic.

This matters for the workflows that agents actually run in production. A Deep Agent analyzing a customer portfolio doesn’t wait silently for 45 seconds and then dump a result. It streams insights as it works through the data. The human overseeing the agent sees progress in real time. The downstream systems that consume the results can start processing before the full output is ready.

When REST Is Still Right

REST isn’t going away. It solves specific problems well, and those problems don’t disappear because agents arrived.

Public APIs for human developers. If the consumer of your API is a developer writing code, REST is the right choice. REST’s simplicity, widespread tooling support, and massive ecosystem make it the default for developer-facing interfaces. GitHub’s REST API, Stripe’s API, Twilio’s API. These serve human developers building applications, and REST serves them well.

Simple CRUD operations. Create, read, update, delete on a single resource type. That is REST’s sweet spot. If the interaction is one request, one response, no session context needed, REST is simpler and more appropriate than spinning up an MCP session.

Human-facing web applications. Browsers speak HTTP. Web apps fetch pages and data via REST. This doesn’t change. MCP isn’t competing with REST for the browser. It’s competing for the agent layer, the machine-to-machine communication that agents require.

Existing infrastructure. The world runs on REST APIs. Every SaaS product, every enterprise platform, every internal tool exposes REST endpoints. MCP doesn’t require ripping any of this out. MCP servers wrap existing REST APIs. The Salesforce MCP server calls Salesforce’s REST API internally. The PostgreSQL MCP server uses the database’s existing protocol. MCP is an agent-native layer on top of existing infrastructure, not a replacement for it.

When MCP Wins

MCP becomes the right choice when three conditions are present.

The consumer is an AI agent, not a human developer. If the thing calling your tool is an LLM-powered agent that needs to discover capabilities, maintain context, and compose actions dynamically, MCP matches the interaction model. REST forces the agent to pretend it’s a human developer who memorized the API docs.

The interaction is multi-step. One request, one response? REST is fine. Five requests that build on each other, with context carried forward and decisions made based on accumulated state? MCP’s session model handles this natively. REST requires you to build a session layer on top of a stateless protocol.

Tools need to be composed at runtime. When an agent selects which tools to use based on what’s available, not based on what a developer hardcoded, MCP’s discovery model is the enabling architecture. The agent reads capability manifests and assembles its toolset dynamically. This is how Business-as-Code works in practice: agents reading schemas and skills to understand the domain, then discovering available tools via MCP to execute on it.

The Protocol Shift Is Already Happening

This isn’t a theoretical prediction. The shift from REST to MCP for agent-tool communication is already underway. Every major AI provider supports MCP clients. Thousands of MCP servers exist. Registries like mpak.dev provide discovery, search, and security scoring. NimbleBrain has built 21+ production MCP servers and deploys MCP-based agent systems in enterprise environments.

The parallel to the SOAP-to-REST transition is instructive. SOAP worked. It was enterprise-grade. It had tooling. But REST fit the web’s architecture better: simpler, more aligned with how HTTP worked, more natural for the patterns developers needed. SOAP didn’t disappear overnight, but REST became the default because it matched the interaction model of the era.

MCP is to the agent era what REST was to the web era. Not because REST failed, but because agents need a protocol designed for persistent connections, dynamic discovery, and multi-step workflows. REST was never designed for that. MCP was.

The organizations building on MCP now (investing in server infrastructure, establishing governance through frameworks like the MCP Trust Framework, training teams on the protocol) are building the integration layer that every agent initiative will depend on. The ones waiting for MCP to “mature” are accumulating integration debt that compounds with every agent they deploy.

For a complete introduction to the protocol, see MCP Explained. For the enterprise adoption playbook, see MCP for Enterprise.