MCP (Model Context Protocol)

1. Vue d'ensemble du concept et problème systémique

Avant l'avènement du protocole MCP, l'écosystème des outils agentiques souffrait du classique problème de compatibilité $N \times M$ :

1. Fragmentation des adaptateurs : Si vous disposez de 5 clients IA (Cursor, Claude Desktop, Continue, un agent CLI interne, une interface web) et de 10 sources de données (PostgreSQL, GitHub, Slack, Sentry, système de fichiers local), les ingénieurs devaient créer et maintenir 50 connecteurs d'intégration distincts.
2. Fuite de clés sensibles : Les applications clientes exigeaient la transmission directe de tokens API dans leur contexte, augmentant ainsi la surface d'attaque.
3. Absence de typage unifié des ressources : Il n'existait aucun standard définissant comment le modèle devait recevoir des données passives (documents en lecture seule) séparément des actions actives ayant des effets de bord (mutations de base de données).

Le Model Context Protocol (MCP) résout ce problème par analogie avec le Language Server Protocol (LSP) dans le monde des IDE : c'est un « USB-C pour l'intelligence artificielle » qui unifie l'interaction entre les clients IA et les outils backend via un protocole ouvert JSON-RPC 2.0.

2. Taxonomie architecturale et modèle mental

Le protocole MCP repose sur une répartition claire client-serveur et opère autour de trois primitives fondamentales :

• 1. Tools (Outils actifs avec effets de bord) : Fonctions exécutables que le modèle peut invoquer pour modifier l'état du monde extérieur (exécution d'une requête SQL, lancement d'un build, envoi d'un commentaire sur GitHub). Elles sont décrites via un schéma JSON Schema strict.
• 2. Resources (Sources de données passives en lecture) : Données adressées par URI sans effets de bord, transmises au contexte du modèle sous forme de documents (contenu de fichiers, logs serveur, schéma de tables, documentation).
• 3. Prompts (Modèles d'interaction) : Prompts pré-paramétrés et chaînes de contexte proposés par le serveur au client (par exemple, une instruction prête à l'emploi pour un audit de vulnérabilités ou la génération d'une migration).
• 4. Couche de transport (Transport Layer) :
  • stdio : Lancement du serveur comme processus enfant sur la même machine. Ne nécessite pas de ports réseau et offre une latence quasi nulle.
  • SSE (Server-Sent Events) : Fonctionnement via HTTP/HTTPS, permettant de connecter des microservices d'entreprise distants et des agents cloud.

3. Pipeline technique et mécanique interne

Le cycle de vie d'une session selon le protocole MCP traverse 4 étapes :

1. Handshake & Capabilities Negotiation (Poignée de main) : Le client envoie une requête initialize, déclarant ses capacités (par exemple, la prise en charge des notifications ou des dossiers racines). Le serveur répond avec la liste de ses propres capacités (Tools, Resources, Prompts) et la version du protocole.
2. Dynamic Discovery (Découverte des services) : Le client interroge les manifestes via tools/list ou resources/list. Les descriptions de fonctions et de paramètres obtenues sont automatiquement traduites au format Function Calling pour le LLM cible.
3. Execution & Context Invocation (Appel de l'action) : Lorsque le modèle génère un appel de fonction, le client le traduit en une requête tools/call vers le serveur MCP correspondant, avec des paramètres JSON validés.
4. Result Streaming & State Notification (Retour du résultat) : Le serveur exécute l'action localement, en utilisant ses propres configurations sécurisées (sans transmettre les mots de passe au client), et retourne le résultat sous forme de texte, d'images ou de ressources intégrées.

4. Scénarios d'ingénierie pratiques en production

01. Accès sécurisé à une base de données de production

Un serveur MCP pour PostgreSQL est déployé au sein d'un périmètre VPC fermé. Il expose uniquement l'outil execute_read_only_query à Cursor ou Claude Code. L'agent peut analyser le schéma et optimiser les requêtes lentes sans avoir accès direct au mot de passe de la base ni aux droits de suppression de données.

02. Boîte à outils unique pour le développeur local

Un seul serveur MCP écrit pour interagir avec GitLab d'entreprise, Jira interne et le service de métriques Datadog se connecte simultanément au terminal CLI (Claude Code), à l'éditeur graphique (Cursor) et aux GitHub Actions automatisées.

03. Automatisation navigateur avec Puppeteer/Playwright

Un serveur MCP pilote un headless-browser, fournissant au client les outils navigate_to, click_element, take_screenshot. L'agent teste et valide les interfaces et le design de manière autonome, sans nécessiter de plugins tiers lourds.

5. Pièges courants, erreurs typiques et sécurité

• Encombrement de la fenêtre de contexte (Context Bloat) : La connexion de 15 serveurs MCP avec des centaines de schémas JSON détaillés peut consommer plus de 30 000 tokens avant même la première entrée utilisateur. Utilisez le filtrage dynamique ou le chargement paresseux des outils (Dynamic Tool Selection).
• Danger des serveurs tiers (Arbitrary Code Execution) : Un serveur MCP local s'exécute avec les privilèges complets de votre compte OS. Le lancement de serveurs non vérifiés via npx -y sans examen du code source peut entraîner le vol de clés SSH locales.
• Violation du contrat de protocole par le logging : L'utilisation de console.log() ou print() standard dans le code du serveur corrompt le canal stdout dans le transport stdio. Écrivez vos diagnostics exclusivement dans stderr.