For the past fifteen years, REST APIs have been the backbone of software integration. They're well-understood, battle-tested, and supported by a rich ecosystem of tooling. When a developer needs to integrate with your service, the workflow is familiar: read the docs, grab an API key, write some code that calls GET /users/123, parse the response, and handle errors.But a new class of API consumer has arrived: LLM-powered agents. And these consumers need to discover what your API can do, reason about which operation to use, and maintain context across multi-step workflows, all at runtime, without a human writing integration code in advance.This is the gap that the Model Context Protocol (MCP) fills. Originally published by Anthropic in November 2024, MCP is an open JSON-RPC-based standard that lets AI applications discover tools, resources, and prompts from external servers and invoke them through stateful sessions. It doesn't replace your REST API; it wraps it in a layer that AI agents can actually work with.The question for developers building APIs today isn't "MCP or REST?" It's "Do I need both, and if so, how do they fit together?"REST APIs: What they do wellREST APIs are general-purpose interfaces. They were designed to let any software system access another system's functionality or data, regardless of whether the client is a web browser, a mobile app, a CLI tool, or a microservice. They're stateless by design, which makes them easy to cache, load-balance, and scale horizontally. Decades of tooling exist around them: OpenAPI specifications, Swagger UI, Postman, API gateways, rate limiters, CDNs.For traditional software clients (where a developer writes deterministic code that knows exactly which endpoint to call and what parameters to pass) REST is excellent. The API acts as an abstraction layer: the requesting application doesn't need to know the internal details of the service, just how to format requests and understand responses. A frontend engineer building a dashboard doesn't need their API to explain itself at runtime. They read the docs, write the fetch call, and move on.REST also benefits from proven infrastructure. HTTP caching, content delivery networks, load balancers, and API gateways all speak REST natively. These techniques have demonstrated scalability over decades. When you need high-throughput, low-latency data fetching for a web application, REST remains the right tool.Where REST falls short for AI agentsThe problems emerge when the client is an LLM making autonomous decisions rather than a developer following a spec. REST wasn't created with AI or LLMs in mind, and that's fine, it wasn't supposed to be. But it means there are structural gaps when the consumer is an agent:‍No self-description at runtime. A REST API doesn't tell you what it can do, you have to know that going in. OpenAPI specs exist, but they're static documents designed for developer tooling, not for an LLM to interrogate at runtime. If the API changes or new endpoints are added, a developer has to manually update the client code. The API itself can't say "hey, I have a new capability you might want to use."‍Stateless by design. Each REST call is isolated. If an agent needs to look up a user, check their order history, then update their shipping address, it must manually pass context between each call. There's no session, no shared state, no memory of what happened two calls ago.‍Every API is a snowflake. Each REST API has its own unique endpoints, parameter formats, authentication schemes, and error conventions. If an AI agent wants to use five different REST APIs, it needs five different adapters; five sets of custom integration code, each with its own assumptions and edge cases.‍Designed for developers, not for models. REST API design principles emphasize composability, discoverability for humans, and atomicity (small endpoints that developers combine). These principles work well for human developers who read docs once, write code, and iterate cheaply. They actively hurt AI agents, who pay a token cost for every tool definition they have to reason over.MCP: Purpose-built for AI agentsWhere REST is a general-purpose interface that any software client can use, MCP was explicitly designed to integrate LLM applications with external data and tools. It standardizes patterns like providing context and invoking tools in ways that align with how AI agents actually operate.A useful analogy: MCP is to AI applications what USB-C is to laptops. A laptop with USB-C ports can connect to any peripheral (monitors, drives, power supplies) regardless of manufacturer, because they all share a common standard. Similarly, an AI agent using MCP can connect to any MCP server (databases, code repositories, email systems, calendars) because they all speak the same protocol. It doesn't matter who built the server; the interface is identical.MCP doesn't replace your REST API. It's a protocol layer that sits on top of your existing APIs and makes them consumable by AI agents. Your REST API handles the actual business logic. MCP provides the AI-native discovery and session management on top.The three primitivesMCP servers advertise their capabilities through three types of primitives:Resources are endpoints for information retrieval. A resource handler might return data from a database, fetch a document, or list items in cloud storage. Importantly, resources are read-only or passive – they provide data but typically do not cause side effects. For example, an MCP server for a knowledge base might have a resource called searchArticles that takes a query and returns relevant articles from a corpus. The server’s request handler for searchArticles would handle the JSON-RPC request by executing the search and formatting the results to send back. Resources often need to handle large data (files, big query results), so their handlers might support streaming chunks or pagination for efficiency.‍Tools are active operations that can perform side effects or computations. A tool handler might create a new record in a database, send an email, invoke an external API, or even control something like a web browser. Tools enable the AI to act on the world (within limits). For instance, an MCP server could expose a tool sendSlackMessage that, given a channel and message, posts to Slack. The request handler for this tool would contain the logic to call Slack’s API and return a success/failure result. Because tools can have effects, their handlers usually include validations and safety checks. They also define input parameters and output schema clearly, so the AI (and client) know how to use them.‍Prompts: These are a bit unique: they are reusable prompt templates or workflows that the server can provide to guide interactions with the AI model. Essentially, a prompt capability might supply a pre-defined prompt or chain-of-thought that the AI can use. For example, a server could have a prompt called sqlQueryTemplate that helps an AI format a database query request consistently. The request handler for a prompt might not hit an external system at all, but instead return a carefully crafted template or even initiate a multi-step workflow involving the model (some advanced MCP servers use prompt capabilities to orchestrate complex interactions). Prompt handlers ensure the template variables are filled and the final prompt is delivered to the AI client.Not every MCP server uses all three. In practice, many focus primarily on tools. But the important thing is that an AI agent can query an MCP server at runtime to discover which primitives are available and then invoke those capabilities through a uniform interface.How discovery actually worksThis is MCP's most significant departure from REST. When an MCP client connects to a server, it sends a tools/list request using JSON-RPC 2.0: