MCP — Model Context Protocol
MCP en profondeur : transports, cycle de vie, design de serveurs, et intégration dans des workflows multi-agents.
MCP en profondeur
Le premier passage couvrait les fondamentaux : architecture client/serveur, tools vs resources, choix d’outils, sécurité. Ce second passage approfondit les aspects pratiques : transports, cycle de vie d’un serveur, design d’outils, et intégration dans un workflow de développement réel.
Transports MCP
MCP ne prescrit pas un seul mode de communication. Le protocole fonctionne au-dessus de différents transports.
stdio (entrée/sortie standard)
Le client lance le serveur MCP comme un sous-processus. La communication passe par stdin/stdout. C’est le transport le plus simple et le plus courant pour le développement local.
Point clé : Pas de réseau, pas de port, pas de firewall. Le serveur démarre et meurt avec la session de l’agent.
HTTP avec Server-Sent Events (SSE)
Le serveur MCP tourne comme un service HTTP. Le client envoie des requêtes POST, le serveur renvoie des événements via SSE. Utile pour les serveurs partagés ou distants.
Point clé : Le serveur peut servir plusieurs clients en parallèle, tourner sur une autre machine, et persister entre les sessions.
Piège : Le choix du transport n’affecte pas la logique de l’outil — seulement comment le client et le serveur communiquent. Un même serveur MCP peut souvent supporter les deux transports.
Cycle de vie d’un serveur MCP
L’initialisation MCP suit un protocole précis :
| Étape | Description |
|---|---|
| 1. Connexion | Le client établit le canal de transport (lance le processus ou se connecte en HTTP). |
| 2. Initialize | Le client envoie initialize avec ses capacités. Le serveur répond avec les siennes. |
| 3. Initialized | Le client confirme avec initialized. Le serveur est prêt. |
| 4. Discovery | Le client appelle tools/list et resources/list pour découvrir les capacités. |
| 5. Utilisation | Le client appelle des outils (tools/call) ou lit des ressources au fil de la session. |
Point clé : Ce handshake permet la négociation de capacités. Un client qui ne supporte pas les resources ne les demandera pas. Un serveur peut adapter son comportement selon les capacités du client.
Bien concevoir un serveur MCP
Nommage et descriptions
Le LLM choisit un outil MCP uniquement en lisant son nom et sa description. Un outil mal nommé ou mal décrit ne sera jamais appelé — ou sera appelé à tort.
Point clé : Le nom doit être un verbe d’action (
create_ticket,search_logs) et la description doit expliquer quand utiliser l’outil, pas seulement ce qu’il fait.
Granularité
Un serveur MCP devrait exposer des outils à la bonne granularité : ni trop fins (le LLM doit orchestrer 4 appels pour une seule action), ni trop gros (le LLM ne sait pas quand l’utiliser). La bonne granularité : une action métier = un outil.
Gestion des erreurs
Quand un outil MCP échoue, le message d’erreur est réinjecté dans le contexte du LLM. Plus le message est clair et actionnable, mieux l’agent peut se corriger.
Piège : Un outil qui renvoie
{"error": "500 Internal Server Error"}est inutile pour l’agent. Préférer :{"error": "Table 'orders' n'existe pas. Tables disponibles : products, customers, invoices."}— c’est le Leverage Point 5 (Standard out) appliqué au design de serveurs MCP.
MCP et The Agentic Layer
MCP est la brique d’extensibilité de la couche agentique (The Agentic Layer). Quand une équipe standardise ses workflows agentiques, elle capitalise ses intégrations sous forme de serveurs MCP réutilisables.
Point clé : Un serveur MCP bien conçu est comme un port dans l’architecture hexagonale : il définit un contrat d’interaction stable, indépendant de l’agent qui le consomme. Le serveur MCP appelle la même couche applicative que les contrôleurs REST — il ne contourne pas la logique métier, il y accède via un nouveau canal.
Remonte relire la fiche memo ci-dessus en pretant attention aux points rates, puis clique sur « Recommencer » pour retenter.