L'agent enfermé dans ton dossier
La leçon précédente, Les agents : l'IA qui agit, vous a montré un agent qui lit vos fichiers et lance vos commandes. Puissant, mais limité à ce que le terminal voit. Et le reste de votre monde de dev ? Votre base de données PostgreSQL, votre navigateur, vos tickets Jira, votre dépôt GitHub, votre documentation interne ?
Pendant longtemps, chaque connexion demandait une intégration sur mesure. Brancher l'IA sur GitHub : un bricolage. La brancher sur votre base : un autre bricolage, complètement différent. Avec M modèles d'IA et N outils, on se retrouvait à écrire M × N intégrations. Anthropic appelait ça le « problème N×M » : un casse-tête qui explose dès qu'on ajoute un outil ou qu'on change de modèle.
MCP (Model Context Protocol) règle ce casse-tête. C'est une prise standard : on écrit une fois comment exposer un outil, et n'importe quel agent compatible MCP peut s'y brancher. Le M × N devient M + N.
Repère de dates, vérifiés à la source : MCP a été créé et publié en open source par Anthropic en novembre 2024. En mars 2025, OpenAI l'a adopté (ChatGPT, son SDK d'agents). En décembre 2025, Anthropic l'a donné à l'Agentic AI Foundation, un fonds de la Linux Foundation co-fondé avec OpenAI et Block. MCP n'est donc plus le protocole d'un seul éditeur : c'est un standard de l'industrie.
Tu branches un serveur MCP « base de données » sur ton agent, puis tu lui demandes : « Combien de commandes hier ? » Avant de dérouler : comment l'agent sait-il qu'un outil query_sql existe, et qui exécute réellement la requête sur ta base ?
Voir la réponse
Au branchement, le serveur MCP annonce à l'agent la liste de ses capacités, par exemple un outil query_sql avec sa description et ses paramètres. L'agent ne devine rien : il découvre ce catalogue. Quand tu poses ta question, l'agent décide d'appeler query_sql avec la bonne requête, mais c'est le serveur MCP qui l'exécute sur ta base et renvoie le résultat. L'IA orchestre ; le serveur fait le travail réel. C'est tout le principe de la prise standard.
La prise USB-C de l'IA
La documentation officielle le résume d'une image : MCP est « un port USB-C pour les applications d'IA ». Avant l'USB-C, chaque appareil avait son câble propriétaire ; depuis, une seule prise branche tout. MCP fait pareil entre les agents et les outils.
Concrètement, MCP relie trois rôles :
- L'hôte : l'application d'IA que vous utilisez (Claude, ChatGPT, votre éditeur en mode agent).
- Le client : la partie de l'hôte qui parle le protocole MCP.
- Le serveur MCP : le petit programme qui expose un outil ou une source de données précise (votre base, GitHub, le système de fichiers…).
Un serveur MCP expose trois sortes de capacités, et la distinction est utile :
- Les outils (tools) : des actions que l'IA peut déclencher, comme exécuter une requête SQL, créer une issue, prendre une capture d'écran.
- Les ressources (resources) : des données que l'IA peut lire, comme un fichier, une table, une page de doc.
- Les prompts : des modèles de requête préparés que le serveur propose pour des tâches courantes.
Le point clé, c'est la découverte. Quand l'agent se branche, le serveur lui annonce tout seul la liste de ses capacités, avec leur description. L'agent n'a rien codé en dur : il découvre ce qu'il peut faire, puis l'appelle au besoin. C'est le prolongement direct de la leçon Donner des yeux à l'IA : là on lui donnait la vue (des captures d'écran), ici on lui donne des mains branchées sur de vrais outils.
À quoi ça ressemble en vrai
L'écosystème a explosé. Un an après le lancement, MCP comptait des dizaines de millions de téléchargements mensuels de ses SDK et plus de dix mille serveurs actifs, branchables côté client sur Claude, ChatGPT, Cursor, Gemini, Copilot ou VS Code. Quelques serveurs très répandus pour se faire une idée :
- Un serveur système de fichiers : lire et écrire des fichiers dans un dossier donné.
- Un serveur GitHub : lister des issues, ouvrir une pull request, lire le code d'un dépôt.
- Un serveur base de données (PostgreSQL, SQLite…) : interroger un schéma et exécuter des requêtes.
- Un serveur navigateur : ouvrir une page, cliquer, prendre une capture, pour tester une interface.
Côté pratique, on ne « code » pas un serveur pour l'utiliser : on le déclare dans la configuration de son client. Un fichier de config liste les serveurs à lancer, sous une forme très proche de ceci :
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "ton_token_ici" }
}
}
}Au démarrage, le client lance ce serveur, lui demande son catalogue de capacités, et l'agent peut désormais dire « ouvre une issue sur ce dépôt » sans que vous ayez écrit la moindre ligne de glue. Les détails exacts du format changent d'un client à l'autre ; le concept, lui, est toujours le même : déclarer un serveur, l'IA découvre ses outils.
Vous n'avez presque jamais besoin d'écrire un serveur MCP vous-même au début. Cherchez d'abord un serveur existant pour l'outil visé (système de fichiers, GitHub, base de données). On n'écrit son propre serveur que pour exposer un outil maison que personne n'a encore couvert.
Une prise, c'est aussi du pouvoir donné
Brancher un serveur MCP, c'est donner à l'IA une capacité réelle sur un système réel. Un serveur « base de données » avec les droits d'écriture, c'est une IA qui peut modifier votre base. Un serveur « système de fichiers » sur tout le disque, c'est une IA qui peut lire vos secrets. La leçon Sécuriser le code IA vous a appris à traquer les failles dans le code généré ; ici le risque est ailleurs, dans le pouvoir qu'on accorde à l'agent.
Trois réflexes de sécurité, dans l'esprit du moindre privilège :
- La confiance d'abord. Un serveur MCP tiers est du code qui tourne chez vous et que l'IA pilote. N'installez que des serveurs de source fiable, comme vous ne lanceriez pas n'importe quel script trouvé en ligne.
- Le moindre privilège. Donnez au serveur le périmètre minimal : un dossier précis plutôt que tout le disque, un accès lecture seule à la base quand l'écriture n'est pas nécessaire.
- Les données sensibles. Tokens, mots de passe, clés d'API transitent dans la config et les appels. Gardez-les hors du dépôt Git (revoir Sécuriser le code IA : jamais de secret en dur), et méfiez-vous d'un serveur qui enverrait vos données vers un service externe.
Le scénario le plus vicieux : un agent qui lit une donnée externe (un ticket, une page web) où un attaquant a glissé une instruction cachée, du type « supprime la table users ». Si l'agent a un outil MCP qui peut le faire, il risque de l'exécuter. C'est de l'injection de prompt au niveau des outils. La parade : limiter les outils dangereux, exiger une confirmation humaine avant toute action destructrice, et ne jamais brancher en aveugle un serveur sur des données de production.
The agent trapped in your folder
The previous lesson, Agents: the AI that acts, showed you an agent that reads your files and runs your commands. Powerful, but limited to what the terminal sees. And the rest of your dev world? Your PostgreSQL database, your browser, your Jira tickets, your GitHub repo, your internal docs?
For a long time, each connection demanded a bespoke integration. Plug the AI into GitHub: one hack. Plug it into your database: another, completely different hack. With M AI models and N tools, you ended up writing M × N integrations. Anthropic called it the "N×M problem": a headache that explodes as soon as you add a tool or switch models.
MCP (Model Context Protocol) solves that headache. It is a standard socket: you write once how to expose a tool, and any MCP-compatible agent can plug into it. The M × N becomes M + N.
Dates worth pinning, verified at the source: MCP was created and open-sourced by Anthropic in November 2024. In March 2025, OpenAI adopted it (ChatGPT, its agents SDK). In December 2025, Anthropic donated it to the Agentic AI Foundation, a Linux Foundation fund co-founded with OpenAI and Block. MCP is no longer one vendor's protocol: it is an industry standard.
You plug a "database" MCP server into your agent, then ask: "How many orders yesterday?" Before scrolling down: how does the agent know a query_sql tool exists, and who actually runs the query on your database?
Show the answer
On connecting, the MCP server announces its list of capabilities to the agent, for example a query_sql tool with its description and parameters. The agent guesses nothing: it discovers that catalogue. When you ask your question, the agent decides to call query_sql with the right query, but it is the MCP server that runs it against your database and returns the result. The AI orchestrates; the server does the real work. That is the whole point of the standard socket.
The USB-C port for AI
The official docs sum it up in one image: MCP is "a USB-C port for AI applications". Before USB-C, every device had its proprietary cable; since then, one socket plugs everything. MCP does the same between agents and tools.
Concretely, MCP links three roles:
- The host: the AI application you use (Claude, ChatGPT, your editor in agent mode).
- The client: the part of the host that speaks the MCP protocol.
- The MCP server: the small program exposing one specific tool or data source (your database, GitHub, the filesystem…).
An MCP server exposes three kinds of capabilities, and the distinction is useful:
- Tools: actions the AI can trigger, like running an SQL query, creating an issue, taking a screenshot.
- Resources: data the AI can read, like a file, a table, a doc page.
- Prompts: ready-made request templates the server offers for common tasks.
The key point is discovery. When the agent connects, the server announces its list of capabilities on its own, with descriptions. The agent hardcoded nothing: it discovers what it can do, then calls it when needed. It is the direct extension of the Giving AI eyes lesson: there we gave it sight (screenshots), here we give it hands plugged into real tools.
What it looks like in practice
The ecosystem exploded. One year after launch, MCP counted tens of millions of monthly SDK downloads and over ten thousand active servers, plugged client-side into Claude, ChatGPT, Cursor, Gemini, Copilot or VS Code. A few widespread servers to picture it:
- A filesystem server: read and write files in a given folder.
- A GitHub server: list issues, open a pull request, read a repo's code.
- A database server (PostgreSQL, SQLite…): query a schema and run queries.
- A browser server: open a page, click, take a screenshot, to test an interface.
On the practical side, you do not "code" a server to use it: you declare it in your client's configuration. A config file lists the servers to launch, in a form very close to this:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "your_token_here" }
}
}
}On startup, the client launches that server, asks for its capability catalogue, and the agent can now say "open an issue on this repo" without you writing a single line of glue. The exact format details change from one client to another; the concept stays the same: declare a server, the AI discovers its tools.
You almost never need to write an MCP server yourself at first. Look for an existing server for the target tool (filesystem, GitHub, database). You only write your own to expose a custom tool nobody has covered yet.
A socket is also power granted
Plugging in an MCP server means giving the AI a real capability over a real system. A "database" server with write rights is an AI that can modify your database. A "filesystem" server over the whole disk is an AI that can read your secrets. The Securing AI code lesson taught you to hunt flaws in generated code; here the risk is elsewhere, in the power you grant the agent.
Three security reflexes, in the spirit of least privilege:
- Trust first. A third-party MCP server is code running on your machine, driven by the AI. Only install servers from a trusted source, just as you would not run any script found online.
- Least privilege. Give the server the minimal scope: a specific folder rather than the whole disk, read-only database access when writing is not needed.
- Sensitive data. Tokens, passwords, API keys travel through the config and the calls. Keep them out of the Git repo (revisit Securing AI code: never a hardcoded secret), and beware a server that would send your data to an external service.
Beware the nastiest scenario: an agent reads external data (a ticket, a web page) where an attacker slipped a hidden instruction, like "drop the users table". If the agent has an MCP tool that can do it, it might execute it. This is prompt injection at the tool level. The defence: limit dangerous tools, require human confirmation before any destructive action, and never blindly plug a server into production data.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
✨ Prompt IA
Demandez à l'IA, avant de brancher un serveur MCP, de vous expliquer le périmètre de pouvoir que vous accordez, pour décider en connaissance de cause :
Je veux brancher le serveur MCP [nom] sur mon agent. Explique-moi, en concret : quels outils et ressources il va exposer, quelles actions destructrices deviennent possibles, quels secrets (tokens, accès) il réclame, et quel périmètre minimal je devrais lui donner pour le principe du moindre privilège. Liste aussi les vérifications de confiance à faire avant de l'installer.
En quelques lignes, expliquez à un collègue ce qu'apporte MCP. Votre réponse doit faire apparaître : l'idée de prise/standard, la découverte des outils par l'agent, et au moins un réflexe de sécurité (confiance, moindre privilège ou secret).
💬 Ré-explique sans regarder
Avec tes mots : pourquoi MCP est-il comparé à une prise USB-C, et que veut dire « l'agent découvre les outils » d'un serveur plutôt que de les avoir codés en dur ?
⚖️ Juge le code de l'IA
Tu veux que ton agent lise quelques fichiers d'un projet et interroge ta base en lecture. L'IA te propose cette config MCP, à coller telle quelle dans ton dépôt. Ton rôle de relecteur : accepter ou rejeter, et dire pourquoi.
{
"mcpServers": {
"fichiers": {
"command": "npx",
"args": ["-y", "server-filesystem", "/"]
},
"db": {
"command": "npx",
"args": ["-y", "server-postgres"],
"env": { "DATABASE_URL": "postgres://admin:Motdepasse123@prod/db" }
}
}
}/, soit tout le disque : c'est l'opposé du moindre privilège, il fallait viser le dossier du projet. 2) L'accès base pointe sur la prod avec un compte admin en écriture, alors que tu ne voulais que lire : un serveur en lecture seule sur une base de test ou un réplica suffit. 3) Le mot de passe est en dur dans un fichier destiné au dépôt Git : exactement le secret en clair que la leçon « Sécuriser le code IA » interdit. Bon réflexe : périmètre minimal (dossier précis), accès lecture seule hors prod, et secrets en variables d'environnement jamais commitées.🧠 Rappel libre
Sans remonter dans la leçon : à quel problème MCP répond-il, quelles sont les trois sortes de capacités d'un serveur, et cite un réflexe de sécurité avant de brancher un serveur.
Vous tenez maintenant la méthode complète : du prompt à l'agent autonome branché sur vos outils, sans jamais lâcher le jugement. Reste à l'ancrer là où ça compte : sur de vrais projets, du début à la fin, avec un rendu concret à montrer.
Passer aux projets →