Protocole de contexte du modèle (MCP), et notes sur la mise en œuvre d'un serveur MCP en Go

Longue lecture sur les spécifications et l'implémentation de MCP en GO

Sommaire

Ici, nous avons une description du Model Context Protocol (MCP), des notes brèves sur la manière d’implémenter un serveur MCP en Go, comprenant la structure des messages et les spécifications du protocole.

Robots et MCP

Aperçu du Model Context Protocol (MCP)

Le Model Context Protocol (MCP) est un cadre ouvert et normalisé (introduit par Anthropic à la fin de 2024) pour connecter les modèles de langage artificiels à des sources de données externes, des outils et des systèmes. Son objectif est de résoudre le problème de « N×M intégration » en fournissant une interface universelle pour des choses comme la lecture de fichiers, l’exécution de fonctions (outils) et l’utilisation de prompts contextuels dans différentes applications. L’MCP n’est pas un protocole propriétaire ou interne ; c’est un standard ouvert avec une spécification officielle et une implémentation de référence open source. En fait, les principaux fournisseurs d’IA (y compris OpenAI et Google DeepMind) ont annoncé leur soutien à l’MCP après son introduction, soulignant qu’il est conçu comme un standard largement adopté plutôt qu’une solution spécifique à un vendeur.

Objectif et architecture de l’MCP

L’MCP vise à standardiser la manière dont les applications fournissent un contexte aux LLMs – l’analogie souvent utilisée est « un port USB-C pour les applications d’IA ». En définissant un protocole commun, l’MCP permet aux assistants et outils d’IA d’interfacer sans problème avec des bases de données, des systèmes de fichiers, des API et d’autres ressources, sans intégrations personnalisées. Cela aide les modèles de langage à générer des réponses plus pertinentes et à jour en leur donnant un accès sécurisé aux données dont ils ont besoin.

Architecture : L’MCP suit un modèle client-serveur avec une séparation claire des rôles :

  • Hôte MCP : L’application parente (par exemple, un client de chat ou un IDE) qui gère les connexions. Elle contient un ou plusieurs clients MCP (connecteurs).
  • Client MCP : Une instance de connecteur (dans l’hôte) qui établit une session 1:1 avec un serveur MCP. Le client gère le cycle de vie de la session, route les messages et applique toute permission utilisateur ou politique de sécurité.
  • Serveur MCP : Un service léger qui expose des capacités spécifiques (accès à certains données ou fonctions) via le protocole MCP. Chaque serveur peut envelopper une source de données (fichiers, base de données, API, etc.) ou un outil. Plusieurs serveurs peuvent fonctionner en parallèle, chacun fournissant différentes intégrations.
  • Sources de données/services : Les ressources réelles avec lesquelles les serveurs interagissent – cela peut inclure des fichiers locaux et des bases de données ou des services distants (API web, applications SaaS, etc.). Le serveur MCP agit en tant qu’adaptateur pour ces ressources, assurant que le LLM n’accède aux données qu’à travers le protocole normalisé.

Cette conception est inspirée par le Language Server Protocol (LSP) du monde des IDE. Tout comme LSP permet à tout éditeur de supporter tout langage de programmation via un protocole commun, l’MCP permet à toute application d’IA de se connecter à toute intégration de données/outils qui parle de l’MCP. Cette découplage signifie que les développeurs d’outils d’IA peuvent écrire un serveur MCP une seule fois et qu’il fonctionnera avec de nombreux clients d’IA, et que les développeurs d’applications d’IA peuvent ajouter de nouvelles intégrations simplement en branchant un serveur MCP, évitant ainsi le code d’intégration personnalisé.

Protocole et structure des messages

