MCP Is Not Replacing REST. It Is Replacing the Entire Mental Model of How Agents Use Tools.
REST was designed for humans writing code to call services. You read the docs, you write the client, you ship it. That whole loop assumes a developer is in the middle, translating intent into HTTP calls. When you put an LLM in the driver's seat, that assumption breaks completely, and the cracks are showing up in every agent system I have seen in production.
What Actually Happened
Model Context Protocol (MCP), originally introduced by Anthropic, has crossed from "interesting spec" to "actual adoption pressure" faster than most protocol transitions I have watched. The pattern is now visible across the ecosystem: Cognizant just expanded their Anthropic partnership specifically to bring Claude-powered agents to enterprise workflows, and when you look at what those workflows require, MCP is not optional. You cannot bolt REST onto an agent loop and call it done.
The short version of what MCP is: a standardized, bidirectional protocol that lets LLMs discover, negotiate, and invoke tools without a human writing a custom client for each integration. The server advertises its capabilities. The model reads them. The model calls them. No glue code, no prompt-stuffed API docs, no fragile JSON schema passed in a system prompt and hoped for the best.
REST was never the problem. HTTP is fine. The problem was the integration layer that had to exist between "LLM knows what it wants" and "service exposes an endpoint." That layer has been killing agent reliability in production.
The Technical Detail That Matters
Here is the specific failure mode that MCP fixes. In a typical REST-based agent integration, you stuff tool descriptions into the context window. The model reads them, generates a function call, and you parse that back into an HTTP request. This works until it does not, which is: when the schema drifts, when the model hallucinates a parameter name, when the endpoint returns an unexpected shape, or when you need the tool to push state back to the model mid-task.
MCP is a session-oriented protocol, not a request-response one. The connection stays open. The server can send notifications. The model can maintain state across multiple tool calls without you serializing and deserializing context between every round trip. For anything involving multi-step agent tasks, that is not a nice-to-have. It is the difference between an agent that can actually complete a workflow and one that loses the thread halfway through.
The other piece that matters architecturally: MCP separates capability discovery from capability invocation. The model can ask "what can you do?" before it commits to a plan. That changes how you build agent orchestration. Instead of hardcoding tool availability into your system prompt, you let the agent discover it dynamically. Your multi-tenant platform can serve different tool sets to different tenants from the same agent runtime, without rewriting prompts per customer.
What This Means for Builders
If you are running a RAG pipeline that exposes retrieval as a tool, you are probably doing it via a function-calling schema today. That works, but you are carrying a maintenance burden every time your retrieval interface changes. MCP gives you a contract that the agent runtime and the retrieval server negotiate directly.
If you are building a multi-tenant AI platform, the capability discovery model is the real unlock. You stop thinking about tools as static config and start thinking about them as services the agent can introspect. Tenant A gets access to Salesforce tools. Tenant B gets Jira tools. The agent figures out what is available per session. You stop managing a matrix of prompt templates.
If you are building agent frameworks, the session model means you can implement proper long-running task patterns, including progress updates, partial results, and cancellation, without hacking them on top of webhook callbacks and polling loops.
The practical risk right now: MCP servers vary wildly in quality. The spec is solid but the implementations are early. Plan for defensive handling on the client side.
One Thing to Do Today
Pull down the MCP TypeScript SDK from the official repo at github.com/modelcontextprotocol/typescript-sdk and spin up the example server locally. Then write a minimal MCP client that connects to it, calls the capability discovery endpoint, and logs what comes back. That single exercise will reframe how you think about tool integration faster than any blog post will, including this one.
Follow along here for daily breakdowns of what is actually moving in AI engineering.
Top comments (0)