MCP vs REST API: what is the difference, and which should you use?

A REST API exposes resources — orders, invoices, products — behind URLs and HTTP verbs. A developer reads the docs, picks the calls, writes the code that chains them and handles failures. Everything is settled up front: the program does exactly what it was told, thousands of times a day if needed.

An MCP server exposes tools described in plain language, each with a parameter schema. An MCP client (Claude, Cursor, Visual Studio Code…) connects, fetches the tool list, and the model decides mid-conversation which tool to call and with what arguments. The integration logic is no longer written in advance; it is assembled on the fly from your request.

So the MCP vs API distinction is not about transport — both run over HTTP — but about who reads the description and who decides the sequence of calls. REST assumes a human writing code; MCP assumes a model reasoning. That is why they do not compete: they serve different jobs.

Plenty of comparisons boil MCP vs REST API down to one line: REST is stateless, MCP keeps state. That was a fair reading of early protocol versions, which had an initialize handshake and an optional session ID. It is no longer accurate.

The 28 July 2026 MCP specification makes the protocol explicitly stateless: no initialize exchange, no Mcp-Session-Id header, every request self-contained. Even before that, the Streamable HTTP transport let each server decide whether to open a session at all.

Ondes PRO’s MCP server made that call from day one: it issues no session ID and keeps nothing in memory between calls. A GET on its address returns 405, which the spec allows for a server that does not open a stream. It currently advertises protocol versions 2025-06-18, 2025-03-26 and 2024-11-05; its session-free design already matches the model the protocol later adopted.

The criterion that matters is therefore not state but audience. When an article tells you to “pick REST for scalability because MCP holds sessions”, check which protocol version it is describing.

No — and the way most MCP servers are built proves it: an MCP tool nearly always ends up calling an API. MCP is a description and discovery layer designed for language models. It does not replace the transport, the business logic or the access control that live behind the API.

A REST API remains the right tool whenever a job must be deterministic: syncing a catalogue every night, showing stock on a website, receiving a webhook on every payment. Nobody wants a model to “decide” how to import 5,000 orders. Conversely, writing code to answer “which Studio Nord invoices are overdue?” once would be overkill — that is precisely what MCP makes instant.

The MCP server is not a second front door with its own rules. The ondes_appeler tool replays the request against the real v1 API view: same permission checks, same key scopes, same quotas, same idempotency, same partitioning between companies, same structured error messages. Not a single access check is rewritten on the MCP side, so none can drift.

Documentation follows the same principle. ondes_guide, ondes_chercher and ondes_ressource serve, section by section, the guide generated from your workspace’s real routes — the one a developer reads in the admin. The server’s permanent context weighs around 2,700 tokens, where the old documentation file people copied into their repositories weighed 44,000 and went stale the moment it was copied.

In practice, whatever your assistant does through MCP, your code can reproduce through REST, and vice versa. Calls made over MCP even land in the same log as REST calls, tagged “MCP”.

The protocol is neither safer nor riskier than an API: it all depends on what the server allows. The risk specific to MCP is model autonomy — it can chain calls nobody reviewed. That is why Ondes PRO’s safeguards sit in the server: writes default to test mode when a resource has a twin, dry runs, a plan to approve for the built-in assistant, and the mode always stated in the response.

On identity, an OAuth connection acts with your full permissions, one hour per token, and can be revoked instantly; an API key keeps its limited scopes whether you use it over REST or MCP. Details are on the MCP server security page.