Communication : La communication MCP est basée sur des sessions persistantes et étatiques utilisant des messages JSON-RPC 2.0. Toutes les demandes et réponses respectent le format JSON-RPC (avec un champ "jsonrpc": "2.0", des noms de méthodes, des paramètres et des ID correspondants). Soit le côté client, soit le côté serveur peut envoyer des demandes ou des notifications, permettant une interaction bidirectionnelle. Une session MCP commence généralement avec une poignée de main :

  • Le client commence avec une demande initialize, proposant une version du protocole et annonçant ses capacités (les fonctionnalités qu’il prend en charge). Par exemple, le client pourrait indiquer qu’il peut gérer des demandes de « sampling » dirigées par le serveur ou fournir certains points d’accès pour l’accès aux fichiers. Le serveur répond avec sa propre version du protocole prise en charge et ses capacités, finalisant les fonctionnalités activées pour cette session (l’MCP utilise un système de négociation des capacités similaire aux fonctionnalités optionnelles de LSP). Si des capacités critiques ou une version sont incompatibles, la connexion est arrêtée de manière gracieuse.
  • Après l’accord, le client envoie une notification initialized pour marquer sa disponibilité. Après cela, les opérations normales peuvent commencer. La session reste ouverte pour un échange continu de messages JSON-RPC jusqu’à ce qu’un côté émette une fermeture.

Transports : L’MCP ne stipule pas un seul transport – il fonctionne sur tout canal capable de transporter du texte JSON. En général, un serveur MCP est exécuté comme un sous-processus et communique via STDIO (tuyaux d’entrée/sortie standard) pour les intégrations locales. Cela est analogue à la manière dont les serveurs de langage fonctionnent et est pratique pour les outils locaux (l’hôte peut lancer le processus du serveur et envoyer des messages via les tuyaux). En alternative, les serveurs MCP peuvent fonctionner comme des services indépendants accessibles via HTTP. La spécification MCP définit un transport HTTP en flux où le serveur expose un seul point de terminaison HTTP pour les appels JSON-RPC (les clients POST des requêtes, et le serveur peut répondre ou envoyer des résultats via les événements envoyés par le serveur pour les opérations longues). Dans les deux cas, les messages sont des lignes JSON UTF-8, et le protocole prend en charge les réponses en flux et les messages initiés par le serveur (l’approche HTTP + SSE permet au serveur de pousser des notifications ou des résultats partiels de manière asynchrone). Les lignes directrices de sécurité recommandent que les serveurs locaux se lient à localhost et valident les en-têtes Origin pour empêcher l’accès distant non souhaité, et que l’authentification appropriée (par exemple, des jetons ou des flux OAuth) soit utilisée pour les serveurs distants.

Format du message : L’MCP utilise les trois types de messages de JSON-RPC : Demandes, Réponses et Notifications. Une demande contient un id, une chaîne method et (facultativement) params (généralement un objet JSON d’arguments). Le récepteur doit répondre avec une réponse correspondante (avec un id correspondant) contenant soit un result soit un objet error. Les notifications sont comme des messages unidirectionnels avec une method et des params mais sans id (donc elles ne reçoivent pas de réponse). L’MCP impose quelques règles supplémentaires au-dessus de JSON-RPC de base (par exemple, id doit être non nul et ne pas être réutilisé pendant une session) pour maintenir la clarté.

Session et état : La connexion est considérée comme étatique – le client et le serveur maintiennent un contexte sur les capacités de l’autre et éventuellement certains états de session (comme les abonnements aux changements, les opérations en cours, etc.). Il existe également des procédures définies pour une fermeture gracieuse (par exemple, un client peut envoyer une demande de fermeture ou simplement fermer le transport ; les serveurs doivent gérer la nettoyage, et les deux côtés implémentent des délais pour les opérations en attente). Le traitement des erreurs suit les conventions JSON-RPC (les réponses d’erreur ont un code et un message) et la spécification définit des codes d’erreur standard pour certaines conditions (par exemple, accès refusé, outil non trouvé, etc.). L’MCP fournit également des outils pour des préoccupations transversales : par exemple, il existe des notifications intégrées pour les mises à jour de progression, l’annulation d’une demande longue (CancelledNotification), les messages de journalisation/débogage et les changements de configuration. Ces outils aident à gérer les interactions longues ou complexes (le client peut annuler une appel d’outil en cours, ou le serveur peut envoyer des avertissements au client, etc.).

