Le Model Context Protocol : le protocole manquant de l'ère AI-Native

En cherchant à résoudre son propre irritant, David Soria Parra met le doigt sur un défi bien plus large — ce que l'industrie appelle le problème M×N.

Le principe est simple à énoncer, redoutable à gérer. Une entreprise déploie M modèles d'IA (Gemini, Claude, un modèle OpenAI) et souhaite les connecter à N outils ou sources de données (une base de données, une API métier, un calendrier). Chaque combinaison exige un connecteur dédié. Cinq modèles, trois outils : quinze intégrations distinctes à développer, tester et maintenir.

Le nœud du problème réside dans la fragmentation des interfaces. Chaque fournisseur impose ses propres conventions :

• OpenAI requiert des schémas JSON structurés pour la définition des outils ;
• Anthropic (Claude) s'appuie sur des balises de type XML ;

• Google Gemini exige ses propres structures et SDK propriétaires.

Résultat : un outil parfaitement opérationnel dans un écosystème devient inutilisable dans un autre sans réécriture intégrale de son interface. L'interopérabilité n'existe tout simplement pas.

Le problème M×N en un schéma :

graph LR
    subgraph "Modèles (M)"
        LLM1["OpenAI"]
        LLM2["Claude"]
        LLM3["Gemini"]
    end

    subgraph "Outils (N)"
        T1["Base de données"]
        T2["API Métier"]
        T3["Calendrier"]
        T4["Système de fichiers"]
    end

    LLM1 -->|"connecteur spécifique"| T1
    LLM1 -->|"connecteur spécifique"| T2
    LLM1 -->|"connecteur spécifique"| T3
    LLM1 -->|"connecteur spécifique"| T4
    LLM2 -->|"connecteur spécifique"| T1
    LLM2 -->|"connecteur spécifique"| T2
    LLM2 -->|"connecteur spécifique"| T3
    LLM2 -->|"connecteur spécifique"| T4
    LLM3 -->|"connecteur spécifique"| T1
    LLM3 -->|"connecteur spécifique"| T2
    LLM3 -->|"connecteur spécifique"| T3
    LLM3 -->|"connecteur spécifique"| T4

    style LLM1 fill:#ff6b6b,stroke:#c92a2a,color:#fff
    style LLM2 fill:#ff6b6b,stroke:#c92a2a,color:#fff
    style LLM3 fill:#ff6b6b,stroke:#c92a2a,color:#fff
    style T1 fill:#4dabf7,stroke:#1971c2,color:#fff
    style T2 fill:#4dabf7,stroke:#1971c2,color:#fff
    style T3 fill:#4dabf7,stroke:#1971c2,color:#fff
    style T4 fill:#4dabf7,stroke:#1971c2,color:#fff

3 modèles × 4 outils = 12 connecteurs à développer et maintenir. Chaque ajout de modèle ou d'outil multiplie la complexité.

Cette fragmentation impose une charge cognitive considérable. Les développeurs jonglent entre des méthodes d'authentification, des modèles de gestion d'état et des stratégies de traitement d'erreurs radicalement différents d'un fournisseur à l'autre. L'architecture résultante s'apparente à un château de cartes : la moindre modification d'interface par un fournisseur menace la stabilité de l'ensemble.

La dette technique s'accumule mécaniquement. Chaque équipe est prisonnière d'une maintenance perpétuelle, mobilisée par des correctifs urgents plutôt que par l'innovation. Un nouvel outil de détection de fraude ? Il faudra le décliner en autant de versions qu'il y a de modèles déployés. La mutualisation est paralysée, l'innovation freinée.

C'est précisément ici que l'héritage du LSP prend tout son sens. David Soria Parra comprend qu'un protocole standardisé peut transformer cette impasse combinatoire M×N en une équation linéaire M+N. Un seul connecteur par LLM, un seul connecteur par outil. Le reste est affaire de protocole.

