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

> MCP vs REST API: what actually differs, why “MCP is stateful” is outdated, when to pick each one, and how Ondes PRO runs both on the same foundation.

Updated on 2026-10-21 · The Ondes PRO team · https://ondes.pro/en/integrations/mcp/mcp-vs-rest-api

The **Model Context Protocol (MCP)** and a **REST API** both open up a software product’s data, but to different readers: a REST API is consumed by code a developer writes, while MCP is consumed by an **AI assistant** that works out on its own what it can do. This page explains MCP vs API without shortcuts, debunks the most repeated misconception on the topic, and shows how Ondes PRO builds its MCP server on top of its v1 API.

## What is the difference between MCP and a REST API?

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.

## MCP and REST compared, criterion by criterion

The same criteria on both sides, applied to Ondes PRO.

| Criterion | REST API (Ondes PRO v1 API) | MCP server (Ondes PRO) |
| --- | --- | --- |
| Intended reader | Code written by a developer | An AI assistant, during a conversation |
| What is exposed | About 135 resources, each with its own URLs and verbs | 8 stable tools that reach those same resources |
| Discovery | Docs, an OpenAPI 3.1 schema and an explorer in the admin | The client lists tools on connect; `ondes_guide` and `ondes_ressource` serve docs on demand |
| Call sequencing | Fixed in advance, in code | Chosen by the model based on the request |
| Authentication | Scoped API key, JWT or session | OAuth 2.1 with PKCE, or the same API key |
| Safe writes | `/api/v1/test/…` twins and the `Idempotency-Key` header | Test mode by default, `simuler: true`, idempotency key set automatically |
| Server-side state | None: every request carries its identity | None: no `Mcp-Session-Id`, every call stands alone |
| Best for | Syncs, websites, repetitive high-volume jobs | One-off questions, cross-module actions, coding assistance |

Comparison made on 21 October 2026 on an Ondes PRO instance.

## “MCP is stateful, REST is stateless”: an outdated claim

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](https://blog.modelcontextprotocol.io/posts/2026-07-28/) 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.

> **What stateless means for you** — No session to reopen after a network drop, no server that “forgets” your conversation on restart: the assistant just sends the next call with its token. It is also what lets MCP be served by the same application as the API, with no dedicated infrastructure.

## Will MCP replace REST APIs?

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.

## When to use the REST API

- **Your website or app** lists products, takes orders or creates accounts: the code must behave identically on every visit.
- **Scheduled syncs**: accounting exports, catalogue imports, stock updates from another system.
- **Events**: receive a signed webhook when an order is paid or an invoice is issued — see [the Ondes PRO REST API](https://ondes.pro/en/integrations/rest-api).
- **Volume**: cursor pagination, `fields` to fetch only the columns you need, quotas reported in `X-RateLimit-*` headers.

## When to use MCP

- **A one-off question** about your data, asked in plain English: “How many brass pendant lights are left?”
- **An action spanning several modules**: draft a quote, create the matching Kanban card and block a time slot, in a single request.
- **Writing the integration code itself**: a coding assistant connected to the server reads your workspace’s exact documentation while it writes the REST call.
- **Access without a developer**: a business owner pastes the workspace address into [Claude](https://ondes.pro/en/integrations/mcp/clients/claude) and gets to work without writing a line.

## At Ondes PRO, MCP runs on top of the v1 API

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 same call, two ways

Listing overdue invoices. First, a developer writes the request; second, the assistant calls the `ondes_appeler` tool, which runs that very request.

```bash
# REST API: called by your code
curl "https://your-workspace.ondes.pro/api/v1/billing/factures/?statut=en_attente&date_echeance__lt=2026-10-21" \
  -H "Authorization: ApiKey opk_…"

# MCP: called by the assistant (JSON-RPC request sent by the client)
curl -X POST "https://your-workspace.ondes.pro/mcp/" \
  -H "Authorization: Bearer <OAuth token>" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"ondes_appeler",
                 "arguments":{"chemin":"billing/factures",
                              "params":{"statut":"en_attente","date_echeance__lt":"2026-10-21"}}}}'
```

You never type the second request yourself: your MCP client does it for you.

## MCP helping you write REST code

_Example conversation · demo data (Atelier Lumen)_

> **You** : Atelier Lumen’s website should send its own confirmation email when an order is paid. Write the webhook receiver in Python.
>
> 🔧 `ondes_chercher` Searches “webhook”: the `developer/abonnements` resource and the guide section on signed events.
>
> 🔧 `ondes_exemple` Fetches the “subscribe to events” recipe, verified against the live API.
>
> 🔧 `ondes_impossible` Confirms no route returns an existing secret: it is shown only at creation.
>
> **Assistant** : Here is the receiver: it verifies the `Ondes-Signature` header (HMAC-SHA256 over timestamp and body), rejects stale timestamps, then handles the `commande.payee` event. The secret is displayed once when the subscription is created, so I read it from an environment variable. Shall I validate the subscription with a dry run first, writing nothing?

## Security: is MCP riskier than an API?

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](https://ondes.pro/en/integrations/mcp/security) page.

## Keep reading

- [What is MCP?](https://ondes.pro/en/integrations/mcp/what-is-mcp) — The complete guide to the Model Context Protocol: definition, architecture, comparisons, security and adoption.
- [REST API v1](https://ondes.pro/en/integrations/rest-api) — Around 135 REST resources, scoped keys, an OpenAPI schema and signed webhooks.
- [Build an integration](https://ondes.pro/en/integrations/mcp/guides/build-an-integration) — Scoped keys, signed webhooks, idempotency and test mode for a back office that never creates duplicates.
- [MCP server security](https://ondes.pro/en/integrations/mcp/security) — OAuth 2.1, short-lived tokens, instant revocation and write safeguards: what your IT team needs to know.

## Frequently asked questions

### What is the difference between MCP and an API?

A REST API exposes resources that code calls in a sequence written in advance. MCP exposes tools described in natural language that an AI assistant discovers and chooses during a conversation. Both run over HTTP; the difference is who is on the other end.

### Is MCP a stateful protocol?

Not any more. The 28 July 2026 specification removes the `initialize` handshake and the session ID, making the protocol stateless. Ondes PRO’s server already opened no session before that.

### Will MCP replace REST APIs?

No. Most MCP servers call an API behind their tools. The API remains the right answer for any repetitive, deterministic job; MCP adds a layer designed for AI assistants.

### Do I need an API key to use the Ondes PRO MCP server?

No. The default connection uses OAuth: your client opens a window from your workspace and you sign in. An API key is still an option when you want to restrict access to specific scopes.

### MCP vs RAG: what is the difference?

RAG retrieves document passages to enrich an answer. MCP gives the assistant tools to query and act inside software. An MCP server can serve documentation, as `ondes_guide` does, but its main job is reading live data and running actions.

### Can I use the REST API and MCP at the same time?

Yes, that is the intended setup. Ondes PRO’s MCP server replays its calls on the v1 API: same permissions, same quotas, same log. Your website talks to the API, your assistant talks to MCP, and both see the same data.

### Are the MCP server and the API part of the subscription?

Yes, both are included in every Ondes PRO plan, from Essentiel to Entreprise. See [pricing](https://ondes.pro/en/pricing).