MCP — Model Context Protocol

Le problème que MCP résout

Un agent de développement a des outils intégrés : lire un fichier, écrire du code, exécuter un build. Mais en entreprise, on veut souvent qu’il interagisse avec des systèmes externes : une base de données, un outil de ticketing, un service de CI, une API métier.

Avant MCP, chaque agent avait son propre système de plugins. Un outil développé pour Claude Code ne marchait pas dans Cursor, et inversement. On recodait la même intégration pour chaque agent.

Point clé : MCP est un standard ouvert qui définit comment un agent (client) découvre et appelle des outils exposés par un serveur externe. Un outil écrit une fois fonctionne dans tout agent compatible MCP. L’analogie : MCP est aux agents ce que HTTP est aux navigateurs.

Architecture client / serveur

Les deux rôles

Tools vs Resources

Un serveur MCP expose deux types de capacités :

• Tools : des fonctions que le LLM peut appeler (ex : create_ticket, query_database). C’est du function calling classique, mais standardisé.
• Resources : des données que le client peut lire pour enrichir le contexte (ex : la liste des tables d’une base, un schéma d’API). Les resources ne sont pas appelées par le LLM directement — elles alimentent le contexte.

Point clé : Les tools sont des actions (le LLM décide de les appeler). Les resources sont des informations (le client les injecte dans le contexte). Cette distinction détermine ce que le LLM contrôle activement et ce qu’il reçoit passivement.

Comment le LLM choisit un outil MCP

Le mécanisme est le même que pour le function calling natif (voir chapitre 5) : le client transmet au LLM la liste des outils MCP avec leur nom, description, et schéma de paramètres. Le LLM choisit en lisant les descriptions.

Piège : La qualité de la description reste déterminante. Un outil MCP mal décrit ne sera jamais appelé, ou sera appelé à mauvais escient — même si son implémentation est parfaite.

Flux d’un appel MCP

1. Le LLM reçoit la liste des outils MCP dans son contexte
2. L'utilisateur pose une demande ("crée un ticket pour ce bug")
3. Le LLM choisit l'outil : { "name": "create_ticket", "input": { "title": "..." } }
4. Le client MCP transmet l'appel au serveur MCP
5. Le serveur exécute et renvoie le résultat
6. Le client réinjecte le résultat dans le contexte du LLM
7. Le LLM continue (répond ou appelle un autre outil)

MCP dans le Core Four

MCP s’inscrit directement dans le 4e levier du Core Four : Tools. Plus un agent dispose d’outils pertinents, plus il peut agir de manière autonome. MCP est le mécanisme qui rend ce levier extensible à l’infini sans modifier l’agent lui-même.

Point clé : MCP concerne aussi le levier Context (via les resources) : un serveur MCP peut fournir du contexte métier (schéma de base, documentation d’API) que le client injecte automatiquement. C’est le concept de The Agentic Layer : une couche d’outils et de contexte qui entoure l’agent et le rend spécifique à un projet.

Sécurité et limites

Risques

• Prompt injection via MCP : un serveur MCP malveillant ou compromis peut renvoyer des données contenant des instructions destinées à détourner le LLM.
• Permissions larges : un outil execute_sql sans restriction permet au LLM de faire n’importe quelle requête — y compris des DROP TABLE.
• Explosion du contexte : connecter trop de serveurs MCP sature la fenêtre de contexte avec les descriptions d’outils, laissant moins de place au raisonnement.

Garde-fous

• Ne connecter que les serveurs MCP nécessaires à la tâche en cours.
• Restreindre les permissions côté serveur (read-only quand possible).
• Valider les résultats renvoyés par le serveur avant de les réinjecter dans le contexte.

Piège : Connecter 15 serveurs MCP “au cas où” est un anti-pattern. Chaque serveur ajoute des descriptions d’outils dans le contexte du LLM, ce qui consomme des tokens et peut créer de la confusion dans le choix d’outils. Pragmatisme : connecter uniquement ce dont l’agent a besoin.