In its March 13 guide to MCP vs REST API design, WorkOS argues that companies adding AI-agent access should generally keep their existing REST interfaces and place the Model Context Protocol, or MCP, above them as an agent-facing layer. This is architectural guidance from WorkOS, not a product launch or an independently tested comparison.
The distinction is about the caller. WorkOS says REST works well when a developer has already read documentation, selected an endpoint and written deterministic code around its request and response format. An LLM-driven agent instead needs to find available actions while it is running, select among them and retain context while completing work across several steps.
What is the difference between MCP and a REST API?
WorkOS describes MCP as an open, JSON-RPC-based standard, first published by Anthropic in November 2024. An MCP server can present tools, resources and prompts for an AI application to discover, then let the application invoke them through a stateful session.
REST is a general-purpose HTTP interface built around discrete, stateless requests. That is not a defect. Statelessness works well with the machinery developers have spent years building, including caching, content delivery networks, load balancers, API gateways and rate limiters. WorkOS says it remains the sensible interface for conventional application integrations and high-throughput, low-latency web data access.
The problem, in WorkOS’s account, starts when the client is deciding what to do from natural-language instructions rather than executing a prewritten integration. A typical REST API does not announce its current capabilities at runtime. Calls do not carry shared session state by default. And each provider has its own endpoint layout, request fields, authentication scheme and error behavior, leaving an agent builder to create separate adapters.
MCP is meant to supply a common agent-facing layer around those underlying API operations, according to WorkOS. That does not make MCP a replacement transport for every existing integration, nor does the company’s guide establish that it is faster, safer or better in every workload.
When should an API add MCP?
WorkOS’s practical split is straightforward: retain REST when developers build clients that know their operations ahead of time; consider MCP when agents must inspect capabilities and execute multi-step tasks at runtime. For an API provider, that means the likely work is exposing carefully chosen higher-level tools over existing services, rather than throwing out a mature REST surface because the industry acquired another acronym.
The protocol choice also does not settle authorization. In separate guidance, WorkOS says agents should use credentials that expire, are restricted to the task, identify the authorizing user and can be revoked independently. Those controls matter because an agent may select tools and sequence actions at runtime, unlike a conventional service account following fixed code.
WorkOS’s own later management MCP server illustrates the permission issue. The company says it connects through OAuth and takes on the dashboard user’s existing roles, while excluding credential creation, impersonation, billing and account administration. It also says sensitive fields are removed from responses and certain irreversible deletions need a second confirmation. An MCP wrapper can make an API legible to an agent; it does not absolve the API owner from deciding what that agent may actually do.
This story draws on original reporting from Daring Fireball.
