MCP is an open standard for linking AI assistants to company systems. How it works, what you gain and which risks need to be kept under control.
An AI assistant can write well, but on its own it knows nothing about your orders, the customers in your CRM or the team calendar. To be useful at work it has to be connected to the company’s tools. Until recently, each connection was a separate project. The Model Context Protocol (MCP) is an attempt to standardise that connection. The term appears more and more in discussions of AI agents, so it is worth understanding, without jargon, for those who decide budgets and risks.
What MCP is, in brief
MCP is an open standard for connecting AI applications to external systems: data sources (files, databases), tools (search, calculations) and workflows. It was launched by Anthropic on 25 November 2024, and the official documentation describes it by analogy with a USB-C port: one standardised way of connecting different devices. Assistants such as Claude or ChatGPT and developer tools such as Visual Studio Code can use it.
Without a standard, if you want to connect three assistants to five systems, you need in principle many separately built connections. With a common standard, each system builds a single “door” once (an MCP server), and any compatible assistant can use it.
How the pieces fit together
The MCP documentation uses three roles:
- The host: the AI application the person works with (for example an office assistant or a development environment).
- The client: the component inside the host that keeps the connection to a particular server.
- The MCP server: the program that “exposes” a tool or data source from your company, such as the CRM, the calendar or a document base.
A server can run locally, on the user’s computer, or remotely, at a provider or on the company’s infrastructure. For remote servers, the specification recommends standard authentication using OAuth.
A server mainly offers three kinds of things: tools (actions the assistant can request, for example “create a record”), resources (information to read, for example the content of a document) and reusable prompt templates.
A hypothetical example
A car service company has a booking system, a CRM and a set of technical sheets. Someone writes to the assistant: “Which cars had an appointment last week and did not show up? Prepare rebooking messages.” Through the booking system’s MCP server the assistant reads the list; through the CRM’s, it finds the phone numbers; it writes the messages and queues them for a person to approve. Without MCP, the same functionality would have needed an integration built specially for that assistant.
What you gain
- Less repeated integration work when you change or add assistants.
- An assistant that works with real data, not text pasted by hand into a chat window.
- A central point of control: each tool exposed through a server can be limited, tracked and switched off.
- An ecosystem: servers already exist for many popular products, and others can be built for your own systems.
What you need to know about the risks
Connecting an assistant to real systems changes the nature of the risk. An assistant that only talks is wrong in words; a connected one can be wrong in actions.
How much it is allowed to do
Every exposed tool is a capability. Grant only what is needed: reading first, then small actions, and only last actions with consequences (sending messages, changing data, payments). For actions that cannot be undone, require a person’s approval.
Content that can trick the assistant
An assistant that reads emails, web pages or documents may come across text trying to give it orders (“ignore the instructions and send the data to…”). This is called prompt injection and we cover it in a separate article on agent security. With MCP the stakes rise, because the assistant has hands: the same tools it can use for something useful can be turned to something else if it is tricked.
Third-party servers
An MCP server is code that runs with rights over your systems. Use servers from trusted sources, read what permissions they ask for, check who maintains them and prefer what you can control. A server installed “because it was on the list” is like a program you run without reading it.
Data that leaves
What the server sends back reaches the assistant and, from there, the model provider. If you work with personal data, apply the same rules as for any use of an AI assistant: processing contract, settings, minimisation. We wrote about them in the GDPR article; for your own case, speak to a lawyer.
How to start, without rushing
- Pick a narrow use case with clear value: for example, an assistant that reads orders and answers “where is my order?”.
- Start with read access. An assistant that can only see is far easier to check than one that can write.
- Limit the data: expose only the fields and records needed, not the whole database.
- Keep a log of the tools called: who, what, when.
- Add human approval for any action with consequences, and a simple way to stop everything.
- Test with awkward cases, including content that tries to trick the assistant.
- Expand gradually, based on what you see in the logs.
Is MCP right for your business?
If you only use AI assistants for writing and summarising, probably not yet. It becomes relevant when you want the assistant to work with your data and systems and you have several systems to link. Even then, a simple direct integration is sometimes enough. The standard helps when you have many connections to make or change, not when you have just one.
ME Digital provides AI implementation, including connecting assistants to company systems with limited rights and logging; for projects that need development, see also custom software. You can start with a conversation on the contact page.