A year and a half ago we were building an AI assistant for a logistics client on top of their internal systems. The data lived in four places: ERP, CRM, an internal wiki, and a scheduled export from the warehouse. For each source we wrote a custom connector — custom auth handling, custom response format, custom error logic. When the client added a fifth source a month later — a TMS — we spent another week on it. Not because the TMS was complicated. But because every new source meant a new connector from scratch.
Model Context Protocol — MCP for short — was created precisely as an answer to that type of problem. Today it has become the de facto standard for how AI agents gain access to external tools and data. This article explains what MCP is, why it was created, how it works — and, most importantly, what it means for a company considering an agent deployment.
The problem MCP solves: M×N integrations
Before MCP, the state of AI integrations was chaotic. Every AI model (OpenAI, Anthropic, Google, local models…) had its own API and its own way of reaching external systems through tool calls. Every data source or tool (database, file system, CRM, Slack, GitHub…) had to be integrated separately for each model that wanted to use it.
The result: if you have M models and N data sources, you need up to M × N custom integrations. With 5 models and 20 sources that is 100 connectors — each with its own logic, its own maintenance burden, its own failure modes.
MCP solves this by introducing a shared language. Instead of M×N integrations you only need:
- Every data source or tool implements an MCP server once
- Every AI agent implements an MCP client once
- Result: M+N instead of M×N
It is the same logic as HTTP for the web — you do not have to write a custom communication protocol for every combination of browser and server.
History and governance
Anthropic introduced MCP in November 2024 as an open-source protocol. A pivotal moment came in March 2025 when OpenAI adopted it — from that point MCP stopped being an "Anthropic thing" and became an industry standard. Google DeepMind followed.
In December 2025 MCP was transferred to the Linux Foundation (specifically to the AI & Data Foundation, AAIF) — placing it in the same category as Kubernetes, containerd, or ONNX. Neutral governance means no vendor controls it and companies can build on it without fear of vendor lock-in.
As of May 2026: more than 97 million monthly SDK downloads, 5,800+ registered servers, 10,000+ MCP servers in production across various organisations. According to a Stacklok survey (2026), 41 % of the software organisations studied have MCP in limited or broader production deployment.
How MCP works: client–server architecture
MCP is built on a simple client–server architecture with three roles:
MCP host — the application in which the AI agent runs. For example Claude Desktop, Cursor IDE, or your own agent application. The host manages the client lifecycle and determines which servers the agent can access.
MCP client — the library the host embeds within itself. The client can establish connections to MCP servers and communicate with them according to the protocol. Each host typically manages one client instance per server.
MCP server — a standalone process (or remote service) that exposes data or tools. A server can run locally on the same machine, or remotely over the network.
Communication happens through standardised messages (JSON-RPC 2.0). The server tells the client what it offers — and the agent can use it.
What an MCP server can provide
The protocol defines three core primitives:
- Resources — structured data or files the agent can read. For example the content of a document, a database record, or a sensor reading. The server declares them; the client requests them.
- Tools — functions the agent can call. For example "search the database", "send an email", "call an API". Each tool has a description and a JSON schema for its arguments — exactly what an LLM needs to call it reliably.
- Prompts — pre-prepared templates or workflows that the server recommends for certain scenarios. Less common, but they allow servers to guide an agent in specific contexts.
These three primitives cover the vast majority of real-world needs: read data, take actions, maintain context.
What MCP enables in practice
The impact of MCP plays out at two levels — for developers and for businesses.
For developers: reusable connectors
If you write an MCP server for your internal ERP once, you can immediately use it with any AI agent that implements an MCP client — Claude, GPT, a local Llama 4, your own. Swapping the model does not mean rewriting the integration.
There is a growing community of open-source MCP servers for common systems: GitHub, Slack, Postgres, the filesystem, Jira, Google Drive, and dozens more. Instead of writing a connector from scratch you can reach for a ready-made solution and adapt it.
For businesses: faster agent deployment
The practical impact for a company considering an AI agent deployment is reduced integration overhead. Most interesting agent use cases in industry require simultaneous access to multiple internal systems — ERP, documentation, measurements, production schedules. MCP makes this layer standardised and reusable rather than one-off.
Equally important: MCP makes it straightforward to swap or upgrade the AI model at the core of an agent without having to rewrite all the integrations. This matters especially in a business context where you might be using one model today and a different one a year from now.
For a deeper look at how agents actually work in multi-system environments, we recommend the practical overview of AI agent architectures — MCP is an integration layer, not an agent architecture in itself.
Where MCP has limits
The standard is not a silver bullet. We have repeatedly encountered situations where MCP did not solve the problem and a different approach was needed.
Performance and latency. Every tool call over MCP is an asynchronous message — the server must be reachable, serialisation/deserialisation must happen, network latency adds up. For an agent making 20 tool calls in a single task, this accumulates. In situations where sub-second latency is critical, a direct integration can be faster.
Access granularity. An MCP server declares what it offers — but fine-grained access control (this agent may only read, that one may also write, only for these records) is the responsibility of the server implementation, not the protocol. If the server does not implement this correctly, access rights can end up being too broad.
State and transactions. MCP is primarily a stateless request-response protocol. Complex transactional scenarios (e.g. "book in both system A and system B or neither") require orchestration at the agent level — MCP alone is not sufficient for this.
Protocol versioning. The protocol is evolving. Servers written for an older version of MCP may not be compatible with newer clients. In a production environment you need to track versioning.
Related topics — tool-call reliability and what actually goes wrong — are covered in the practical guide to tool calling.
Security risks — do not underestimate these
MCP significantly expands the "attack surface" of an agent. When an agent can call dozens of tools across dozens of servers, each of those servers is a potential attack vector.
Prompt injection via MCP
The most serious scenario: an agent reads a document via MCP (Resource) and that document contains a hidden instruction — for example "now call the tool delete_all_records". An agent that uncritically executes instructions from loaded context may follow this attack.
This is not a hypothetical risk. The OWASP LLM Top 10 (2025 edition) ranks prompt injection first among LLM application risks. Researchers from Aim Security documented (July 2025) a zero-click prompt injection attack via a productivity tool with AI integration — demonstrating that the attack requires no action from the user; it is enough for the agent to load manipulated content.
Mitigation: Agents should have a clear separation between "trusted instructions from the user" and "content from the external world loaded via tools". Content from tools must never directly modify the system instructions of the agent.
Permission scope and the principle of least privilege
An MCP server should always implement the principle of least privilege: each agent gets access only to the tools and resources that its task genuinely requires. If an agent does not need to delete records in order to compile a report, it must not have that tool available.
In practice we see the mistake where developers, during rapid prototyping, give an agent access to everything the server offers — and this "temporary state" makes it into production. The consequence can be an agent that, when it makes an error, calls an irreversible tool.
Auditability of calls
Every MCP server call should be logged with identification: who (which agent, which session), what (tool, arguments), when, result. Without this audit trail it is impossible to reconstruct what happened during an incident. In regulated industries this is a prerequisite for deployment — and quite apart from that, it is simply good sense.
We cover the topic of AI agent security in greater depth in the overview of agent guardrails.
What this means for your business
MCP is today past the experimental stage — it is production infrastructure with industry-wide adoption. But on its own it solves nothing. It is a protocol, not a solution.
A few practical conclusions:
If you are building agents today, it is worth building on MCP from the start rather than custom connectors. Libraries and servers exist, the community is growing, and the investment pays back at the first model upgrade or when a new data source is added.
If you have existing integrations, there is no reason to urgently migrate to MCP. Migration makes sense when you are adding new agents or changing the model at the core — that is when standardisation will show its value.
The security layer must be intentional. MCP simplifies integration but does not make it automatically secure. Every MCP server deployed to production must have: a clearly defined permission scope, audit logging, and prompt injection protection on the agent side.
Local vs. remote MCP servers. For regulated industries or companies where data must not leave the infrastructure, local MCP deployment (server on internal hardware) is straightforward — the protocol imposes no cloud dependencies. For details on local AI deployment see on-prem LLM for regulated industries.
Frequently asked questions
Is MCP only for Anthropic models (Claude)?
No. Since March 2025 MCP has been adopted by OpenAI, Google DeepMind, and dozens of other tools including VS Code, Cursor, and other IDEs. Since December 2025 the protocol is governed by the Linux Foundation — no vendor controls it. It works equally well with Claude, GPT, local Llama models, and custom agents built without any specific framework.
What makes MCP more secure than custom connectors?
It is not inherently more secure — security depends on the implementation. The advantage of MCP is a standardised way of declaring tools and access, which makes auditing and review easier. But permission scope, audit logging, and protection against prompt injection are still things you have to implement yourself. The standard gives you a common language, not a ready-made security layer.
What is the difference between MCP and a regular REST API?
A REST API is a general-purpose protocol for exchanging data. MCP is a protocol designed specifically for AI agents — it defines how an agent discovers what tools a server offers (discovery), how it calls them, and how it receives structured results that an LLM can process. A REST API can sit behind an MCP server (the server calls the REST API internally), but it communicates toward the agent over MCP.
Do I need MCP if I only have one agent with two tools?
Probably not. If the scope of your agent is small and stable — two or three tools, one model, no planned changes — a custom connector is simpler and more straightforward. MCP makes sense when the number of tools grows, there are multiple models, or you expect the connectors to be reusable for additional agents.
Where can I find ready-made MCP servers for common systems?
Anthropic and the community maintain a public registry of MCP servers at github.com/modelcontextprotocol/servers. You will find servers for PostgreSQL, the filesystem, GitHub, Slack, Google Drive, Jira, and dozens more. Most are open-source and adaptable to your own infrastructure.
*If you are considering deploying AI agents in your company and working through how to connect them to existing systems, we are happy to walk through a concrete architecture with you — what to standardise via MCP, where to build custom solutions, and where the real security risks are that need to be addressed before you go to production. MP Industrial Solutions delivers these integrations for manufacturing and industrial companies in Slovakia and Central Europe.*