MCP vs REST API: when each one fits, and when it doesn't

If you're building an AI agent on top of a SaaS product, you'll hit this decision early: do you expose the product's capabilities through a REST API, or through an MCP server? The question sounds like a protocol choice. It isn't. It's a decision about who the consumer is, how they discover what's available, and how much of the integration work you're willing to own.

This piece is for engineering leaders and technical evaluators picking between the two — usually while building an agent that needs to reach an existing product. REST wins when you control both sides and the consumer is a human developer writing code against a stable contract. Model Context Protocol (MCP) wins when the consumer is an agent that needs to discover tools at runtime and reason about which one to call.

Both can coexist. Most production setups end up running MCP on top of REST. The interesting question is where each layer earns its keep.

How REST APIs work

REST is a design style for HTTP APIs. A client sends a request to a URL, the server returns a response, and the contract between them is written down in advance — usually in an OpenAPI specification or equivalent. The client reads the docs, generates or hand-writes the code, and calls the endpoints it needs. Every REST integration is a design-time commitment: the developer knew, before shipping, which endpoints they were going to hit and what the payloads looked like.

The strengths are well understood. HTTP semantics are universal. Every language has a client library. Caching, rate limiting, auth, and observability all work through mature middleware. Versioning is a solved problem — you deprecate, you sunset, you communicate. When a REST API is well-designed, a developer can build against it in an afternoon.

The weakness, in the agent context, is that REST assumes the consumer knows what it wants before the request. There's no standard way for the API to advertise its capabilities to a caller that's making decisions at runtime. Agents can call REST APIs — and they do, constantly — but every REST endpoint an agent invokes has to be wrapped in a tool definition somewhere else, usually by hand, and kept in sync as the API changes.

How MCP works

MCP is a protocol Anthropic published in late 2024 for connecting AI agents to external tools and data. It runs over JSON-RPC 2.0, usually with stdio or streamable HTTP as the transport, and it standardises three things: how a client discovers what tools a server exposes, how it calls those tools, and how it authenticates.

The important word is discovers. An MCP server advertises its tools at runtime through a tools/list call. The client — an agent, or the LLM behind it — reads that list, sees each tool's name, description, and input schema, and decides which one to invoke. The developer building the agent doesn't have to know in advance which tools exist. The developer building the server doesn't have to know in advance which agents will consume them. The protocol handles the introduction.

MCP is protocol-only. It defines the wire format and the shape of tool definitions. It doesn't tell you how to build a server, how to secure it beyond the OAuth 2.1 requirements introduced in the March 2025 spec revision and expanded through the June and November 2025 revisions, or how to keep it in sync with the underlying product. Those are implementation concerns. We've written separately on what an MCP server actually is and what the protocol standardises versus what it leaves to you.

One thing MCP is often confused for: it is not a replacement for REST. Almost every production MCP server in the wild is a thin layer over one or more REST APIs underneath. MCP is the interface an agent sees; REST is often what the server actually calls.

Comparison

When to choose REST

Choose REST when the consumer is a developer or a deterministic system, and the integration is written once and maintained. If someone on your team is going to write code that calls POST /v1/invoices and ship it to production, REST is the right primitive. You get versioning, you get caching, you get every piece of HTTP tooling ever built. You also get a contract you can test in CI.

Choose REST when you need mature auth models beyond OAuth 2.1. Bearer tokens, service accounts, mTLS, signed requests — REST supports all of them because the ecosystem has had two decades to build them. MCP's OAuth 2.1 requirement is good practice but narrower in scope.

Choose REST when the integration pattern is system-to-system rather than agent-to-product. Webhook receivers, scheduled syncs, ETL jobs, service meshes — none of those benefit from runtime tool discovery. They benefit from a stable contract and a clear versioning policy. Our take on why API-first strategies aren't automatically agent-ready covers where this line falls.

And choose REST when you're the one designing the API from scratch. You should build a clean REST API first. Wrapping it in MCP later is straightforward. Trying to design MCP-native without a REST foundation underneath usually means you're skipping the versioning, the docs, and the change-management discipline that will bite you later.

When to choose MCP

Choose MCP when the consumer is an agent that needs to reason about which tool to call. The whole point of runtime discovery is that the agent doesn't have to be told in advance what's available. If you're building a general-purpose assistant on top of Claude, ChatGPT, or a similar foundation model, and you want users to be able to point it at new tools without rebuilding the agent, MCP is the interface designed for that.

Choose MCP when you want tool descriptions to travel with the tool. In a REST world, the API is one thing and the description of that API — for an agent's purposes — lives somewhere else, usually in a hand-written tool spec inside the agent codebase. Every API change means two updates. In MCP, the description lives on the server. One update, one deploy.

Choose MCP when you're building for a heterogeneous agent ecosystem. If your product needs to work with Claude Desktop today, Cursor tomorrow, and whatever agent framework wins next year, exposing an MCP server means you write the integration once. The clients handle themselves.

And choose MCP when the alternative is asking every agent developer to hand-write a wrapper around your REST API. The connector maintenance cost of that pattern compounds — every API version bump means every wrapper needs updating, and most of them won't be.

How Pontil fits

The REST vs MCP framing usually collapses into a follow-on question: fine, we'll expose MCP — but who's going to build the server, keep it in sync with the product, and handle auth as the authenticated user? That's the work most teams underestimate. The protocol is the easy part. The tool definitions, the OAuth flow, the change management as your API surface shifts week to week — that's where agent projects stall.

Pontil is a Tools-as-a-Service platform. We generate tools from the APIs a product already has, run them as the authenticated user, and keep them current as the underlying code changes. That means the MCP server (or the equivalent tool surface for whatever protocol the agent uses) isn't a separate thing your team maintains — it's a generated artefact that stays aligned with your product. Protocol-agnostic by design: we support MCP where MCP is the right fit, and we don't force it where a direct tool interface works better. If your team is picking between REST and MCP mostly because you don't want to own the MCP server long-term, that's a version of the problem Pontil exists to remove.

What we'd choose

Both. Almost always both.

Build a clean REST API. Version it properly. Document it. That's the foundation your developer ecosystem needs regardless of what happens with agents. Then expose an MCP server (or an equivalent tool surface) on top of it for agent consumers. The MCP layer is where runtime discovery, per-tool auth scoping, and agent-friendly descriptions live. The REST layer is where deterministic, code-authored integrations continue to work.

The mistake we see is teams treating this as an either/or. They either dismiss MCP as hype and try to make REST work for agents by hand-writing tool wrappers, or they treat MCP as a replacement for REST and skip the API discipline that makes the underlying system usable. Both approaches produce something that works in a demo and falls over in production.

If you have to pick one to invest in first, and your product already has a REST API that works, invest in the tool layer on top of it. That's where the leverage is. If you don't have a working REST API yet, build that first — MCP without a stable underlying contract is just moving the mess.