MCP (Model Context Protocol): Connect Your Tools to AI, Cleanly

Generative AI becomes truly useful when it can act: read your data, call your tools, trigger actions. MCP (Model Context Protocol) is the standard that makes this clean and controlled.

The Problem MCP Solves

Connecting an LLM to your systems, database, CRM, internal API, used to be done on a case-by-case basis, with custom code for each connection. Result: fragile, hard to secure, and difficult to maintain.

MCP standardizes this connection. A MCP server exposes tools and data to the model in a declared and controlled way. The model knows which tools exist, what they do, and calls them within a defined framework.

The specification is public and versioned, which changes a great deal compared with bespoke integrations. An MCP server exposes three kinds of primitive: tools the model can call, resources it can read, and prompts the application can offer the user. The same server works with any compatible client, which removes the rewrite every time the assistant changes. Two transports coexist: stdio for a local server launched by the client, and HTTP for a remote one, not a trivial choice, since it determines who can reach the server.

What This Changes in Practice

• Controlled access: you decide exactly which data and actions the model can reach. No open pipe.
• Reusable: a well-built MCP server serves multiple assistants or agents, without rewriting everything.
• Auditable: calls go through an explicit, traceable interface.

“Controlled access” has to be engineered, and the specification devotes a whole page to it. The MCP security best practices name several attacks and their mandatory countermeasures. “Token passthrough” is explicitly forbidden: an MCP server must never accept a token that was not issued to it, otherwise it becomes an anonymous relay into your internal APIs. Sessions must not be used for authentication, and session identifiers must be random and bound to the user. The confused deputy problem requires per-client consent before redirecting to a third-party provider. Add least privilege on scopes: start with a minimal read-only set, and elevate only on demand.

Custom MCP Servers

In our projects, we build MCP servers that expose your data (a Supabase database, an ERP, a business API) to an AI assistant, often powered by a sovereign model like Mistral. The AI becomes capable of responding and acting within your scope, without uncontrolled access. It’s a core building block of our AI assistants connected to your data.

One risk remains untouched whatever the protocol, and it deserves stating before opening tools to a model: prompt injection, ranked first in the OWASP Top 10 for large language model applications. Text sitting in an indexed document, a customer ticket or a web page read by the agent can carry instructions that hijack its behaviour. MCP standardises access to tools; it does not filter what the model decides to do with them. Three rules therefore apply on the server side: expose only the tools strictly needed, apply the real user’s rights rather than an all-powerful service account: this is broken access control from the OWASP Top 10, and require human approval for every irreversible action.

In summary

MCP isn’t a gimmick: it’s the clean way to give AI access to your systems, with the control and traceability required for production.

Need to connect an assistant or agent to your tools? Let’s talk.