MCP vs REST

Why Is MCP Getting Attention Now?

The protocol arrived in November 2024. In the eighteen months since, Microsoft, Google, AWS, and Cloudflare have all published reference implementations or first-party integrations. Over thirty Common Vulnerabilities and Exposures (CVEs) were filed against MCP servers and infrastructure between January and February 2026 alone, with vulnerabilities ranging from path traversal flaws to a CVSS 9.6 remote code execution in a package downloaded nearly half a million times. The gap between high adoption rates and lagging security issues.

Why is the MCP server vs REST API decision suddenly a conversation?

Solution design is simply a requirements decision. What makes the MCP server vs REST API discussion a live conversation right now is that most current writing on MCP weighs the functional requirements heavily and under-weights the non-functional ones. The non-functional requirements are often where production reviews are won or lost.

The functional axis is the part the field handles well:

• Use REST when the consumer is application code that knows in advance what it is calling and why.
• Use MCP when the consumer is an LLM agent that needs to discover capabilities at runtime and chain calls across them.

The dominant advice of "build both, wrap REST in MCP" stops at this level and treats the choice as resolved.

The non-functional dimension though is where the field gets quieter. Identity propagation. Per-user audit attribution. Data egress and boundary control. Latency under tool composition. Token cost when the agent has to load tool schemas at session start. These are the dimensions that decide whether a working pilot survives a production review, and they are the dimensions the discourse under-weights.

Putting the two axes together gives a simple test:

• REST fits when the integration is system-to-system and the contract is stable.
• MCP fits when the consumer is agentic, the integration surface is broad enough to justify dynamic discovery, and there is a defensible answer for identity propagation and per-user audit.
• Wrapping REST in MCP is the right move when you want agent consumers to reach an existing surface. The wrap solves discovery and composition. It does not solve governance.

Two of those three MCP conditions are not enough. Teams regularly satisfy the functional requirements and then discover that governance is the condition that actually qualifies the deployment. It is the difference between a successful pilot and a deployable production system.

The table below provides a comparison of MCP and REST.

The important distinction is not that MCP and REST serve different consumers. Most architects already understand that. The more consequential distinction is governance. REST inherited decades of patterns for propagating user identity, enforcing permissions, and attributing actions. MCP is still developing those operational patterns. The architectural risk is not adopting MCP. The risk is assuming the protocol solves governance problems it was never designed to solve.

How does an MCP server work?

Five components make MCP work: tools, resources, prompts, transport, and authorization.

The first four explain why MCP is useful. Tools expose actions an agent can invoke. Resources expose structured context. Prompts provide reusable workflows. Transport standardizes communication between client and server.

Authorization is different. It determines whether the identity of the requesting user survives the trip from the AI client, through the MCP server, and into the underlying system. That is where most enterprise deployments encounter trouble. A server can expose well-formed tools, use OAuth correctly, and successfully execute requests, yet still lose the identity of the originating user before reaching the back-end system. The result is an agent operating under a shared service account, with accountability detached from the human who initiated the action.

That distinction matters because production reviews rarely fail due to tool schemas or transport protocols. They fail when auditors discover that actions cannot be reliably attributed to individual users.

What happens to MCP servers at enterprise scale?

Three governance failures repeatedly surface in enterprise MCP deployments;

• The service account trap. Production MCP deployments commonly call the back-end with a single shared credential. Every request appears to come from the same technical identity, regardless of which employee actually initiated it. The agent effectively runs with the permissions of every user combined, and compliance reviews catch it. SOC 2, HIPAA, PCI-DSS, and GDPR all require per-user accountability that a shared credential cannot produce.
• The identity-forwarding gap. OAuth 2.1 can authenticate the user to the MCP server, but that does not automatically mean the user's identity is forwarded to the back-end system the tool calls. Azure architects building MCP through API Management have documented the same gap: until per-user identity is forwarded all the way to the back-end, the integration is only safe for public or system-level APIs. Current workarounds include subscription-level authorization and bespoke JWT-forwarding policies. Most public MCP implementations stop at the server boundary, so the back-end call goes out under whatever credential the server holds.
• The audit attribution gap. Tool name plus timestamp does not satisfy a SOC 2 or HIPAA audit. A defensible audit log records which human user the request originated from, what the agent's reasoning was at the point of the call, what data the call returned, and whether an access policy was consulted before the operation was permitted. Standard MCP server logging records none of those by default.

The same pattern sits behind all three failures. Enterprise integration evolved around known applications calling known interfaces. MCP changes the assumption. The consumer is now an agent that discovers capabilities at runtime and decides what to do mid-session. The protocol arrived quickly. The governance patterns needed to support it are still catching up.