What is MCP: how it works, advantages, limitations and best practices

"We'll just hook it up over MCP." It's the phrase of the year. You hear it from someone building their first agent on a Sunday afternoon and from the AI committee of a large company. And it's partly right: MCP (Model Context Protocol) is the open standard that lets an AI assistant —Claude, ChatGPT, Gemini, Copilot— connect to tools and data without a custom integration for every system. But plenty of people use it without knowing what it is or what they're connecting. And the phrase hides a trap: MCP solves how an agent reaches your data. It doesn't decide which data it should be allowed to see. This article explains what MCP is, how it works under the hood, its advantages and limitations and, above all, the best practices you need to use it without losing control.

Before we start: six words you're going to read

If you've come to technology through AI, some of these words are taken for granted. They shouldn't be. One sentence each:

• AI agent: a language model that doesn't just answer but acts: it decides on steps, uses tools and queries data to reach a goal.
• Tool: a specific action the agent can carry out, such as "find customer" or "create ticket".
• API: the door through which one program talks to another. Almost every system in a company has one.
• Token: here, a credential, a kind of digital key that proves who you are to a system. Careful: in AI, "token" is also the unit used to measure the text a model processes. Two different things with the same name.
• OAuth: the standard that lets an application act on your behalf without knowing your password. It's what happens when you click "Continue with Google".
• Data lineage: the trail of each piece of data: which system it came from, when it was recorded and what transformations it went through along the way. It's what lets you check where each claim made by an AI comes from.

What MCP is, without the jargon

MCP is a protocol: an agreement on how two programs talk to each other. In this case, an AI application and a system that offers it capabilities —finding a customer, reading a contract, querying a database.

The comparison everyone makes is USB-C, and it's a good one. Before MCP, connecting an assistant to the CRM, the ERP and the document store meant three custom integrations. And for the next assistant, another three. With MCP, each system is exposed once and any compatible application can use it. One connector for everything.

Anthropic released it as open source on 25 November 2024. A year later, on 9 December 2025, it donated it to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. Today it isn't one company's protocol. It's the industry standard.

How it works under the hood: host, client and server

MCP has three pieces. There aren't many, and understanding them is what lets you reason about everything else.

• Host: the AI application you work with. For example, Claude Desktop, ChatGPT, Cursor, your own agent.
• MCP client: the connector, inside the host, that keeps the connection to a server. One per connected server.
• MCP server: the program that offers the capabilities of a specific system. For example, one for the CRM, another for files, another for the database.

An MCP server can offer three things: tools, which the model runs; resources, which are data and context that can be read, such as a document; and prompts, predefined message templates. Underneath, everything travels as messages in a standard format (JSON-RPC 2.0), along one of two routes: directly inside your computer if the server is local, or over the internet (HTTP) if it's remote.

Let's see it with an example. You ask your assistant: "Which invoices does our customer López have outstanding?"

1. On start-up, the MCP client asked each connected server what it can do. The model has the list of tools in front of it, with a description of each.
2. The model reads your question and decides, on its own, that the right tool is "find invoices" on the ERP server.
3. The client sends the request to the ERP server.
4. The server calls the ERP's API with its credential and gets the invoices.
5. The result goes back to the model, which reads it and writes the answer.

Look at step 2. The model is the one deciding which tool to use and with which data. Not a programmer. Hold on to that idea, because everything else follows from it.

What an MCP server is

An MCP server is the piece that turns a system —a database, a SaaS product, a document repository— into something an assistant can use without a custom integration. Many wrap an API that already existed: they receive the model's request, call the system's API and return the result.

There are two kinds, and the difference matters more than it seems:

• Local: installed and run on your computer. They work with your permissions: they can read your files and use whatever you can use.
• Remote: published by the system's own provider; you connect to them over the internet, usually authorising them with OAuth.

According to Anthropic, by the end of 2025 there were already more than 10,000 active public MCP servers. That abundance is MCP's great strength. And, at the same time, its great problem: installing a server is so easy that within a few months nobody knows how many are connected, who wrote them or what data they reach.

