MCP: what the protocol changes for integrations

An agent is only useful if it reaches the tools where the work happens. Every agent platform therefore has to connect to dozens of software products, each with its own API, authentication and quirks. The Model Context Protocol, or MCP, proposes a common contract for these connections. Let us be clear from the start: Scalt does not integrate MCP today. We follow the protocol closely, and this article explains what it changes, what it does not solve, and what we expect from it.

The problem with custom integrations

Every in-house connector is debt. You have to handle authentication, pagination, rate limits, API version changes, and start again for the next tool. And the day the API changes, you often find out in production. When every AI application writes its own connectors to every tool, the work multiplies, and the same mistakes repeat from one connector to the next.

Every connector also has to reproduce the same guarantees: respect the user’s rights, trace calls, withstand the tool’s errors and outages. These guarantees, more than the code itself, are what is expensive to maintain.

What the protocol is

MCP is an open protocol, based on JSON-RPC 2.0 messages, that standardises how an AI application connects to data sources and tools. It takes its inspiration from the Language Server Protocol, which did the same for programming language support in code editors. It distinguishes three roles:

• The host: the AI application that opens connections, for instance an assistant or an agent platform.
• The client: the connector, inside the host, that talks to a server.
• The server: the service that exposes context and capabilities.

A server can offer three things: resources, meaning data to consult; prompts, message or task templates; and tools, functions the model can execute. The specification is versioned by date; the most recent one, at the time of writing, is dated 28 July 2026.

What it changes

The main change is a shift of work. A server written once for a tool can serve every compatible application. The tool’s vendor can maintain its own server, as close as possible to its API. And the AI application discovers the available tools and their description, instead of coding them one by one.

For a company, this promises more choice: connecting a new tool without waiting for a vendor to write the connector, or exposing its own internal systems once and for all. It is a real promise, provided you do not forget what the protocol does not solve.

The security questions

The specification says so itself: a tool exposed by a server amounts to arbitrary code execution, and must be treated with caution. Tool descriptions should be considered untrusted, unless they come from a trusted server. The host must obtain the user’s explicit consent before calling a tool or sharing their data. The protocol cannot enforce these principles itself: it is up to the applications that implement it.

The best practices published with the specification detail the known attacks. A server must not accept an access token that was not issued for it, nor pass it on as is to another service. A poorly designed intermediary server can become a “confused deputy” acting with rights that are not the user’s. And overly broad permissions granted up front turn a stolen token into access to everything. Add to that a risk we know well on the data side: content returned by a tool can contain hidden instructions, which end up in the agent’s context.

What we expect from it

If we integrate MCP, it will be on these conditions:

• The agent acts on behalf of the user, with their rights, and never with a technical account holding broad rights.
• Write actions remain subject to the approvals you have defined.
• Every tool call is traced in the execution’s case.
• Content returned by a tool is checked like any other input.

We are not giving a date. We would rather announce an integration when it meets these conditions than a compatibility in principle. If your team already uses MCP servers, tell us about your use cases: they help us decide.

Frequently asked questions