# What is MCP? The complete guide to the Model Context Protocol

> What is MCP? A plain-English guide to the Model Context Protocol: history, how an MCP server works, how it differs from APIs and RAG, security and adoption.

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

The **Model Context Protocol (MCP)** is an open standard that lets an AI assistant connect to software, databases and services so it can read information and take action there. This guide covers what an **MCP server** is, where the protocol came from, how it works, how it differs from an API or RAG, which risks it carries, and how Ondes PRO applies it across an entire business.

## What is MCP? The one-minute definition

On its own, a large language model only knows what it learned during training and what you type into the chat. It has no idea what orders came in today, how much stock is left or what is on your calendar. To use any of that, it needs a door into your data — and someone has to decide what it may do once inside.

The **Model Context Protocol** standardises that door. Software that wants to be usable by AI publishes an **MCP server**; an AI application that wants to plug into software ships an **MCP client**. Both speak the same language: the client asks the server what it can do, the server answers with a precisely described list of tools, and the model decides for itself which ones to call to answer your request.

The usual analogy is a USB-C port for AI: one connector, whatever device sits on the other end. It only goes so far — an MCP tool is not a cable, it carries meaning, permissions and side effects — but it captures the point: you build the integration once and it works with every compatible assistant.

- **25 Nov 2024** — protocol launched by Anthropic
- **Dec 2025** — handed to the Agentic AI Foundation, under the Linux Foundation
- **10,000+** — [active MCP servers](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/) announced when MCP joined the Agentic AI Foundation (December 2025)
- **2** — standard transports: stdio locally, Streamable HTTP remotely

## What is MCP used for? The N × M problem

Before MCP, every assistant vendor built its own connectors, and every software vendor had to write one per assistant. With N assistants and M applications, that meant N × M integrations, each different, each needing upkeep. One assistant’s “plugins” did not work in another, and niche software was left out entirely.

A shared protocol turns that into N + M: each assistant implements the client once, each application implements the server once. It is exactly what the Language Server Protocol did for code editors, and MCP openly draws on it: a programming language no longer needs a plugin per editor, it ships one language server and every editor benefits.

For a business the payoff is concrete. You are no longer tied to whichever assistant your software vendor picked: if your business software exposes an MCP server, you can use it from Claude today, from a code editor tomorrow, and from whatever assistant your team adopts next year.

## A short history of the Model Context Protocol

How a single vendor’s proposal became an industry standard.