La solution M+N avec le MCP :

graph LR
    subgraph " Modèles (M)"
        LLM1["OpenAI"]
        LLM2["Claude"]
        LLM3["Gemini"]
    end

    MCP{{" Protocole MCP"}}

    subgraph "Outils (N)"
        T1["Base de données"]
        T2["API Métier"]
        T3["Calendrier"]
        T4["Système de fichiers"]
    end

    LLM1 --- MCP
    LLM2 --- MCP
    LLM3 --- MCP
    MCP --- T1
    MCP --- T2
    MCP --- T3
    MCP --- T4

    style LLM1 fill:#51cf66,stroke:#2b8a3e,color:#fff
    style LLM2 fill:#51cf66,stroke:#2b8a3e,color:#fff
    style LLM3 fill:#51cf66,stroke:#2b8a3e,color:#fff
    style MCP fill:#fcc419,stroke:#e67700,color:#000,stroke-width:3px
    style T1 fill:#4dabf7,stroke:#1971c2,color:#fff
    style T2 fill:#4dabf7,stroke:#1971c2,color:#fff
    style T3 fill:#4dabf7,stroke:#1971c2,color:#fff
    style T4 fill:#4dabf7,stroke:#1971c2,color:#fff

3 modèles + 4 outils = 7 connecteurs. Chaque nouveau LLM ou outil ne nécessite qu'un seul connecteur supplémentaire.

Il partage cette vision avec Justin Spahr-Summers. Ensemble, ils posent les fondations du MCP. Lors d'un hackathon interne chez Anthropic, plusieurs équipes s'emparent immédiatement du concept pour développer de nouvelles intégrations Claude Desktop. L'engouement est organique, spontané — il préfigure le succès public qui suivra un mois plus tard.

Avant même le lancement officiel, Anthropic accorde un accès anticipé à plusieurs éditeurs. Dès sa publication, le protocole est déjà intégré dans des IDE majeurs comme VS Code et dans de nombreux outils du quotidien développeur. Cette stratégie de déploiement "clé en main", combinée à la simplicité de création de serveurs MCP, propulse l'adoption à une vitesse remarquable.

Cette accessibilité a toutefois un revers. Dans la précipitation, de nombreux serveurs sont déployés avec des vulnérabilités critiques : authentification absente, exposition de données sensibles, dysfonctionnements en cascade.

Lectures complémentaires :

• Dark Reading — Agentic AI Risky MCP Backbone Attack Vectors
• Le Monde Informatique — Le piratage du logiciel médical de Cegedim refait surface
• Invariant Labs — MCP GitHub Vulnerability
• Noma Security — AI Agent Vulnerability in LangSmith

Loin de freiner l'élan, ces défis de jeunesse catalysent l'organisation de la communauté. Les développeurs se rassemblent sur des espaces dédiés — r/mcp, r/modelcontextprotocol, serveurs Discord communautaires — pour partager leurs retours d'expérience, établir des bonnes pratiques de sécurité et contribuer à la maturation de la spécification.

Dans les années 2010, la conteneurisation (popularisée par Docker) révolutionne le déploiement logiciel. Mais l'orchestration à grande échelle plonge l'industrie dans la confusion car dès 2014, Kubernetes, Docker Swarm et Apache Mesos se lancent quasi simultanément dans la course, chacun porté par sa propre vision de l'orchestration.

Les entreprises qui investissent dans l'une de ces plateformes se retrouvent captives de son écosystème, c'est le fameux lock-in. L'absence de standard commun génère de la friction, ralentit l'adoption et fragmente les compétences.

