What is MCP (Model Context Protocol)? A guide for businesses
MCP (Model Context Protocol) is an open protocol that gives AI models a standard way to connect to outside tools and data sources. Once you expose a system as an MCP server, every AI application that supports MCP can talk to it in the same language. Put simply, MCP is a common socket for AI — one standard instead of a different cable for every device.
In this article we explain why MCP came about, how it works, where companies use it and what we watch for on the security side.
Why did MCP come about?
On its own, a language model only produces text. It cannot see your customer records, your stock levels or your support tickets. Until recently, giving it that access meant writing every connection separately: one CRM connection for one model, a second connection to the same CRM for another application, a third for the next.
If you have five AI applications and ten internal systems, that is fifty separate integrations. Each one has to be maintained, secured and updated on its own.
MCP turns that multiplication into addition. Each internal system is written once as an MCP server. Each AI application becomes an MCP client once. The rest is standard.
The protocol was published by Anthropic as an open standard at the end of 2024, and within a short time it was supported by a wide range of AI applications, code editors and developer tools.
How does MCP work? Three roles
There are three parties in MCP:
- The host. The AI application the user actually works in — a desktop assistant, a code editor, or your company’s own assistant.
- The client. The part inside the host that manages the connection to each server.
- The server. A small piece of software that opens one system — a database, a file store, an internal API — to the AI.
A server can offer the model three kinds of thing:
| What it offers | What it is for | Example |
|---|---|---|
| Tools | Actions the model can call | ”Check order status”, “Open a ticket” |
| Resources | Data the model can read | A document, a record, a schema |
| Prompts | Ready-made, reusable task templates | ”Prepare the weekly sales summary” |
The connection can be made in two ways: as a local process running on the same computer, or as a remote server reached over HTTP. A local connection suits tools on a developer’s own machine; a remote connection suits systems shared across a team or a whole company.
A concrete example: a support team assistant
Picture the support team at a software company. During the day they look at three systems: customer records, the ticketing system and the product documentation.
The company writes one MCP server for each:
- Customer server — offers a tool to read the customer’s plan and past tickets. It has no write access.
- Ticket server — offers tools to read tickets, add notes and open new tickets.
- Documentation server — offers the product manuals as resources.
A support specialist writes to the assistant: “Look at this customer’s last three tickets — is there a common problem? If so, find the fix in the manual and add it to the ticket as a note.”
The assistant uses the three servers in turn. It reads the tickets, finds the relevant section of the manual and drafts a note. Before adding the note, it asks the specialist for approval. The specialist approves; the note is added.
The value of this flow is simple — if the company moves to a different AI application tomorrow, those three servers keep working exactly as they are.
Where are companies using MCP?
- Opening internal tools to assistants. Reporting, record look-ups and ticket management done through AI.
- In developer teams. Letting the AI assistant in a code editor reach the bug tracker, the database schema or internal documentation.
- In assistants that work with company documents. Exposing a document store as an MCP server gives a RAG-based assistant a standard door to its data source.
- In agent systems. Defining the tools an AI agent uses through MCP servers, rather than coding each one by hand.
What MCP does not give you
MCP is a connection standard. There are a few things it does not solve by itself:
- Good tool design. A poorly defined tool, whose purpose is unclear, works just as poorly over MCP. The tool’s name, description and parameters decide whether the model uses it correctly.
- An access policy. You decide who may reach which data. MCP offers a way to enforce that decision; it does not make the decision for you.
- The model’s mistakes. A model can pick the wrong tool or send the wrong parameters. That is why approval steps and limits are still needed.
Security: what we pay attention to
An MCP server is a door into your company that you open for AI. When we build that door, we follow these rules:
- Least privilege. The server exposes only the operations that are needed. If reading is enough, no write tools are added.
- Acting with the user’s permissions. The assistant should never go beyond the data that the person using it can already reach. On remote servers, authentication is set up for this from the start.
- Human approval for risky tools. Steps that are hard to undo — deleting, paying, sending something outside the company — never run without approval.
- Care with untrusted content. An email or a web page can plant hidden instructions in the text the model reads. So we draw deliberate boundaries between content from outside sources and tools with real permissions.
- Logging. Which tool was called, on whose behalf, with which parameters — all of it is recorded.
- Where servers come from. If ready-made, third-party MCP servers are to be used, we review their code and the permissions they ask for. Company data is never opened to an unknown server.
Where should you start?
Our advice is to start with one system and read-only access. For example, a server that can only read ticket records. The team uses it for a few weeks, and we see which questions get asked and where the assistant struggles. Write tools and a second system come after that.
During this first period we measure a few things: how often the assistant picks the right tool, which questions it tries to answer without using a tool at all, and which tool description misleads the model. These observations feed straight into better tool names and descriptions. More often than not, describing existing tools more clearly makes a bigger difference than adding new ones.
This approach keeps the risk small and shows early on which integration is genuinely worth having.
Frequently asked questions
Does MCP only work with one particular AI model?
No. MCP is an open protocol and is not tied to any single model. Any application that supports MCP can use the same server. That also makes it easier to move from one model to another.
What is the difference between MCP and an API?
An API is the door a system opens to the outside world. MCP standardises how those doors are introduced to AI models. Most MCP servers use an existing API behind the scenes and turn it into tools the model can understand.
Does our data leave the company through MCP?
MCP itself does not send data anywhere; it makes data available to the model. The real question is where the model runs and where the data goes. We settle that in writing at the start of the project.
Ready-made MCP servers or a custom server?
Ready-made servers exist for common tools and give you a quick start. Where systems are specific to your company, permission rules are particular or the data is sensitive, writing a custom server is usually the safer choice. We decide together once we have looked at the system and the access it needs.
Do we need to change our existing systems?
Usually not. An MCP server is a thin layer placed in front of an existing system. The system itself stays untouched; only the operations you choose are opened to AI.
If you would like to talk about connecting your internal systems to AI safely, have a look at our AI systems architecture page or write to us. We reply within two business days.