MCP or API: the difference hardly anyone explains

MCP doesn't replace APIs. It builds on them. The difference is who each one is designed for.

• Designed for. API: a programmer writing code against it. MCP: an AI model deciding what to use in real time.
• How it's discovered. API: by reading its documentation. MCP: the client asks the server what it can do.
• Format. API: specific to each system. MCP: the same for every server.
• Integration. API: one per application–system pair. MCP: one server per system, valid for any client.
• Who decides the call. API: the code, deterministically. MCP: the model, from a text description.

The last row is the one that changes the game. With an API, a programmer decides exactly what gets called and when, and it will happen the same way a thousand times. With MCP, a language model decides by reading a description. That gives enormous flexibility. And it also opens the door to everything that follows.

Advantages and limitations of MCP

MCP is a big step forward. But it isn't magic, and it's worth knowing both sides before connecting it to anything important.

Advantages

• Open standard, governed by a foundation and adopted by the major assistants
• One integration works for all compatible assistants
• Automatic discovery: the assistant knows what it can do without any coding
• Huge ecosystem: thousands of ready-to-use servers
• Local or remote, as you need

Limitations

• The model decides which tool to use: flexible, but not deterministic; it can pick the wrong tool
• Every tool takes up context: with many servers the agent burns tokens and chooses worse (we covered it here)
• Security depends on each server: the protocol defines how to authorise, not what can be seen
• Very uneven quality: anyone can publish a server, well built or not
• No logging by default: if the server doesn't do it, nobody knows afterwards what data was queried

The takeaway from this table is simple: MCP gives you the connection. The control is up to you.

What MCP doesn't decide

Back to our customer López, whom you'll know if you read I'm an agent. The sales team wants an agent to prepare tomorrow's meeting. Someone connects the CRM, the ERP and the contracts folder over MCP. Ten minutes later, it works.

Now look at what happened underneath. The agent can read everything each server's credential allows it to read: López, yes, but also every other customer, the margins, perhaps the terms of other contracts. Nobody decided that the agent preparing a sales meeting should see all that. Nobody decided otherwise either.

MCP's risk isn't in the protocol. It's in what gets connected and how permissions are granted. OWASP, the global reference in application security, already maintains a Top 10 of MCP-specific risks. These are the ones that weigh most when the agent reaches business data:

• Mismanaged tokens and secrets: fixed or long-lived credentials that end up in logs, in the model's context or in an attacker's hands.
• Permissions that grow on their own: access granted "for now" that nobody removes, giving the agent more reach than its task needs.
• Tool poisoning: a tool, or its description, tampered with to inject instructions or false data into the agent's context.
• Prompt injection through content: a document, email or web page with hidden instructions that the agent reads and obeys.
• Insufficient authentication and authorisation: servers that don't check who is calling or what they may do.
• Lack of auditing: nobody can reconstruct afterwards what data the agent queried, for whom and why.
• Shadow servers: servers installed on someone's own initiative, outside the company's inventory.
• Context over-sharing: the agent receives far more data than it needs to answer.

Notice what they have in common: none of them is solved by asking the model to behave. An instruction in the prompt is a suggestion the model can ignore and an attacker can override. We go into it in depth in Guardrails and data security: whatever watches what the agent says does not govern what it accesses.

Best practices for using MCP

This is the part hardly anyone talks about. We split it in two: what's worth doing if you use MCP day to day, and what's needed when a company deploys it.

If you use MCP day to day (Claude, ChatGPT, Cursor…)

1. Only install servers from trusted sources. The system provider's official ones, or repositories with visible maintenance. Remember that a local server runs on your computer, with your permissions.
2. Check which tools it brings and switch off the ones you don't use. Fewer tools means a faster, cheaper agent that chooses better and has a smaller attack surface.
3. Give it the least permission possible. If you only need to read, use a read-only credential. If you can, a separate account for the agent.
4. Don't paste passwords or tokens into the chat, or into configuration files you share or push to a repository.
5. Don't switch off confirmations. Most assistants ask your permission before an action that writes, sends or deletes. That pause is your last control: read it before accepting.
6. Be wary of the content the agent reads. A web page, a PDF or an email can carry hidden instructions. If the agent proposes something you didn't ask for, stop.
7. Clean up. Keep servers updated and remove the ones you no longer use.

