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

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.

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 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.

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.

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.

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, and compare MCP with automation platforms in MCP vs Zapier, Make and n8n.

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?”.

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). On 20 May 2026 the NSA published an advisory on MCP risks 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 page.

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.

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.

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.