What Is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open, open-source standard introduced by Anthropic in November 2024. It standardizes how AI applications, notably large language models (LLMs), connect to external tools, systems, and data sources [11].

A standardization layer between AI and services

IBM describes MCP as a standardization layer. It allows AI applications to communicate with external services: tools, databases, predefined models [12]. MCP is neither an AI model nor business software. It is a protocol, that is, a common exchange convention between the assistant and the systems it needs to use.

Mendix, a development platform publisher, defines it in similar terms: an open-source protocol that allows AI applications to connect to external data sources and tools, with a promise of security [19]. This promise is made by the publisher. It must be verified in each deployment.

The USB-C analogy

To illustrate this role, several commercial players use the USB-C comparison.

• Red Hat presents MCP as a single, standardized protocol for connecting an AI application to an external system, comparing it to a USB-C cable that connects a device to various accessories [1].
• NextStart.AI speaks of the "USB-C port of enterprise AI" [30].

The analogy relies on the prior situation. Before MCP, each publisher had to develop its own connector for each model, and each company had to maintain these integrations through every update [30]. With a common port, the same tool can in principle be plugged into different assistants without specific development.

The image has its limits: USB-C is a hardware standard, whereas MCP is a software protocol. The following sections detail how it works, how it differs from a traditional API, and the precautions to take for enterprise deployment.

What problem does MCP solve for a company?

MCP primarily solves an integration problem: connecting an AI model to a company's tools used to require as many custom connectors as there were model/tool combinations. Before the protocol, each publisher had to develop its own connector for each model, and each company had to maintain these integrations at every update [30].

The multiplying "plumbing"

The difficulty lay less in the models' reasoning capacity than in the plumbing needed to connect them to the information system. This plumbing multiplied with each new assistant/tool combination [21]. Many AI projects had until then relied on hand-built integrations for each model + tool pair [27]. The arithmetic is simple: ten tools and three assistants potentially represent thirty distinct integrations, to be developed and then maintained. MCP addresses this interoperability obstacle by offering a universal protocol [10].

Models that only know their training

The second problem lies with the models themselves. A large language model (LLM) generally only knows the data it was trained on, and that data can quickly become outdated [8]. For professional use, this is a direct limitation: a model alone knows nothing about the status of a client file, a stock level, or a ticket opened this morning.

MCP tackles this limitation by giving models structured, evolving access to the data and tools they need. Context drawn from enterprise systems is then real-time and verifiable [18]. The AI's answers thus rely on the current state of systems, not only on what the model has learned.

What this changes for an IT department

Before MCP	With MCP
One connector per model and per tool [30]	A common protocol between models and tools [10]
Maintenance at every update [30]	Standardized interface, no recoding for each model [10]
Model limited to its training data [8]	Access to real-time context [18]

The protocol does not make models more "intelligent." It shifts the effort: instead of rewriting integrations, technical teams rely on a shared interface between AI and tools.

How does MCP work in practice?

MCP is based on a client-server architecture. The MCP client issues standardized requests, and MCP servers expose the company's resources (databases, APIs, tools) through a unified interface [17].

Messages, roles, and authentication

Exchanges are bidirectional [8][17] and pass through JSON messages [17]. The architecture is based on JSON-RPC 2.0 and clearly separates three roles: host, client, and server [27]. The vocabulary varies across sources. [17] simply calls the AI model the "client," whereas [27] distinguishes the host from the client. For authentication, [17] indicates that the protocol uses OAuth2. This point comes from a single source in the file, and it must be confirmed in the official specification before an architecture is fixed.

Dynamic tool discovery

The model discovers available tools by itself, without a hard-coded list [17][26]. This discovery happens at runtime: a tool added to a server instantly becomes accessible to connected models [35]. For an IT department, enriching a server is therefore enough to extend the assistant's capabilities, without modifying each client application.

Multi-step workflows

This architecture makes it possible to run stateful, multi-step workflows, rather than isolated request-response interactions [9]. The AI can thus access the right data, at the right time, and interact with business systems as a employee would [26].