Plusieurs années de compétition acharnée — ce que l'industrie a surnommé les "guerres de l'orchestration" — seront nécessaires avant que Kubernetes ne s'impose durablement, porté par la solidité de son héritage (Borg, le système d'orchestration interne de Google) et par la dynamique de la Cloud Native Computing Foundation, fondée en 2015 pour l'héberger. Vers 2017-2020, le verdict est sans appel : Kubernetes devient le langage commun, le standard universel autour duquel l'industrie tout entière se réorganise. Les briques technologiques s'emboîtent enfin. L'industrie entre dans l'ère Cloud Native : microservices, CI/CD, DevOps deviennent des pratiques dominantes, portées par un écosystème unifié et interopérable.

Le MCP joue aujourd'hui, pour l'IA, un rôle comparable à celui que Kubernetes a fini par jouer pour le Cloud. Il pose l'infrastructure de communication indispensable pour entrer dans l'ère AI-Native : une ère où l'intelligence artificielle n'est plus un gadget greffé à une application existante, mais le cœur d'un système capable de raisonner, d'apprendre et d'agir de manière autonome !

Le succès du MCP a ouvert la voie à d'autres initiatives. Là où le MCP standardise l'accès d'un LLM à ses outils et données, de nouveaux protocoles se spécialisent dans la communication entre agents.

L'initiative la plus significative est le protocole Agent2Agent (A2A) de Google (blog officiel). Ses concepteurs l'affirment sans ambiguïté : A2A ne concurrence pas le MCP, il le complète. Dans une architecture moderne, le MCP connecte un agent à ses outils externes ; l'A2A lui permet de collaborer, de se synchroniser et de déléguer des tâches à d'autres agents.

Deux autres initiatives méritent l'attention :

• Agent Communication Protocol — une API RESTful standardisée portée par IBM, qui permet à des agents hétérogènes (architectures et modèles différents) de coopérer de manière fluide. Son parti pris est délibérément minimaliste : pas de SDK imposé, pas de runtime spécifique. N'importe quel service exposant une API HTTP peut devenir un agent ACP. C'est son principal avantage sur A2A dans des environnements d'entreprise déjà fortement REST-centric, où l'on cherche à intégrer l'IA sans refondre l'infrastructure existante.

• Agent Network Protocol — développé en Chine par un consortium autour de AgentNetworkProtocol.com, ce protocole adopte une posture radicalement différente : il intègre nativement la gestion des identités décentralisées (DID), l'authentification et le chiffrement de bout en bout des communications inter-agents. Là où A2A et ACP supposent implicitement un environnement de confiance relative (agents appartenant à la même organisation ou au même écosystème partenaire), ANP est conçu pour des scénarios zero-trust à grande échelle — des agents autonomes qui se découvrent et interagissent sur un réseau ouvert, sans autorité centrale de confiance préétablie.

Comment choisir ?

La maturité des protocoles est très inégale à ce stade. A2A, porté par Google avec le soutien de plus de 50 partenaires industriels dès son lancement, dispose de la dynamique d'adoption la plus forte et des meilleures garanties de pérennité à court terme. ACP est le choix naturel pour des équipes enterprise déjà investies dans des architectures REST et qui souhaitent une intégration sans friction. ANP répond à des besoins encore émergents — marchés d'agents publics, orchestration inter-organisations, scénarios où aucune partie ne peut être désignée comme autorité centrale — mais son écosystème d'outillage reste limité. En pratique, pour la grande majorité des architectures multi-agents d'entreprise en 2025-2026, A2A combiné au MCP constitue le point de départ le plus solide.

L'écosystème se structure rapidement, mais il reste en chantier. La coexistence de plusieurs protocoles concurrents n'est pas nécessairement un problème : elle reflète des besoins légitimement différents. Ce qui compte, c'est de comprendre la couche que chacun adresse — et le MCP reste la fondation commune sur laquelle tous s'appuient pour connecter les agents à leurs outils.

Positionnement des protocoles dans l'écosystème Agentic AI :

