MCP explained: AI safely to your systems

The drawing above is a simplification. What it calls the MCP layer is an MCP server in the specification, and control sits in two places. The server decides which tools exist and what they may do. The AI application you work in asks for your permission before a tool does anything. Both places have to be set up properly.

In this article you read what MCP is and where it comes from, how it works, what an MCP server can offer, how it relates to an ordinary integration, what the risks are and how to start sensibly. Everything about how it works comes from the specification on modelcontextprotocol.io, version 2026-07-28.

What is MCP?

MCP stands for Model Context Protocol. It is an open protocol that lets applications built on a language model connect in a fixed way to data sources and tools outside them. The specification names three aims: sharing context with language models, making tools and capabilities available to AI systems, and building integrations that can be combined.

Anthropic released MCP in November 2024 as an open standard. On 9 December 2025 it moved to the Agentic AI Foundation, a new fund under the Linux Foundation, together with goose from Block and AGENTS.md from OpenAI. According to the Linux Foundation, MCP had been adopted by Claude, Cursor, Microsoft Copilot, Gemini, VS Code and ChatGPT, among others, and there were more than 10,000 published MCP servers at the time.

The specification takes its inspiration from the Language Server Protocol, which standardises how programming languages work across development tools. MCP does the same for AI: one way to connect context and tools, instead of a separate integration for every model and every system.

How does MCP work?

There are three roles. They talk to each other in messages that follow JSON-RPC 2.0, an existing standard for exchanging requests and responses.

Messages travel over one of two standard routes. With stdio, the application starts the server as a program on the same computer and they talk through standard input and output. With Streamable HTTP, every message is a request to a single address of the server, which can live somewhere else.

The version of 28 July 2026 made MCP stateless. There is no longer an opening exchange in which client and server agree on terms. Every request carries the protocol version and what the client can do. So if you build or choose a server, check which versions it supports. Older versions still work through a fallback that the specification describes.

What can an MCP server offer?

A server can offer three kinds of things. The difference lies mainly in who sets them in motion.

In the other direction, the application can give the server something back. In the current version that is mainly elicitation: the server asks the user for extra information, such as a missing customer number. Three older parts, roots, sampling and logging, have been marked for removal since 28 July 2026. They keep working during a transition period, which under MCP's policy normally lasts at least twelve months, but new integrations should no longer use them.

According to the specification, tools are meant to be controlled by the model. The model sees which tools exist and picks one itself based on your question. That is exactly why tool safety is the main subject of this article.

Is MCP different from an ordinary integration?

Yes and no. Behind the scenes, an MCP server often simply calls a system's existing interface, the API. The difference lies in who uses the integration. An ordinary integration follows fixed rules a developer wrote: if this happens, do that. With MCP, a language model chooses which tool to use and with what input. That is more flexible, but you know less precisely in advance what will happen.

MCP is also something other than an llms.txt. That is a text file on a website that tells AI assistants what is on the site. It lets an assistant read your site, but not do anything. With MCP, an assistant can act in a system. How AI assistants find and read your site is covered in our article on AI visibility.

What does the specification say about security?

The specification is clear: MCP enables access to data and the execution of code, and whoever builds with it has to handle that carefully. It names three principles:

• Consent and control. Users must explicitly consent to, and understand, all data access and operations. They keep control over what is shared and what actions are taken.
• Privacy. The application must get explicit consent before it exposes user data to a server, and must not send data elsewhere without consent.
• Tool safety. Tools represent arbitrary code execution and call for caution. Descriptions of what a tool does count as untrusted unless they come from a trusted server. The application must get consent before it invokes a tool.

The sentence that follows matters most: MCP itself cannot enforce these principles at the protocol level. It depends on how the application and the server are built. The specification also says there should always be a human in the loop who can refuse a tool call, with clear confirmation prompts. A server must validate all input, control access, limit the number of calls and clean up its output. An application should ask for confirmation on sensitive operations, show the input before it calls a tool, and keep a log of tool use.

What are the risks, and what do you do about them?

Access that is too broad. MCP's security guidance describes the case where someone steals a key with broad rights, such as all files or the whole database. Its advice: start with a minimal set of rights for reading and discovery only, and only ask for more when an operation needs it. Do not use wildcards such as everything or full access.

Instructions hidden in data. A model that reads emails, documents or web pages can come across text posing as an instruction. OWASP calls this indirect prompt injection in its list of risks for language models, and writes that it is unclear whether it can be fully prevented. OWASP advises, among other things, minimal rights, human approval for risky actions, and keeping external content separate and clearly marked.

An untrustworthy server. A local MCP server is a program running on your own computer, with the same rights as the application. The specification requires an application that installs such a server in one click to first show the full command that will run, and to ask for explicit consent. It recommends isolating such servers with as few rights as possible.

Signing in. Authorization is optional in MCP. If a server uses an HTTP route, it should follow the authorization rules, based on OAuth 2.1. A server may then only accept keys issued for it, and must not pass them on to another system. With a local server over stdio, the credentials come from the computer's environment.

How do you start sensibly?

1. Choose one task with clear value, such as enriching enquiries with data from your customer records or summarising documents from one folder.
2. Write down which actions the task needs, and which it does not. Anything not on that list, the integration does not get.
3. Start read-only where you can. Writing, sending and deleting come later, and only with confirmation.
4. Give the integration its own account with its own rights, not an administrator's login.
5. Choose the server with care. Preferably one from the system's own supplier, or one you have built and can inspect.
6. Test with dummy data before you connect real customer data.
7. Keep a log and check every result for the first few weeks. That builds trust, and gives you the examples to improve the integration.
8. Only then take the next task. That way you grow a whole you understand, instead of a sprawl nobody can oversee.

That is how our AI integrations start: small, on one process, on top of what is already running, and with a person who signs off. More on AI that takes steps on its own is in our article on AI agents.

Where does your data go?

MCP governs how an AI application talks to a server, not where your data is processed. Whatever a tool returns goes to the language model you use, and that model runs at the provider you choose. Where your data goes therefore depends on three choices: which AI application, which model and which server. Record them for each integration. If you work with personal data, also check what agreements you have with each party.

When this does not apply

If two systems always need to do the same thing with each other, such as passing a new order to your accounts, an ordinary integration or automation is often simpler and more predictable than a language model that makes its own choices. MCP makes sense where the question differs each time and an assistant has to choose which information or action fits. More on that trade-off is under AI automation.

If you have data you may not or do not want to share with an AI provider, MCP does not help: it governs the connection, not the processing. Then the first question is which model you may use, not how to connect it.

What we do not know: the specification is still changing. The version of 28 July 2026 removed, among other things, sessions and the opening exchange from the protocol. What is written here holds for that version. Nor have we measured how much time an MCP integration saves a business, so we give no figure.

Which connection would give you time? Name the system your team works in most, and we will sketch a safe first step. Integrations, code and login details are put in your name; more under AI integrations. You work directly with Nawid; for each project he puts together a fixed team of specialists.