A specification that evolves

One source mentions a version of the specification dated July 28, 2026, which would introduce a "stateless" core and authorization improvements [13]. This point seems to qualify the notion of stateful workflows described above [9]. The file does not contain the official specification, and [13] is popularization content. We therefore do not settle the question: before any development, check the version in force in the protocol's documentation.

How does MCP differ from a traditional API or connector?

An API exposes a specific function of a tool, while MCP standardizes the dialogue between an AI and that tool [23]. The two do not sit at the same level: the API describes what a software can do, the protocol describes how an AI model accesses it.

What MCP changes compared with a traditional connector

A traditional connector is written for a specific pair, one model and one tool. Before MCP, each publisher had to develop its own connector for each model, and each company had to maintain these integrations through updates [30]. MCP moves this work to three places:

• Standardized access: the protocol unifies the way a model accesses tools and data [5].
• Separation of responsibilities: business logic, the model, and the infrastructure remain distinct [5].
• Reuse: a single MCP server per tool can serve all of the company's AI applications [15].

According to an editorial source, an assistant can then read and write in the CRM, ERP, messaging, or calendar without specific integration [29]. This promise is made by a commercial player and remains to be validated on each deployment.

A layer that complements APIs

MCP does not replace APIs. In the architecture described, MCP servers expose resources (databases, APIs, tools) through a unified interface [17]. The API remains the means of access to the application, and the MCP server makes it usable by a model in a standard way. For non-AI uses (system-to-system exchanges, batch processing), nothing in the file justifies going through MCP.

A methodological point

The most categorical formulations of this comparison come from editorial or commercial sources: [23] for the distinction between API and MCP, [15] for the reuse of a server by all AI applications. The description of the separation between business logic, model, and infrastructure [5] comes from a software publisher. These sources describe the protocol's intent. The real gain depends on the number of tools and assistants to connect, and the IT department must measure it on its own scope.

Which tools and use cases can be connected via MCP?

The Model Context Protocol primarily targets enterprise tools: CRM, Slack, Google Drive, and databases [3]. Concretely, an AI assistant can read and write in these tools, including the ERP, messaging, and calendar, without specific integration [29]. This write capability, which allows acting and not just consulting, calls for access rights precautions, addressed later in this article.

Tool categories concerned

Category	Examples cited
Customer relations and management	CRM, ERP [29]
Communication and organization	Messaging, calendar, Slack [3][29]
Documents and data	Google Drive, databases [3]

Use case: a local government

In an administrative or local-government document assistant, MCP can connect a conversational agent to several internal sources [33]. The source cites four types:

• file directories;
• document databases;
• ticketing tools;
• knowledge bases [33].

The agent thus queries these resources from a single conversational interface, instead of each requiring its own development. The text, published by the Banque des Territoires, presents the protocol as a component of enterprise AI architecture, not as a mere technical detail [33].

Use case: industry

In manufacturing, MCP provides language models with the context they need from the tools and systems manufacturers already use [6]. The model therefore does not have to rely on a separate dataset: it works with the systems that run the plant. This source comes from a commercial player, and its formulations describe a potential rather than a measured result.

What to keep in mind for scoping

These two cases share the same principle: AI plugs into existing systems instead of replacing them. For an IT department, the starting question is therefore less "which model to choose?" than "which internal sources to expose, with which read and write rights?"

Is MCP a truly adopted standard?

MCP is presented as adopted by the main AI providers, but the file contains no primary source (publisher press release or official specification). The facts below come from secondary sources, often commercial, and some remain to be confirmed.

What the sources agree on

• Origin: MCP is an open standard introduced by Anthropic in November 2024 [11].
• OpenAI: adoption dates from March 2025 [29].
• Google and Microsoft: a consulting agency indicates that MCP was adopted by OpenAI, Google, and Microsoft in 2025 [16]. The file gives no precise date for Google or Microsoft.
• Ecosystem: the project publishes reference servers (file systems, PostgreSQL databases, web search), and an official registry lists available servers. Community directories list thousands of others, from database connectors to niche business tools [31]. This description comes from a practical guide written by an agency, without a precise count.