graph TB
    subgraph "Communication inter-agents"
        A2A["Agent2Agent\n(Google)"]
        ACP["Agent Communication\nProtocol"]
        ANP["Agent Network\nProtocol"]
    end

    subgraph "Connexion Agent ↔ Outils"
        MCP["Model Context Protocol\n(Anthropic)"]
    end

    subgraph "Agents IA"
        AG1["Agent 1"]
        AG2["Agent 2"]
    end

    subgraph "Outils & Données"
        TOOL1["APIs"]
        TOOL2["Bases de données"]
        TOOL3["Services SaaS"]
    end

    AG1 <-->|"A2A / ACP / ANP"| AG2
    AG1 <-->|"MCP"| TOOL1
    AG1 <-->|"MCP"| TOOL2
    AG2 <-->|"MCP"| TOOL2
    AG2 <-->|"MCP"| TOOL3

    style MCP fill:#fcc419,stroke:#e67700,color:#000,stroke-width:3px
    style A2A fill:#b197fc,stroke:#7048e8,color:#fff
    style ACP fill:#b197fc,stroke:#7048e8,color:#fff
    style ANP fill:#b197fc,stroke:#7048e8,color:#fff
    style AG1 fill:#51cf66,stroke:#2b8a3e,color:#fff
    style AG2 fill:#51cf66,stroke:#2b8a3e,color:#fff
    style TOOL1 fill:#4dabf7,stroke:#1971c2,color:#fff
    style TOOL2 fill:#4dabf7,stroke:#1971c2,color:#fff
    style TOOL3 fill:#4dabf7,stroke:#1971c2,color:#fff

L'IA générative confère aux applications des capacités remarquables : interroger une base de données, analyser un calendrier, produire du code. Historiquement, chaque capacité exigeait une intégration sur mesure, étroitement couplée au code de l'application principale. L'ajout de chaque nouveau modèle ou de chaque nouvel outil multipliait les connecteurs à développer et à maintenir.

Le MCP introduit une couche intermédiaire standardisée qui transforme cette complexité exponentielle en une équation linéaire. L'architecture passe de M×N connecteurs à M+N : les développeurs d'applications implémentent le client MCP une seule fois, les créateurs d'outils développent leur serveur MCP une seule fois. L'ensemble fonctionne immédiatement.

Le MCP est souvent comparé à un "USB-C de l'IA" — un connecteur universel qui permet à n'importe quel LLM de découvrir et d'utiliser instantanément n'importe quel outil, sans adaptateur propriétaire.

Jusqu'à récemment, les outils développés pour les agents IA restaient enfermés dans des silos : spécifiques à un environnement, difficiles à réutiliser, impossibles à distribuer largement.

Le MCP change la donne en introduisant le principe de l'agent découplé. L'interface de communication étant unifiée, les intégrations sont physiquement séparées du code de l'agent. Celui-ci se concentre sur son rôle cognitif — raisonnement et prise de décision — tandis que les serveurs MCP assument l'accès aux capacités externes et la manipulation des données.

Ce découplage produit un effet multiplicateur considérable. N'importe quel développeur peut rendre ses données ou ses API "compatibles IA" en publiant un simple serveur MCP. Au sein d'une grande organisation, les équipes créent et maintiennent leurs propres serveurs en parallèle, faisant émerger un véritable marché d'outils interne qui standardise les ressources à l'échelle de l'entreprise.

Un bénéfice souvent sous-estimé : le développeur d'une application connectée à MCP n'a plus à maintenir à jour les descriptions des APIs qu'il consomme. Cette responsabilité incombe désormais au fournisseur du serveur MCP, qui connaît le mieux son propre service. Lorsqu'une API évolue — nouveaux paramètres, endpoints dépréciés, changements de format — c'est le mainteneur du serveur MCP qui met à jour les descriptions d'outils. Les applications clientes en bénéficient automatiquement, sans modification de leur côté.

Le MCP repose sur le standard de messagerie JSON-RPC 2.0 et exige une communication bidirectionnelle robuste. Un serveur MCP ne se limite pas à publier une liste d'outils de manière passive : il reçoit des instructions d'exécution du LLM et peut, en retour, émettre des requêtes ou des notifications de mise à jour vers l'application hôte.