Fonctionnalités et opérations de l’MCP

Une fois initialisé, une session MCP permet l’échange structuré de contexte et de commandes. Les fonctionnalités principales du côté serveur de l’MCP sont Prompts, Resources et Tools (chaque serveur déclare s’il prend en charge ces fonctionnalités pendant l’initialisation) :

  • Prompts : Modèles de prompt ou instructions prédéfinis que le serveur peut fournir au client. Ces sont généralement des assistants déclenchés par l’utilisateur (l’utilisateur choisit explicitement un prompt à insérer dans la conversation, par exemple via une commande slash dans l’interface utilisateur). L’MCP fournit des méthodes pour lister les prompts disponibles et récupérer le contenu d’un prompt. Par exemple, un client peut appeler prompts/list pour obtenir une liste de modèles de prompt (chaque modèle ayant un nom, une description et des paramètres optionnels). Pour récupérer un prompt, le client utilise prompts/get avec le nom du prompt et toute valeur d’argument ; le serveur renvoie alors le contenu du prompt (souvent sous forme d’un ensemble de messages que le client injectera dans le contexte de l’LLM). Les prompts permettent de réutiliser des instructions ou workflows complexes (par exemple, « modèle de revue de code ») que l’utilisateur peut invoquer sur demande. Les serveurs indiquent une capacité prompts (avec des sous-fonctionnalités optionnelles comme listChanged pour informer le client si l’ensemble des prompts change dynamiquement).

  • Resources : Données structurées ou contenu qui fournissent un contexte au modèle. Les ressources sont généralement des choses comme des fichiers, des documents, des entrées de base de données – des informations que l’assistant IA pourrait lire ou référencer. L’MCP normalise la manière dont les ressources sont identifiées et transférées : chaque ressource a un identifiant URI (par exemple, file:///path/to/file.txt ou un schéma personnalisé pour les bases de données). Les clients peuvent interroger les ressources disponibles via resources/list (le serveur peut exposer un arbre de répertoires, une liste de documents récents, etc.). La réponse du serveur inclut des métadonnées pour chaque ressource (URI, nom, type, description, etc.). Ensuite, le client peut demander le contenu d’une ressource spécifique avec resources/read, en passant l’URI. Le serveur répond avec le contenu de la ressource, qui pourrait être du texte (pour les fichiers), ou des données structurées (l’MCP prend en charge différents types de contenu, comme le texte, le JSON, le binaire, etc., avec des types MIME). Il y a également un support pour les modèles de ressources (des ressources paramétrées identifiées par des URI de modèle, que le client peut remplir, par exemple une requête de base de données où l’utilisateur fournit un paramètre). Si activé, les serveurs peuvent envoyer des notifications lorsqu’une ressource change (par exemple, notifications/resources/updated) ou permettre aux clients de s’abonner aux changements sur une ressource (resources/subscribe). Dans la conception de l’MCP, les ressources sont contrôlées par l’application : l’application hôte (client) décide généralement quel contenu de ressource fournir réellement au prompt du modèle (souvent après confirmation utilisateur ou en fonction du contexte de l’interface utilisateur).

  • Tools : Fonctions exécutables ou actions que le serveur expose pour que le modèle les invoque. Les outils représentent des opérations que l’IA peut effectuer – par exemple, appeler une API externe, exécuter une requête de base de données, envoyer un e-mail ou modifier un fichier. Chaque outil a un nom et un schéma JSON pour ses paramètres d’entrée (et éventuellement de sortie), donc l’IA (ou le client) sait quelles arguments elle attend. Les outils sont généralement contrôlés par le modèle : l’idée est que le modèle de langage (agent) décide si et quand utiliser un outil pendant une conversation pour remplir la demande de l’utilisateur. Cependant, pour la sécurité, un utilisateur humain ou l’application hôte peut médier l’utilisation de l’outil (par exemple, exiger un clic de confirmation). L’utilisation d’outils dans l’MCP implique deux opérations principales : lister et appeler. Un client peut appeler tools/list pour obtenir les outils disponibles et leurs schémas. Par exemple, un serveur pourrait lister un outil get_weather avec une description et un schéma d’entrée qui exige une chaîne “location”. Ensuite, lorsque le modèle décide d’utiliser un outil (ou l’utilisateur l’active), le client envoie une demande tools/call avec le nom de l’outil et un objet JSON d’arguments. Le serveur exécute la fonction et renvoie le résultat, généralement sous forme de champ result.content qui peut contenir du texte ou des données structurées (l’MCP prend en charge le retour de plusieurs parties de contenu, par exemple du texte plus une image, etc., bien que le texte soit courant). Un exemple simple : appeler un outil get_weather pourrait renvoyer une charge utile de texte comme « Météo actuelle à New York : 72°F, partiellement nuageux » comme contenu pour l’assistant à présenter. Les outils peuvent également indiquer des erreurs (la réponse a un drapeau isError ou un objet d’erreur si quelque chose s’est mal passé). Comme pour les prompts et les ressources, la capacité tools peut avoir un drapeau optionnel listChanged pour informer lorsqu’un outil disponible change en cours d’exécution (par exemple, un plugin dynamique chargé/déchargé).

En plus des fonctionnalités ci-dessus offertes par le serveur, l’MCP définit également des fonctionnalités offertes par le client (capacités que les serveurs peuvent utiliser si le client les prend en charge). Ces incluent Sampling, Roots et Elicitation :

  • Sampling permet au serveur de demander au client (et à son LLM) d’effectuer une inférence de modèle dans la session. Par exemple, un serveur pourrait initier un appel LLM (peut-être pour continuer une chaîne de pensée ou pour résumer quelque chose) en envoyant une demande comme sampling/request – le client promouvoirait alors le modèle et renverrait le résultat. Cela permet des comportements agents où le serveur peut diriger l’IA pour aider à ses propres sous-tâches. (Toutes ces actions sont soumises à l’approbation de l’utilisateur et aux politiques – par exemple, un utilisateur pourrait avoir à s’inscrire pour permettre à un serveur de déclencher le modèle pour des requêtes supplémentaires.)

  • Roots permet au serveur d’enquêter ou d’opérer dans certains répertoires ou URI racines autorisés. Le client peut fournir une liste de « racines » de répertoires/URI que le serveur est autorisé à accéder, via roots/list. C’est une fonction de sécurité assurant que le serveur connaît les limites (par exemple, quels arbres de dossiers il peut lire).

  • Elicitation permet au serveur de demander au client d’obtenir plus d’informations de l’utilisateur si nécessaire. Par exemple, si un outil a besoin d’une information manquante qui n’a pas été fournie, le serveur peut envoyer une demande d’élaboration, que le client (interface utilisateur) traduirait en une invite utilisateur (« L’intégration X nécessite votre clé API, veuillez l’entrer »). Ainsi, le serveur peut collecter des entrées interactivement via le client.

Ces fonctionnalités sont toutes optionnelles et négociées à l’avance. Un aspect clé de la conception de l’MCP est que la négociation des capacités se produit pendant l’initialisation – le client et le serveur annoncent les fonctionnalités qu’ils prennent en charge, donc les deux côtés savent quelles opérations sont disponibles dans la session. Par exemple, si un serveur ne déclare pas la capacité tools, le client ne tentera pas d’effectuer aucune opération tools/list ou tools/call avec lui. Cette extensibilité signifie que l’MCP peut évoluer avec de nouvelles fonctionnalités au fil du temps tout en maintenant la compatibilité descendante (les méthodes non prises en charge ne seront simplement pas utilisées si elles ne sont pas négociées).

Implémentations, SDK et création d’un serveur MCP (notamment en Go)

Spécification officielle et documentation : La spécification MCP officielle est disponible publiquement, y compris un schéma formel de tous les types de messages. Elle est maintenue sur le site du Model Context Protocol et GitHub. La spécification est définie dans un fichier de schéma TypeScript (avec un schéma JSON correspondant) qui documente précisément toutes les demandes, réponses et structures. Le site de documentation (modelcontextprotocol.io) fournit des guides, un FAQ et des explications détaillées de chaque fonctionnalité et type de message, ainsi qu’un outil « MCP Inspector » pour le débogage interactif. Bien que l’MCP ne soit pas (encore) un standard IETF ou ISO, il est développé comme un standard ouvert avec des contributions de la communauté et utilise des termes familiers de RFC 2119 pour les exigences. C’est un protocole en évolution (les versions sont datées ; par exemple, 2025-06-18 est une révision récente), avec une politique de versionnage pour gérer les changements.

Implémentations de référence : Anthropic a open-sourcé plusieurs connecteurs de serveur MCP et SDK lors de l’introduction de l’MCP. Il existe une organisation GitHub modelcontextprotocol qui héberge la spécification et plusieurs dépôts. Notamment, un dépôt « servers » contient une collection d’implémentations de serveurs MCP prêtes à l’emploi pour des services et sources de données courantes. Ces servent d’intégrations de référence et peuvent souvent être utilisées directement ou comme modèles pour des serveurs personnalisés. Par exemple, le dépôt officiel inclut des serveurs pour Google Drive (accès et recherche de fichiers dans Google Drive), Slack (messagerie et contenu de canaux de l’entreprise), GitHub/Git (contexte de dépôt de code), PostgreSQL (requêtes de base de données en lecture seule avec des informations de schéma), Google Maps (API de localisation et de directions), Puppeteer (navigation web et scraping), et bien d’autres. En installant ou en exécutant ces serveurs, une application IA comme Claude ou Cursor peut immédiatement obtenir cette intégration. Il existe également un service de registre MCP communautaire (open-source en Go) pour indexer les serveurs disponibles, et de nombreuses contributions tierces qui étendent l’MCP à divers domaines (depuis les CRM jusqu’aux données blockchain).

SDK et bibliothèques : Pour faciliter la création de vos propres serveurs/clients MCP, il existe des SDK officiels dans plusieurs langages. En 2025, le projet fournit des SDK pour TypeScript/Node, Python, Java (et Kotlin), C# (développé avec Microsoft), Ruby (avec Shopify), Swift, et d’autres. Ces bibliothèques gèrent le « plumbing » du protocole – par exemple, la gestion du transport JSON-RPC, l’implémentation du schéma de spécification et la fourniture d’API d’aide pour enregistrer des outils ou servir des ressources. Par exemple, le SDK TypeScript peut être utilisé pour écrire rapidement un serveur en Node.js, et le SDK Python permet d’intégrer l’MCP dans des applications Python. L’approche SDK signifie que les développeurs n’ont pas à construire manuellement des messages JSON-RPC ou à implémenter l’ensemble de l’automate d’état ; au lieu de cela, ils appellent des méthodes de haut niveau pour envoyer des demandes ou publier des capacités.

Implémentation en Go : Go est devenu un choix populaire pour les serveurs MCP en raison de ses forces en matière de performance et de concurrence (bon pour gérer plusieurs demandes simultanées). Un SDK officiel en Go est désormais disponible, développé en collaboration avec l’équipe Go de Google. (Cela a été annoncé autour d’avril 2025 et la première version stable est prévue pour août 2025.) Le SDK Go fournit un package mcp pour créer des clients/serveurs et un assistant jsonschema pour les schémas d’outils. En utilisant le SDK Go, les développeurs peuvent créer un serveur MCP avec quelques appels. Par exemple, vous pouvez instancier un nouveau serveur avec un nom et une version, puis ajouter des outils via AddTool en fournissant une définition d’outil (nom, description, schéma d’entrée) ainsi qu’une fonction Go à exécuter lors de l’appel de cet outil. Le SDK s’occupe de rendre l’outil disponible dans le protocole (l’annonçant dans tools/list et gérant les demandes tools/call). De même, vous pouvez exposer des ressources ou des prompts avec des API analogues. Enfin, vous exécutez le serveur – par exemple, server.Run(ctx, mcp.NewStdioTransport()) démarre le traitement des messages JSON-RPC via stdio jusqu’à ce que le client se déconnecte. Du côté client, le SDK Go peut lancer un sous-processus et se connecter via mcp.NewCommandTransport(exec.Command("myserver")), puis le client peut appeler session.CallTool(ctx, params) pour invoquer un outil et obtenir facilement le résultat en code Go.

Exemple : La documentation officielle du SDK Go montre un serveur « greeter » simple. Le serveur enregistre un outil "greet" qui prend un nom et renvoie une chaîne de salutation. Le client appelle ensuite cet outil par son nom et affiche le résultat. Cela illustre le schéma de base : définir un outil -> le client appelle l’outil -> obtenir le résultat. En coulisses, cela correspond à des messages JSON-RPC ("method": "tools/call", params: {"name": "greet", ...} et la réponse contenant result.content avec du texte) comme définis par la spécification MCP.

Avant la sortie du SDK Go officiel, la communauté a créé ses propres bibliothèques Go. Notamment, le projet mcp-go d’Ed Zynda (mark3labs/mcp-go) a été largement utilisé et a influencé la conception du SDK officiel. Une autre bibliothèque, mcp-golang par Metoro, a fourni une implémentation Go et une API (le billet de blog de la communauté Dev d’Elton Minetto utilise cette bibliothèque à partir de début 2025). Ces SDKs de la communauté ont permis aux développeurs Go d’expérimenter avec l’MCP dès le début – par exemple, un tutoriel montre comment créer un serveur MCP qui recherche des codes postaux brésiliens (CEP) en exposant un outil « zipcode » via la bibliothèque mcp-golang de Metoro. Dans cet exemple, le serveur Go enregistre une fonction qui appelle une API externe pour trouver une adresse à partir d’un ZIP, et renvoie le résultat sous forme de texte – permettant à un assistant IA de récupérer des informations d’adresse sur demande via l’MCP. Un autre guide démontre l’encapsulation d’une base de données en mémoire personnalisée (DiceDB) en tant que serveur MCP à l’aide du SDK mcp-go de mark3labs : il définit un outil ping pour vérifier la connectivité de la base de données et d’autres outils pour les opérations de données. Ces exemples montrent à quel point il peut être facile de créer une intégration MCP : la plupart du code est simplement la logique métier (appels API, requêtes de base de données, etc.), tandis que le SDK gère le câblage JSON-RPC.

Construction d’un serveur MCP en Go (Points clés du tutoriel)

Pour décrire le processus, voici un flux typique en utilisant le Go SDK ou une bibliothèque similaire :

  1. Mettre en place le serveur : Initialisez une nouvelle instance de serveur avec des informations de base (nom, version et déclarez les capacités prises en charge). Par exemple, en Go : server := mcp.NewServer("MyServer", "1.0.0", nil) créera un serveur qui (par défaut) prend en charge les fonctionnalités du protocole de base. Vous pouvez activer des capacités spécifiques comme les prompts/ressources/outils via des options ou simplement en enregistrant ces fonctionnalités (l’ajout d’un outil ou d’une ressource implique cette capacité).

  2. Enregistrer les fonctionnalités : Ajoutez les fonctionnalités que vous souhaitez exposer :

    • Si vous exposez des outils, définissez le schéma de chaque outil et le gestionnaire. Par exemple, en utilisant AddTool du SDK Go : fournissez un mcp.Tool{Name: "...", Description: "..."} et une fonction de gestionnaire qui prend la demande d’appel et retourne un résultat (qui peut inclure du texte ou d’autres contenus). Le SDK générera automatiquement un schéma JSON pour les entrées à partir des types de paramètres de votre fonction de gestionnaire (ou vous pouvez le spécifier).
    • Si vous exposez des ressources, vous pouvez utiliser une API pour enregistrer les listes de ressources ou un rappel pour lire le contenu. Par exemple, dans le SDK Python, vous pouvez sous-classer un ResourceProvider ; en Go, le SDK évolue encore, mais vous fournirez probablement des fonctions pour lister et lire les ressources. Chaque ressource doit avoir une URI stable.
    • Si vous exposez des prompts, définissez des modèles de prompt (peuvent être des fichiers statiques ou des chaînes) et enregistrez-les avec des noms et des paramètres optionnels. Le serveur les annoncera afin que le client puisse les récupérer et les afficher aux utilisateurs.

  3. Implémenter le transport : Décidez de la manière dont le serveur fonctionnera. La plus simple pour une utilisation locale est le stdio – par exemple, server.Run(ctx, mcp.NewStdioTransport()) en Go démarre la lecture de JSON-RPC depuis l’entrée standard. Si votre serveur doit être réseau, vous pouvez implémenter un gestionnaire HTTP qui utilise le SDK Go pour accepter JSON-RPC via HTTP (le SDK Go officiel pourrait bientôt inclure un assistant pour le transport HTTP/SSE également).

  4. Test client : Vous pouvez tester le serveur avec un client compatible MCP. Par exemple, Anthropic’s Claude 2 (Claude pour le bureau) prend en charge le chargement de serveurs MCP locaux ; vous configureriez Claude pour lancer ou se connecter à votre binaire de serveur. Il existe également un outil CLI appelé mcp-cli et l’interface graphique MCP Inspector pour tester les serveurs sans client AI complet – ces outils envoient des requêtes MCP à votre serveur et affichent les résultats, aidant ainsi au débogage.

  5. Sécurité et autorisations : Lors de la construction d’un serveur, prenez en compte l’authentification et la portée. Pour les serveurs locaux, l’hôte pourrait le faire fonctionner avec certains privilèges du système d’exploitation ou fournir des clés API via l’environnement. Pour les serveurs distants, utilisez des en-têtes d’authentification ou des flux OAuth. MCP inclut une spécification d’autorisation pour les transports HTTP (le serveur peut exiger un jeton et le client peut l’envoyer). Assurez-vous toujours que le serveur n’accède qu’aux données autorisées par l’utilisateur (par exemple, respectez les répertoires racine fournis par le client et ne fuites pas les données ailleurs) – les lignes directrices MCP mettent l’accent sur le consentement de l’utilisateur, la confidentialité des données et la sécurité des outils comme des principes fondamentaux.

En résumé, MCP est un protocole formel mais flexible pour relier les LLM avec le monde extérieur. Il n’est pas un API interne lié à une seule entreprise, mais un standard ouvert avec une adoption croissante et une écosystème riche d’intégrations. Le protocole définit des structures de message claires (basées sur JSON-RPC) et un ensemble d’opérations (méthodes pour les prompts, outils, ressources, etc.) que tout client/serveur conforme peut implémenter. La documentation officielle et les spécifications sont disponibles, et de nombreux SDK, bibliothèques et serveurs d’exemples (y compris en Go) facilitent son implémentation. En utilisant MCP, les développeurs peuvent créer des applications IA qui exploitent en toute sécurité les données et services existants, sans devoir réinventer la logique d’intégration pour chaque nouveau modèle ou ensemble de données.

Liens utiles