If a company deploys it

1. A single governed access point to the data. Instead of one MCP server per system, each with its own permissions, the agent asks a single layer that knows all the data and applies the same policy. It's the idea of centralising, relating and describing the data before the agent asks.
2. The real identity of whoever is asking. The MCP specification bases authorisation on OAuth 2.1 and explicitly forbids token passthrough: a server must not forward to another system the credential it received. Every access has to know which agent is asking and on whose behalf.
3. Least privilege per task, not per agent. The agent preparing the meeting with López doesn't need to see payroll, even if it has technical access to the system where it lives. Permission is decided for each query.
4. Authorisation in the infrastructure, not in the prompt. Whether a piece of data is accessible is decided by a deterministic system, beneath the model. With the same identity, task and data, the answer is always the same.
5. An immutable record of every access. Who asked, what data was returned, under which policy and when. Without that record there's no way to respond to an incident or comply with rules such as the GDPR, DORA or the EU AI Act.
6. Answers with their lineage. Every piece of data that reaches the agent should carry where it came from. Otherwise the agent ends up inferring on top of inferences and nobody can check its answers.
7. An inventory of servers. Which MCP servers are connected, who approved them and which systems they reach. If it isn't in the inventory, it doesn't get connected.

How Opendome solves it

Opendome has its own MCP server, built precisely on these rules. It works like this:

• It connects identities, not just agents. Users, agents or systems ask through the same MCP, each with its own identity. You always know who is asking.
• It filters every access with policies. Before touching the data, each query is compiled with the policy that applies to it: rows, columns and content are filtered within the query itself. It's what we call the Cell Model: access is authorised by identity, task, entity and exact field, and it's enforced by the infrastructure, not the prompt.
• It records every access immutably. Who asked, what was returned and under which policy, in a record that can't be altered afterwards.
• It returns the result with the dataset used and its lineage. The agent doesn't just get an answer: it gets which data was used to build it, which system each piece came from, when it was recorded and what transformations it went through. Any claim the agent makes can be traced back to the data that supports it.

The agent keeps all the flexibility of MCP. What no longer depends on it are the permissions, the record and the traceability. You can see how it all fits together in Technology and in our security centre.

The conclusion

In two years MCP has solved a problem the industry had always carried: connecting AI to systems without a custom integration for every combination. It's worth understanding, because it's going to be everywhere.

What it doesn't solve —nor does it try to— is who can see what. That decision is still yours. And it isn't made in the prompt.

Connecting an agent over MCP is easy. Connecting it properly means deciding permissions outside the model, recording every access and knowing where each piece of data comes from. Whoever does it this way from the start will be able to multiply their agents without multiplying the risk.

If you're connecting agents to your company's data and want to get it right from the start, let's talk.

Opendome gives any agent, from any provider, a single MCP access point to the company's data: centralised, related and described, with every access filtered by policy, recorded immutably and returned with its lineage. The flexibility of MCP, without giving up control.

Sources

• Model Context Protocol, official specification (architecture, tools, resources and prompts; JSON-RPC 2.0) — https://modelcontextprotocol.io/specification/latest
• MCP, transports (stdio and Streamable HTTP) — https://modelcontextprotocol.io/specification/latest/basic/transports
• MCP, authorisation (OAuth 2.1; token passthrough forbidden) — https://modelcontextprotocol.io/specification/latest/basic/authorization
• MCP, security best practices (confused deputy, token passthrough, session hijacking) — https://modelcontextprotocol.io/specification/latest/basic/security_best_practices
• Anthropic, Introducing the Model Context Protocol (25/11/2024) — https://www.anthropic.com/news/model-context-protocol
• Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation (09/12/2025; more than 10,000 active public servers) — https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
• OWASP MCP Top 10 — https://owasp.org/www-project-mcp-top-10/