The mcp vs rest api decision is mostly about the client, according to a sponsored March 13 post from WorkOS: developer-written software already knows the endpoint it needs, while an LLM-powered agent may need to find available operations and choose among them while it is running. The company’s proposed answer is additive. Keep the REST service interface and consider putting an MCP-facing layer in front of it for agents.
That distinction is less glamorous than declaring one protocol the winner, but it is the useful one. REST remains the familiar general-purpose interface for web apps, mobile clients, command-line tools and service-to-service calls. Model Context Protocol, or MCP, defines a common way for AI applications to obtain context and call external tools and services.
Does MCP replace a REST API?
WorkOS says no. Its model has a REST API continuing to run the business logic, with MCP above it to expose capabilities in a format an agent client can discover and invoke. WorkOS describes MCP as an open, JSON-RPC-based standard originally published by Anthropic in November 2024, using stateful sessions for AI applications to discover external tools, resources and prompts.
An API team with conventional, deterministic clients therefore has no evidence here that it needs to discard REST. WorkOS points to REST’s mature operating machinery: HTTP caching, content-delivery networks, load balancers, API gateways and a wider documentation and testing ecosystem that includes OpenAPI, Swagger UI and Postman. Its stateless request model also fits workloads that need caching, load balancing and horizontal scaling, the company says.
The agent problem starts when code is no longer prewritten around a fixed sequence of endpoints. WorkOS uses an illustrative sequence: an agent looks up a user, checks order history, then changes a shipping address. In REST, each request is independent, so the client has to retain and pass workflow context itself. The company also argues that differing endpoint designs, parameters, authentication schemes and error formats can leave an agent needing custom handling for every service.
a16z, an investment firm, makes a similar analytical case: developers often write specialized business logic for each system an agent needs to use. Its description of MCP is narrower and useful: an open protocol intended to generalize how models fetch data, call tools and interact with services. a16z says an agent can use such a contract to select tools and sequence them through a task. That is analysis, not a comparative benchmark.
When should an API team expose MCP?
- Keep REST when clients are conventional applications with code that already knows what calls to make, or when established HTTP-oriented infrastructure is central to the delivery path.
- Consider MCP when a compatible AI client must discover available tools or retrieve context at runtime and execute multi-step workflows through a standardized tool interface.
- Plan for both when the same service must serve developer-authored clients and agent clients. This is an architecture decision, not a protocol fashion contest.
There is another route, though the evidence is weaker. Participants in a GitHub community discussion argued that a well-described REST API plus a middle layer could expose tool descriptions and calls to models, with OpenAPI supplying some of the description. Other participants said direct REST use would still need such added interfaces. That discussion is not a protocol specification or a settled technical finding.
Neither WorkOS nor the other material supplies measured comparisons of latency, reliability, security, adoption or implementation cost. Those omissions matter. The supportable conclusion is limited: MCP is an optional agent-oriented contract; REST remains the service interface and operational base in WorkOS’s proposed design.
This story draws on original reporting from Daring Fireball.