Pour gérer la mécanique fine de ces échanges — maintien de connexion, routage des messages, gestion des erreurs — le protocole s'appuie sur deux couches de transport standardisées :

• Standard I/O (stdio) — pour la communication locale, lorsqu'un serveur MCP s'exécute en tant que processus enfant sur la même machine que l'application hôte (typiquement, un outil intégré à votre IDE).

• Streamable HTTP — le standard recommandé pour les communications distantes. Contrairement à l'ancien transport HTTP+SSE qu'il remplace, ce transport repose sur un point d'entrée HTTP unique (par exemple https://example.com/mcp), qui accepte à la fois les requêtes GET et POST — il n'y a plus de chemin séparé pour le flux SSE. Le client envoie ses messages via POST sur cet endpoint. Le serveur répond soit par un objet JSON unique, soit en ouvrant un flux Server-Sent Events (SSE) sur cette même requête s'il a besoin d'émettre plusieurs messages ou des notifications avant la réponse finale. Le client peut également ouvrir une requête GET persistante sur ce même point d'entrée pour recevoir des messages spontanés du serveur (notifications server-initiated, par exemple notifications/tools/list_changed), sans attendre une requête préalable. Pour gérer des sessions avec état, le serveur peut attribuer un identifiant de session via l'en-tête MCP-Session-Id lors de l'initialisation ; le client le renvoie ensuite sur chaque requête suivante. Un en-tête MCP-Protocol-Version précise par ailleurs la version du protocole négociée, et un mécanisme de reprise basé sur Last-Event-ID permet de relancer un flux interrompu sans perte de message. Ce schéma garantit une communication bidirectionnelle robuste, sans la complexité des WebSockets, tout en restant compatible avec l'infrastructure HTTP classique (load balancers, proxys, CDN). Côté sécurité, la spécification est explicite : un serveur Streamable HTTP doit valider l'en-tête Origin sur chaque connexion pour se prémunir des attaques de DNS rebinding, et devrait se limiter à l'interface localhost lors d'une exécution en local plutôt que d'écouter sur toutes les interfaces réseau.

Flux de communication type entre un hôte et un serveur MCP :

sequenceDiagram
    participant U as utilisateur
    participant H as hôte (IDE / App)
    participant C as client MCP
    participant S as serveur MCP

    Note over C,S: Initialisation de la connexion
    C->>S: initialize (version, capabilities)
    S-->>C: initialize response (capabilities)
    C->>S: mcp/discover
    S-->>C: Liste des outils, ressources, prompts
    C-->>H: Transmet les capacités disponibles

    Note over U,S: Requête utilisateur
    U->>H: "Exécute la requête SQL ..."
    H->>H: Le LLM raisonne et sélectionne l'outil
    H->>U: Demande de validation (Human-in-the-Loop)
    U-->>H: Approuvé
    H->>C: Appel tool/execute (requête SQL)
    C->>S: JSON-RPC 2.0 → tool/execute
    S->>S: Exécution isolée de la logique métier
    S-->>C: Résultat formaté (ou erreur)
    C-->>H: Résultat désérialisé
    H-->>U: Réponse finale enrichie

L'hôte est l'application utilisateur au sein de laquelle l'IA opère. Un IDE dopé à l'intelligence artificielle (Cursor, Windsurf), une application conversationnelle (Claude Desktop), un terminal intelligent (Warp, Gemini CLI) : tous assument ce rôle. Bien qu'il ne figure pas dans la spécification stricte du protocole, l'hôte est l'environnement sans lequel rien ne fonctionne.

Ses responsabilités sont doubles et critiques :

• Gestion de l'expérience et de l'état — L'hôte pilote l'interface, conserve l'historique complet de la conversation et restitue les réponses finales de l'IA à l'utilisateur.