What remains to be verified

Information	Source	Status
Specification dated 2026-07-28, with a stateless core and authorization improvements	Sortlist [13]	Secondary source, to be confirmed against the official specification
40% of enterprise applications embedding AI agents by end of 2026, versus under 5% in Q1 2026	Divalto, citing Gartner via Context Studios (March 2026) [32]	Forecast reported by a software publisher, not verified with Gartner

On the specification, the source indicates only these two developments [13]. If confirmed, they would concern state management and authorization, two points to examine before any deployment. The version in force on the official specification must therefore be read before fixing an architecture.

On the Gartner forecast, the chain of transmission has two intermediaries. It also concerns AI agents rather than MCP itself: it is Divalto that asserts MCP is the protocol these agents rely on to access data [32]. It gives an order of magnitude, not a measure of the protocol's adoption.

In practice, adoption by the major providers and the size of the ecosystem are well attested. Precise specification versions and market figures must be verified with primary sources.

Is MCP safe? What precautions should the IT department take?

MCP is presented as a safe way to connect AI to enterprise systems, but the available sources describe this promise without demonstrating it. The security of a deployment therefore depends on its own risk analysis.

What the sources say

Several sources associate MCP with a secure connection. Proofpoint describes it as an open standard allowing models to connect "securely" to external data sources and systems [2]. Mendix speaks of connecting "in a secure manner" [19]. Digitalkin describes it as a "reliable, portable, and traceable" standard [34]. Kiteworks, a security-focused publisher, makes AI security a central issue of the protocol [7].

These claims are mostly editorial. They come from commercial players, some of whom sell security or development products. They should be read as positioning, not as audit results.

What the file does not allow us to assert

The file details no specific MCP risk, quantifies no vulnerability, and documents no incident. It therefore does not allow concluding that the protocol is safe by design, nor listing its flaws. One source describes exchanges in JSON messages with OAuth2 authentication [17]. Another mentions "authorization improvements" in a specification version dated 2026-07-28 [13]. This date is surprising and must be verified in the official specification before any decision.

Three points to examine before each deployment

The IT department can frame the analysis around three axes:

• Authentication: how the MCP client and each server identify themselves, and how access is granted and revoked.
• Scope of rights: what the assistant can read and, above all, write in each tool. Sources indicate that an assistant can act in business tools such as a CRM or ERP [29], which makes this scope decisive.
• Traceability: the ability to reconstruct which actions were triggered, by whom, and with which data. The mention of traceability remains to be verified on the actual deployment [34].

This analysis must cover each MCP server selected, whether it comes from a publisher, a community directory, or internal development.

How to implement MCP, and where does Oupi fit in?

A company has three paths to implement MCP: reuse existing servers, develop its own servers, or rely on an agency or training. These paths can be combined.

1. Use existing servers. The MCP project publishes reference servers (file systems, PostgreSQL databases, web search). An official registry lists available servers, and community directories list thousands of others, from database connectors to niche business tool integrations [31]. This is the fastest starting point for common tools. The file does not specify how community directories are verified: a technical and security review before any use is essential.

2. Develop in-house servers. Systems specific to the company (custom ERP, intranet, price database) call for in-house servers [31]. This development falls to the internal team, which exposes its own data and functions through the protocol.

3. Go through an agency or training. Agencies offer to develop custom MCP servers and integrate them into existing workflows [24]. On the training side, one provider offers to learn how to design composable architectures based on MCP servers and connect LLMs to tools and data exposed via the protocol [25]. Another offers inter-company or in-house training, in France or remotely, from €1,700 excl. VAT and eligible for OPCO funding [4]. These offers come from commercial players: the content and prices are those of the providers.

In practice, one can start with existing servers for standard tools, reserve specific development for internal systems, and build skills in parallel.

Where Oupi fits

Oupi is an AI platform designed, developed, and hosted in France. It connects to hundreds of external applications via MCP and connectors.