| Date | Milestone |
| --- | --- |
| 25 November 2024 | Anthropic open-sources the protocol, with a specification and SDKs ([announcement](https://www.anthropic.com/news/model-context-protocol)). |
| March 2025 | OpenAI announces support; a spec revision introduces the Streamable HTTP transport and an OAuth-based authorisation framework. |
| April 2025 | Google DeepMind comes on board. |
| May 2025 | Microsoft showcases MCP support across its products at Build. |
| June 2025 | Another revision formally makes an MCP server an OAuth resource server. |
| December 2025 | The protocol moves to the Agentic AI Foundation, a directed fund of the Linux Foundation co-founded by Anthropic, Block and OpenAI ([announcement](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/)). |
| 28 July 2026 | Major revision: a stateless protocol, authorisation aligned with OAuth and OpenID Connect, Tasks and MCP Apps extensions ([announcement](https://blog.modelcontextprotocol.io/posts/2026-07-28/)). |

## Who maintains MCP? A neutral, long-lived standard

A protocol owned by a single vendor is a fair cause for concern: it can change course, or vanish. That is exactly why Anthropic handed MCP over in December 2025 to the **Agentic AI Foundation** (AAIF), a directed fund of the Linux Foundation. The foundation was co-founded by Anthropic, Block and OpenAI, and is backed by Google, Microsoft, AWS, Cloudflare and Bloomberg.

Governance now works like any open project: a public specification, a documented proposal process, reference implementations and SDKs in several languages. Direct competitors funding the same foundation is a strong durability signal for a standard this young.

## How an MCP server works: host, client and server

The architecture has three roles. The **host** is the application you use: a chat assistant, a code editor, a terminal. The **MCP client** lives inside the host and holds one connection to one server — a host connected to five servers runs five clients. The **MCP server** is the program that exposes a piece of software’s capabilities; it can run on your machine or be hosted by the vendor.

Messages are **JSON-RPC 2.0**: requests, responses and notifications encoded as JSON. At the start, client and server agree on a **protocol version** — versions are dated, such as `2025-06-18` — and on the features each supports. The client can then list the server’s tools and call them with arguments that match their schema.

The crucial part is that **the model decides**. Each tool comes with a name, a natural-language description and a JSON schema for its parameters. The model reads those descriptions the way it would read documentation and picks the right tool for your request. That is why an MCP server’s quality depends as much on clear descriptions as on correct code: a poorly described tool never gets called, or gets called at the wrong moment.

## Tools, resources, prompts: the building blocks of an MCP server

The specification defines several kinds of capability. A server does not have to offer all of them.

| Building block | Side | Triggered by | Example |
| --- | --- | --- | --- |
| Tools | Server | The model, as the request requires | Create a quote, list overdue invoices |
| Resources | Server | The host application | A file, a record, a documentation page |
| Prompts | Server | The user, explicitly | A “draft a payment reminder” template |
| Sampling | Client | The server, with the client’s consent | The server asks the model to summarise a text |
| Elicitation | Client | The server | The server asks the user for a missing detail |

In practice, tools are by far the most used building block: they are how an assistant reads and acts.

## MCP transports: stdio locally, Streamable HTTP remotely

The protocol defines two standard transports. **stdio** is for local servers: the host launches the server as a program on your machine and talks to it over standard input and output. It is simple and fast, ideal for a tool that works on your files, but it means installing and updating a program on every machine.

**Streamable HTTP** is for remote servers: the client sends its messages over HTTP to a single endpoint, and the server can reply in one piece or as a stream. In 2025 it replaced the first remote transport, which relied on two endpoints and Server-Sent Events. For online software it is the obvious choice: nothing to install, one URL to paste, and the vendor updates the server for everyone.

A remote transport needs authentication. The spec builds on **OAuth 2.1**: the server advertises where to sign in through metadata documents under `/.well-known/`, the client opens a sign-in window, the user consents, and the client receives an access token. Successive revisions tightened this — PKCE, resource indicators so a token only works for the intended server — and the July 2026 revision aligns it more closely with OAuth and OpenID Connect.

## What happens when you ask a connected assistant a question?

A typical request, from your sentence to the answer.

1. **The assistant discovers the tools** — On connection, the client fetches the server’s tool list and descriptions. They go into the model’s context, so it now knows what it can do.
2. **The model picks a tool** — You type your request. The model matches it against the available descriptions and decides to call one or more tools, building the arguments itself.
3. **The client asks for approval when needed** — Depending on the host and its settings, a call may need your approval, especially if it changes data. The server can enforce its own safeguards too.
4. **The server runs it and replies** — The server checks the user’s permissions, performs the action in the software and returns a structured result — or an explained refusal.
5. **The model writes the answer** — It reads the result, chains further calls if needed, then answers you in plain language, based on real, current data.

## An example: discovery in action

_Example conversation · demo data (Atelier Lumen)_

> **You** : Which lights have dropped below their stock threshold, and is a production order already planned for them?
>
> 🔧 `ondes_etat` Signed in as Karim Benali; Inventory, Store and Invoicing modules available.
>
> 🔧 `ondes_chercher` “stock threshold” — finds `inventory/composants` and `inventory/ordres-production`.
>
> 🔧 `ondes_ressource` `inventory/composants` sheet: fields, available filters and ordering.
>
> 🔧 `ondes_appeler` `GET inventory/composants` filtered on low stock — 3 items.
>
> 🔧 `ondes_appeler` `GET inventory/ordres-production` — 1 order in progress.
>
> **Assistant** : Three items are below threshold: **Trépied lamp** (4 against a threshold of 10), **Laiton pendant** (6 against 12) and **Arc floor lamp** (2 against 5). Only the Arc floor lamp has a production order running, with 15 units due on 6 November. Want me to draft orders for the other two?

## MCP vs API: what is the difference?

A **REST API** is written for developers: endpoints, HTTP verbs and documentation a human reads before writing code that will call it the same way every time. An **MCP server** is written for a model: it describes itself at connection time, in terms an AI understands, and the model decides at run time what to call.

They are not rivals. Most MCP servers sit on top of an existing API, acting as its discovery and security layer for assistants. An API remains the right tool for deterministic integrations — syncing an online store or an accounting package — where every call must be predictable; MCP shines when the request comes in plain language and the path to an answer is not known in advance.

A common claim is that “MCP is stateful, REST is stateless”. It was never a fundamental difference, and the July 2026 protocol revision made it moot by dropping server-side sessions. We go deeper in [MCP vs REST API](https://ondes.pro/en/integrations/mcp/mcp-vs-rest-api), and compare MCP with automation platforms in [MCP vs Zapier, Make and n8n](https://ondes.pro/en/integrations/mcp/mcp-vs-zapier-make-n8n).

## MCP, APIs and RAG at a glance

|  | REST API | RAG | MCP |
| --- | --- | --- | --- |
| Built for | A developer writing code | A model that must quote documents | A model that must read and act |
| Data | Current, structured | Indexed copy, sometimes stale | Current, read at the source |
| Writes | Yes, coded in advance | No | Yes, decided at run time |
| Permissions | Those of the key or token | Often those of the whole index | Those of the signed-in user |
| Discovery | Docs read by a human | Not applicable | The server describes itself to the model |

## MCP vs RAG: rivals or complements?

**RAG** (retrieval-augmented generation) splits documents into chunks, indexes them in a vector database, then injects the passages closest to the question into the conversation. It is an excellent way to query a stable corpus — a knowledge base, contracts, a manual — and have the model cite its sources.

Its limits are those of any copy. The index always lags behind reality, it has no notion of what a given user may see unless permissions are rebuilt alongside it, and it cannot take action. Asking a RAG pipeline “which invoices are overdue this morning?” means querying a snapshot taken yesterday.

MCP covers the other half: reading **live** data at the source, with the permissions of the person asking, and acting on it. The two combine well — an MCP server can even expose a document-search tool built on RAG. The useful question is not “which one”, but “does this information change, and do we need to act on it?”.

## Is MCP secure? The risks worth knowing

Letting an AI act inside software creates new risks, and the ecosystem learned about them on the go. In July 2025 a critical flaw was fixed in `mcp-remote`, a widely used utility that bridges a remote server to a local client ([CVE-2025-6514](https://nvd.nist.gov/vuln/detail/CVE-2025-6514)). On 20 May 2026 the NSA published [an advisory on MCP risks](https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf) for organisations.

The most discussed risks are well known: a malicious or compromised server, booby-trapped tool descriptions that steer the model, **prompt injection** through content the assistant reads (an email, a web page) that pushes it into an unintended action, and over-privileged connections nobody remembers to revoke.

The countermeasures are sound engineering: only install servers you trust, prefer servers hosted by the vendor of the software in question, require OAuth with PKCE, short-lived tokens bound to one server, permissions limited to the user’s own, easy revocation, writes that are confirmed or testable, and call logging. What Ondes PRO does is detailed on the [MCP server security](https://ondes.pro/en/integrations/mcp/security) page.

## Who uses MCP? Adoption and ecosystem

Adoption was fast. After Anthropic, which built it into Claude from day one, OpenAI announced support in March 2025, Google DeepMind followed in April, and Microsoft featured it at Build in May. Most AI-assisted code editors — Cursor, Visual Studio Code with GitHub Copilot, Windsurf, Zed, Cline, JetBrains IDEs — can now connect to a remote MCP server.

On the server side, the Agentic AI Foundation counts more than ten thousand public ones: developer tools, databases, cloud services and, increasingly, business software for invoicing, CRM, project management and e-commerce. Automation platforms followed by exposing their workflows as MCP tools.

One limitation remains for businesses: most of those servers cover a single domain. Plugging an assistant into invoicing, CRM, inventory and calendar often means connecting four servers from four vendors, with four sign-ins and four permission models — and an AI left to stitch the pieces together.

## Should you wait for the protocol to settle?

The protocol evolves through dated revisions, and both client and server announce the versions they support, settling on the newest one they share. A new revision therefore does not break existing connections overnight; it opens new options that everyone adopts at their own pace.

For users, waiting gains little: connecting to a remote server means pasting a URL and signing in, and keeping up with the spec is the server vendor’s job. For developers, the advice is to build on a reference SDK and the Streamable HTTP transport, the stable anchors of the ecosystem.

## How Ondes PRO applies MCP: one server for the whole business

Ondes PRO is all-in-one business software: online store, inventory and manufacturing, quotes and invoices, CRM, Kanban, calendar, video conferencing, email, an encrypted Drive and automations. Every customer runs their own instance, hosted in France, and **every instance ships with an MCP server** at `https://<your-workspace>.ondes.pro/mcp/`, included in every plan.

Because it spans every module, a single request can cross several of them: “draft the quote, check stock and book a delivery slot” happens in one conversation over one connection. The server uses the Streamable HTTP transport, negotiates protocol versions `2025-06-18`, `2025-03-26` and `2024-11-05`, and was designed **stateless** from the start: no session is kept on the server.

Rather than exposing each of its API’s roughly 135 resources as a separate tool — which would flood the assistant’s memory — it offers **eight stable tools**. Their descriptions and schemas fit in about **2,700 tokens** of permanent context, against nearly 44,000 for the documentation file assistants used to be handed. Documentation is served on demand, generated on every call from the workspace’s real routes, and filtered by the signed-in user’s permissions.

## The eight tools of the Ondes PRO MCP server

Six to understand the API without guessing, two to act.

- `ondes_etat` (Read) — **Connection status** : Who is connected, which modules are reachable and which permissions the connection carries. The assistant calls it once to learn its scope.
- `ondes_guide` (Read) — **API guide** : The API guide, section by section: a summarised table of contents first, then only the sections that matter (pagination, idempotency, payments…).
- `ondes_chercher` (Read) — **Search** : Searches a business term (“quote”, “stock”, “webhook”) across both the resource inventory and the guide.
- `ondes_ressource` (Read) — **Resource sheet** : Everything needed to call one resource correctly: URL, verbs, typed and required fields, filters, ordering, actions, required permission, test twin.
- `ondes_impossible` (Read) — **What the API does not do** : The list of what deliberately does not exist. The assistant checks it before inventing a URL: this is what keeps it from hallucinating.
- `ondes_exemple` (Read) — **Complete recipes** : Whole scenarios already verified against the real API: create, read without N+1 calls, invoice, subscribe to events.
- `ondes_appeler` (Write) — **Call the API** : Runs a real call with the user's identity. Writes go to test mode by default, and a dry run validates a request without writing anything.
- `ondes_assistant` (Write) — **Ask the Ondes PRO assistant** : Asks a business question to the built-in assistant, which aggregates several modules. Its writes come as a plan, executed only after approval.

## What the Ondes PRO server guarantees

- **OAuth 2.1 authentication** with PKCE S256 and no client secret, or a scoped **API key** that never outranks its holder.
- **Your permissions, nothing more**: the assistant only sees and does what the signed-in person can, company by company.
- **Safe writes**: test mode by default when a resource has a test twin, dry runs on any resource, automatic idempotency, and plans that need your approval for the built-in assistant.
- **No invented URLs**: the `ondes_impossible` tool lists what the API deliberately does not do.
- **Instant revocation**, one connection at a time, and a log of every call.

## Put it into practice

- [MCP server](https://ondes.pro/en/integrations/mcp) — Plug the AI assistant of your choice into your whole business, with your permissions and nothing more.
- [Claude](https://ondes.pro/en/integrations/mcp/clients/claude) — Claude Desktop, claude.ai and Claude Code: one custom connector, one OAuth sign-in, and you are set.
- [MCP clients](https://ondes.pro/en/integrations/mcp/clients) — Which AI assistant to plug into your workspace, and where each one sets up the connection.
- [Modules available over MCP](https://ondes.pro/en/integrations/mcp/modules) — Eleven business modules behind one MCP server: what the assistant can read and do in each.
- [MCP vs REST API](https://ondes.pro/en/integrations/mcp/mcp-vs-rest-api) — What really sets them apart, when to pick which, and why at Ondes PRO they work together.
- [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 an MCP server used for?

An MCP server exposes a piece of software’s capabilities — reading data, triggering actions — to an AI assistant through the Model Context Protocol. It describes its tools to the model, checks the user’s permissions and runs the calls. It can run on your machine (stdio transport) or be hosted remotely (Streamable HTTP).

### What does MCP stand for?

MCP stands for Model Context Protocol. It is an open standard launched by Anthropic on 25 November 2024 and handed in December 2025 to the Agentic AI Foundation, a directed fund of the Linux Foundation.

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

An API is designed for developers writing predictable code; an MCP server is designed for a model, which discovers the tools at connection time and decides which to call. An MCP server often sits on top of an existing API, so the two are complementary.

### MCP vs RAG: does MCP replace RAG?

No. RAG queries an indexed copy of documents, ideal for a stable corpus. MCP reads live data at the source, with the user’s permissions, and can take action. They combine well: an MCP server can expose a document search built on RAG.

### Will MCP replace traditional integrations?

Not entirely. Deterministic integrations, such as syncing a website or accounting software, are still better served by an API and webhooks. MCP opens a new use: driving software in plain language when the path to an answer is not known in advance.

### Who maintains MCP, and will it last?

Since December 2025 the protocol has been stewarded by the Agentic AI Foundation under the Linux Foundation, co-founded by Anthropic, Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. Its specification is public and evolves through dated revisions.

### How much does an MCP server cost?

The protocol is open and royalty-free. Cost depends on the server’s vendor: with Ondes PRO, the MCP server is included in every plan, with no add-on to enable. See [pricing](https://ondes.pro/en/pricing).

### Can I connect an MCP server to a CRM or invoicing tool?

Yes, if the software publishes an MCP server. Ondes PRO’s covers CRM, invoicing, inventory, the online store, projects and calendar at once, so a single request can cross several modules.