• Gouvernance et sécurité — C'est la fonction la plus déterminante. L'hôte est le gardien ultime des capacités de l'agent. Il contrôle les ressources accessibles selon le contexte (par exemple, restreindre l'accès au seul répertoire du projet en cours) et impose la validation humaine (Human-in-the-loop). Avant toute action irréversible — suppression de fichier, modification d'une base de données — il intercepte la requête et exige l'approbation explicite de l'utilisateur.

Note : Pour renforcer cette gouvernance sans alourdir l'expérience utilisateur avec des validations constantes, l'hôte peut s'appuyer sur des mécanismes de sandboxing système. L'idée est de définir une fois pour toutes un périmètre d'exécution autorisé — répertoires accessibles, binaires exécutables, appels réseau tolérés — et de laisser l'agent opérer librement à l'intérieur de ce périmètre, sans interruption.

Des outils comme OpenShell illustrent cette approche : ils s'intercalent entre l'agent et le système d'exploitation pour intercepter et filtrer finement les appels aux binaires et les accès au système de fichiers, indépendamment du modèle d'IA utilisé. Dans la pratique, cela revient à appliquer le principe du moindre privilège à l'agent : il ne peut exécuter que ce qui lui a explicitement été accordé, quelles que soient les instructions qu'il reçoit.

Cette approche complète (et ne remplace pas) le Human-in-the-loop : là où la validation humaine s'applique aux actions à fort impact et peu fréquentes, le sandboxing couvre le flux continu d'opérations courantes de manière transparente.

Le client MCP est le rouage invisible qui rend la communication possible. Intégré au sein de l'hôte, chaque instance gère la relation technique avec un serveur MCP spécifique (un client par Serveur connecté).

Trois fonctions définissent son périmètre :

• Gestion du cycle de vie — Le client initialise la connexion, sélectionne le transport approprié (local ou distant) et gère proprement la fermeture de session ou les erreurs réseau.
• Traduction protocolaire — Il convertit automatiquement les objets natifs de l'application hôte en messages JSON-RPC 2.0 conformes au MCP, et inversement. Les développeurs n'ont jamais à manipuler le protocole directement.

• Découverte dynamique — Dès la connexion établie, le client interroge le serveur (via mcp/discover) pour récupérer l'intégralité de ses capacités — outils, ressources, prompts — et les transmettre à l'hôte. C'est ce mécanisme qui permet aux agents de découvrir de nouvelles compétences à la volée, sans configuration manuelle.

Le serveur est le composant qui détient la capacité technique réelle. C'est une enveloppe (wrapper) autour d'une fonctionnalité spécifique — base de données SQLite, API d'entreprise, système de fichiers, service SaaS — exposée au monde extérieur via l'interface standardisée du MCP.

Trois caractéristiques le distinguent :

• Modularité extrême — Un serveur MCP peut prendre des formes très diverses : un script Python de 20 lignes s'exécutant localement, un microservice déployé sur un cluster Kubernetes, ou une API publique proposée par GitHub ou Slack. La barrière d'entrée est volontairement basse.
• Exposition déclarative — Le serveur écoute passivement les requêtes de clients autorisés. Lorsqu'il est interrogé, il annonce ses compétences via des descriptions textuelles détaillées, conçues pour guider le raisonnement du LLM dans sa sélection d'outils.

• Exécution isolée — À la réception d'un ordre valide (exécuter une requête SQL, par exemple), le serveur décode la demande, exécute sa logique métier de manière autonome, puis renvoie un résultat formaté — ou une erreur explicite — au client. Il n'a à aucun moment besoin de connaître le modèle d'IA à l'origine de la requête. Cette isolation est une garantie architecturale de portabilité et de sécurité.

Les outils incarnent la capacité d'agir. Ce sont des fonctions exécutables — rechercher sur le web, lancer une requête SQL, déclencher un déploiement — que le serveur MCP met à disposition de l'IA.

