> Bron: https://neuralex.nl/en/blog/wat-is-mcp
> MCP is the open protocol that lets AI agents connect to tools, data and systems in a standardized way. What it is, how it relates to APIs, function calling and RAG, and what it means for security and on-premises AI.

[Back to Insights](/en/blog)

Agents ·19 August 2026 ·8 min read

# What is MCP (Model Context Protocol) and why is it changing agents?

MCP is the open protocol that lets AI agents connect to tools, data and systems in a standardized way. What it is, how it relates to APIs, function calling and RAG, and what it means for security and on-premises AI.

MCP, or **Model Context Protocol**, is an open protocol that gives AI applications a standardized way to connect to external data sources, software and tools. Instead of building a bespoke integration for every database, CRM, document repository or business application, those capabilities can be exposed through an MCP server. An AI agent can then discover what is available and use those capabilities when required.

At first glance, this may sound like an incremental developer improvement. For [AI agents](/en/blog/ai-agents-voor-het-mkb), its implications are much larger. A language model becomes genuinely agentic when it can do more than generate text: it needs to retrieve information, make decisions and take actions. MCP standardizes the layer between the AI system and the outside world. This makes tools less tightly coupled to a particular model, application or AI vendor.

## From chatbot to agent

A traditional language model primarily operates on what it learned during training plus whatever context is provided with the current request. That is enough to generate excellent text, answer questions and reason about problems, but the model does not automatically know:

-   which invoices are currently overdue;
-   what the CRM says about a customer;
-   which documents are stored on an internal file server;
-   whether a product is still in stock;
-   which support tickets are waiting;
-   whether it is allowed to execute an action in a business application.

For those tasks, an AI system needs access to external systems. That was possible before MCP: developers could integrate APIs, use function calling or write custom code connecting a model to databases, search systems and applications. The problem is not that integrations were impossible — the problem is that integrations repeatedly had to be designed and maintained for different AI environments. MCP introduces a common interface for this layer.

## How does MCP work?

MCP uses an architecture involving an **MCP host**, **MCP clients** and one or more **MCP servers**. The host is the AI application in which the user operates. An MCP client communicates with an MCP server, while the server exposes specific information or functionality. The protocol uses standardized messages and is built around JSON-RPC.

An MCP server can expose several important types of capability:

-   **Tools** are actions a model can invoke. Examples include querying a database, creating a ticket, retrieving an order status or performing a calculation. Each tool has a name and structured metadata describing its inputs.
-   **Resources** allow servers to expose data or content that an AI application can read, such as documents, records or other information sources.
-   **Prompts** are reusable prompt templates that servers can expose to clients.

The protocol continues to evolve. The current specification dated July 28, 2026 further develops areas including core protocol behavior, caching, authorization and extensions.

## A practical example

Consider an SME building an internal customer-service agent. The agent needs to:

-   search product documentation;
-   retrieve customer information from the CRM;
-   check outstanding orders;
-   create support tickets;
-   request human approval before certain actions are executed.

Without a common protocol, each capability can require its own integration layer. The AI framework needs to know how the CRM API works, how to query the document store and which parameters the ticketing system requires.

With MCP, these capabilities can instead be exposed as MCP tools and resources. Conceptually, the agent might see tools such as `search_documentation`, `get_customer`, `check_order` and `create_support_ticket`. The agent does not need to understand the CRM's internal architecture. It needs to understand which tool is available, what that tool does and which arguments it requires. That distinction matters: the integration layer becomes separated from the intelligence layer.

## Why is MCP changing AI agents?

The main reason is modularity. An agent can roughly be divided into three layers: a model that reasons, an orchestration or agent layer that manages the workflow, and integrations that allow the agent to interact with external systems. That final layer has historically involved a great deal of custom engineering.

MCP makes it possible to expose capabilities more independently. A properly designed MCP server can in principle be consumed by different MCP-compatible clients. An organisation therefore does not necessarily need to redesign all of its business integrations simply because it changes model or agent platform.

This matters even more because MCP is no longer confined to the ecosystem of its original creator. Anthropic introduced MCP in November 2024 and donated the protocol to the Agentic AI Foundation under the Linux Foundation in late 2025. OpenAI also supports MCP across parts of its API and agent tooling as well as Codex. The agent ecosystem is therefore gaining something that was largely missing from its first generation: a shared connection standard for context and tools.

## MCP is not the same as an API

MCP and APIs are sometimes presented as alternatives. They are not. An API defines how software communicates with a specific service. A CRM platform might provide a REST API for retrieving customer records, for example. MCP does not have to replace that API: an MCP server can instead sit on top of an existing API, translating standardized MCP requests into the application-specific API calls required by the underlying service.

The distinction is therefore about the layer being standardized. APIs remain extremely useful for conventional software integrations. MCP provides an additional interface designed specifically for making tools and context available to AI applications.

## MCP versus function calling

Function calling and MCP are also different concepts. With function calling, a developer defines functions that a model can request during an interaction. The application receives the function call, executes the corresponding code and returns the result to the model. MCP standardizes how such capabilities can be exposed and discovered externally.

A simplified distinction: *function calling* answers "how can this model invoke a function?", while *MCP* answers "how can tools and context be exposed to AI clients through a standardized interface?" The two technologies can therefore work together rather than replace one another.

## MCP versus RAG

MCP does not make [Retrieval-Augmented Generation](/en/blog/rag-uitgelegd) obsolete either. RAG is a retrieval technique: it finds relevant information and adds that information to a language model's context, typically by storing document embeddings in a vector database and retrieving the passages most relevant to a query. MCP does not prescribe how that retrieval system must work internally.

Instead, an MCP server can expose a RAG system as a tool. The agent might request `search_knowledge_base("return policy for business customers")`. The MCP server forwards the request to the organisation's internal search or vector infrastructure and returns the results. In that architecture, RAG provides the retrieval mechanism. MCP provides the interface through which the agent uses it.

## Why MCP matters for on-premises AI

For organisations that do not want business information flowing indiscriminately through external AI services, MCP is particularly interesting because the integration layer can remain under their own control. MCP servers can operate locally or as remote services, so the protocol does not require business data to be hosted publicly or stored with a particular AI vendor.

An organisation could use a [local language model](/en/blog/on-prem-ai-wanneer-de-moeite) together with local MCP servers and internal databases. It could also use a cloud model while keeping the MCP server within its own infrastructure. AI platforms are increasingly supporting architectures of this kind — OpenAI, for example, documents a Secure MCP Tunnel for connecting private or on-premises MCP servers without opening an inbound public connection to those servers.

That can be useful in privacy-conscious architectures, but MCP does **not automatically make a system GDPR-compliant**. Where data is processed, which personal data is sent to a model, which vendors are involved and which permissions apply remain separate architecture and governance decisions.

## MCP makes security more important, not less

An agent that can only produce text has limited operational power. An agent that can read files, query databases and execute actions in business software is considerably more powerful. An MCP implementation should therefore not be treated as a way to "connect everything and let the model decide."

The official MCP documentation contains extensive security guidance covering authorization, token handling and MCP-specific attack scenarios. Remote MCP implementations can use standardized authorization mechanisms aligned with OAuth conventions. In enterprise environments, important principles include:

-   expose only the tools an agent actually requires;
-   separate read and write permissions;
-   use individual user or service identities where appropriate;
-   log relevant tool calls;
-   require human approval for high-impact operations;
-   validate inputs and outputs;
-   treat information retrieved from external systems as potentially untrusted;
-   keep credentials and tokens out of model context wherever possible.

The last point is particularly important because prompt injection does not need to come directly from a user. Malicious instructions can also be embedded in documents, webpages or other information retrieved by an agent. OpenAI similarly warns about prompt-injection risks when MCP tools or connectors can access sensitive information or perform actions.

## From dozens of integrations to a capability layer

For businesses, one of the most significant consequences may therefore be architectural rather than protocol-level. Imagine an organisation operating several agents: a sales agent, a customer-service agent, an internal knowledge agent, a finance agent and a software-development agent. Several of them may need access to the same CRM, document-management platform or ERP system.

The organisation could create five independent integrations. Alternatively, it could create one controlled integration layer in which business functions are exposed as clearly defined MCP capabilities, for example `find_customer`, `read_contract`, `check_invoice_status`, `search_internal_documentation` and `create_ticket_draft`. Permissions can then determine which agent receives which capabilities. That is architecturally very different from giving every agent unrestricted direct access to databases and APIs.

## MCP makes agents more replaceable — and infrastructure more valuable

Another consequence is reduced dependence on a single language model. An organisation may use a model from vendor A today. A model from vendor B may perform better on the same task next year. If all business integrations are embedded deeply within vendor A's framework, migration can become expensive. A standardized context and tool layer reduces that coupling.

MCP does not create complete model independence — agent frameworks, prompts, model behaviour and supported capabilities still differ — but it does move a significant part of the integration layer toward a more neutral interface. For businesses, this changes where long-term value can reside. The key asset does not have to be merely "which model do we use?" Increasingly, it can be the AI infrastructure around the model: proprietary knowledge, permissions, tools, workflows, audit trails and integrations that allow a general-purpose language model to perform useful work inside the organisation.

## Is MCP the future of AI agents?

MCP does not solve every agent problem. It does not decide which model an organisation should use, turn a poor workflow into a good one or prevent hallucinations and incorrect decisions.

What it does address is a fundamental infrastructure problem: how can AI systems communicate consistently with the tools and information they need? That is important because standards reduce the need to build a bespoke integration for every possible combination of application and data source.

MCP is therefore more than a convenient developer feature. For the next generation of AI agents, it has the potential to become a common connection layer between a model's reasoning capabilities and the actual business environment in which that model is expected to operate. And that is the point at which a language model becomes much more useful: not merely a system that knows what to say, but an agent that — within carefully controlled boundaries — knows which systems it can use to get something done.

## Frequently asked questions about MCP

**Is MCP the same as an API?** No. An API defines how software communicates with a particular application or service. MCP provides a standardized interface through which AI applications can discover and use tools, resources and other capabilities. An MCP server can use existing REST, GraphQL or other APIs behind the scenes.

**Does MCP only work with Claude?** No. Anthropic originally introduced MCP in 2024, but the protocol is open and has since been donated to the Agentic AI Foundation under the Linux Foundation. Other AI platforms also support MCP — OpenAI, for example, supports MCP across its API and agent ecosystem and in Codex.

**Is MCP suitable for sensitive company data and on-premises AI?** Yes, provided the architecture and security controls are designed accordingly. MCP servers can run inside infrastructure controlled by the organisation, with access restricted by tool and identity. MCP itself does not guarantee privacy or GDPR compliance, however. Authorization, data minimisation, logging, model selection, network architecture and human approval for sensitive operations still need to be designed explicitly.

Agents that get to act

## Rolling out MCP or agents safely in your organisation?

Neuralex builds and secures AI agents on-premises — from tool permissions to logging. Let's think through which capabilities you do and don't expose.

[Read about AI agents for SMEs](/en/blog/ai-agents-voor-het-mkb) [Ask your question](/en/contact)

---
Volledige (opgemaakte) versie: https://neuralex.nl/en/blog/wat-is-mcp