Leur fonctionnement repose sur un mécanisme déclaratif : le serveur publie la liste exhaustive de ses outils, accompagnée de descriptions textuelles suffisamment précises pour guider le raisonnement du LLM. Le modèle d'IA analyse ensuite cette liste et décide, de sa propre initiative, s'il est pertinent d'invoquer un outil pour répondre à la requête de l'utilisateur.

C'est cette autonomie de sélection qui confère à l'agent sa dimension véritablement agentique. Le LLM ne se contente pas de répondre : il agit.

Exemple concret de déclaration d'un outil : Voici comment le serveur transmet les capacités d'une fonction get_weather au LLM via le Modèle de contexte. Vous remarquerez que le schéma JSON (les arguments et la description) sert de véritable "mode d'emploi" lu par le modèle d'IA pour savoir quand et comment utiliser cet outil :

{
  "name": "get_weather",
  "description": "Obtient la météo locale complète pour une localisation donnée.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "Le nom de la ville (ex: 'Paris', 'Brest')"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "L'unité de température désirée (celsius par défaut)"
      }
    },
    "required": ["city"]
  }
}

Les ressources représentent les données brutes en lecture seule : fichiers texte, documents PDF, schémas de base de données, extraits de code source. Elles constituent le socle factuel sur lequel l'IA construit son raisonnement.

L'Application hôte peut injecter ces données dans le contexte du LLM, ou un Outil peut s'en servir comme matière première pour ses opérations. Mais le point critique réside dans le contrôle d'accès : c'est l'application hôte — et elle seule — qui détermine quelles ressources sont accessibles. Un IDE restreindra l'accès au seul répertoire du projet ouvert ; une interface conversationnelle limitera les documents consultables à ceux explicitement partagés par l'utilisateur.

Le principe est limpide : aucune IA ne doit pouvoir décider unilatéralement d'explorer l'intégralité d'un système de fichiers. L'Hôte garantit un périmètre de données strictement borné.

Les Invites sont des modèles de conversation pré-configurés par le Serveur MCP. Elles définissent un comportement, un format de réponse ou un persona spécifique pour une tâche donnée — par exemple, "agis comme un Principal Engineer pour la relecture de ce code" ou "Produit une analyse de vulnérabilité au format SARIF".

Leur rôle est de standardiser l'interaction entre l'IA et un service spécifique, garantissant des requêtes optimisées et des réponses structurées. Contrairement aux outils, le LLM ne choisit jamais d'activer une Invite de lui-même. C'est l'Utilisateur qui la sélectionne délibérément via l'interface de l'hôte (menu déroulant, commande slash, raccourci clavier), conservant ainsi un contrôle explicite sur la posture adoptée par l'IA.

Synthèse du modèle de contrôle :

graph LR
    subgraph "Capacité"
        T["Outils\n(Actions)"]
        R["Ressources\n(Données)"]
        P["Invites\n(Comportements)"]
    end

    subgraph "Contrôleur"
        M["Modèle (LLM)"]
        A["Application (Hôte)"]
        U["Utilisateur"]
    end

    M -->|"décide d'invoquer"| T
    A -->|"détermine l'accès"| R
    U -->|"sélectionne explicitement"| P

    style T fill:#ff8787,stroke:#c92a2a,color:#fff
    style R fill:#4dabf7,stroke:#1971c2,color:#fff
    style P fill:#51cf66,stroke:#2b8a3e,color:#fff
    style M fill:#ff8787,stroke:#c92a2a,color:#fff
    style A fill:#4dabf7,stroke:#1971c2,color:#fff
    style U fill:#51cf66,stroke:#2b8a3e,color:#fff

Cette ségrégation tripartite du contrôle constitue l'un des choix architecturaux les plus déterminants du MCP. En distribuant l'autorité entre trois acteurs distincts, le protocole empêche tout composant unique — y compris le LLM lui-même — de concentrer un pouvoir d'action incontrôlé.