Qu’est-ce qu’un serveur MCP ? Comment fonctionnent MCP et MCP UI en 2026

Le 1er avril 2025, Invariant Labs a publié un outil appelé add. Il prenait deux nombres et renvoyait leur somme. Sa description contenait aussi un bloc marqué IMPORTANT, invisible dans l’interface du client, qui demandait au modèle de lire ~/.cursor/mcp.json et ~/.ssh/id_rsa puis de faire sortir les deux fichiers par un paramètre inutilisé. Le modèle a obéi. L’utilisateur n’a vu qu’une addition.

Cette démonstration est la meilleure introduction aux serveurs MCP que je connaisse, parce qu’elle montre les deux moitiés à la fois. Le protocole a fonctionné exactement comme prévu : un client IA a découvert un outil, lu sa description et l’a appelé. Le modèle de confiance, lui, restait à construire.

Ce qu’est un serveur MCP

Un serveur MCP est un programme qui expose des outils, des données et des prompts aux applications d’IA via le Model Context Protocol (MCP). La documentation officielle définit MCP comme « un standard open source pour connecter les applications d’IA à des systèmes externes ». Un client IA comme Claude, ChatGPT, Visual Studio Code ou Cursor se connecte au serveur, lui demande ce qu’il propose et appelle ces capacités pour le compte de l’utilisateur.

Anthropic a annoncé MCP le 25 novembre 2024 avec six serveurs prêts à l’emploi : Google Drive, Slack, GitHub, Git, Postgres et Puppeteer. OpenAI l’a adopté en mars 2025. Google DeepMind a suivi en avril. En décembre 2025, Anthropic a confié le protocole à l’Agentic AI Foundation, un fonds dédié hébergé par la Linux Foundation et cofondé par Anthropic, Block et OpenAI.

Le problème résolu est celui de la multiplication. Avant MCP, chaque application d’IA souhaitant accéder à GitHub écrivait son propre connecteur, et chaque fournisseur développait une connexion par application d’IA. Dix modèles et dix outils pouvaient représenter cent intégrations. MCP ramène ce nombre à vingt : chaque client implémente le protocole une fois et chaque système expose un serveur.

Voyez-le comme le conteneur maritime des intégrations d’IA. Avant les conteneurs, chaque port chargeait chaque marchandise à la main, avec ses propres grues et ses propres équipes. Le conteneur a standardisé la boîte, si bien que n’importe quel navire, grue ou camion pouvait transporter n’importe quelle marchandise. Il n’a pas standardisé ce qu’on mettait dans la boîte, et il n’en a jamais inspecté le contenu. MCP passe le même marché. Gardez en tête la seconde moitié : elle revient dans la partie sur la sécurité.

Comment fonctionne un serveur MCP

La spécification actuelle, version 2026-07-28, utilise des messages JSON-RPC 2.0 entre trois rôles. Sa propre description tient en trois lignes : les hôtes sont des « applications LLM qui initient les connexions », les clients sont des « connecteurs au sein de l’application hôte », et les serveurs sont des « services qui fournissent du contexte et des capacités ».

Hôte, client, serveur

L’hôte est l’application dans laquelle vous tapez : Claude Desktop, un IDE, votre propre agent. À l’intérieur, un client tourne pour chaque connexion à un serveur. Le serveur se trouve de l’autre côté et parle au vrai système, qu’il s’agisse d’une base Postgres, de l’API GitHub ou d’un dossier sur votre disque. L’hôte décide de ce que le modèle voit et de ce que l’utilisateur doit approuver. Le serveur décide de ce que le système sous-jacent va faire.

1. Hôte Claude Desktop · un IDE · votre propre agent

   montre les outils au modèle, demande le consentement de l’utilisateur

2. Client un par connexion serveur

   parle JSON-RPC via stdio ou Streamable HTTP

3. Serveur MCP outils · ressources · prompts

   décrit ce qu’il propose et exécute les appels

4. Système sous-jacent base de données · API SaaS · fichiers locaux

   fait le travail

Outils, ressources et prompts

Un serveur peut proposer trois types d’éléments :

• Les outils sont des fonctions que le modèle peut exécuter : create_issue, query_orders, send_email. Chacun a un nom, une description et un JSON Schema pour ses entrées.
• Les ressources sont du contexte et des données que l’utilisateur ou le modèle peut lire : un fichier, un schéma de base de données, un enregistrement.
• Les prompts sont des messages et des workflows préparés que l’utilisateur peut choisir, par exemple « Résumer cette pull request ».

Les outils attirent l’essentiel de l’attention parce qu’ils agissent. C’est aussi pour cela qu’ils concentrent l’essentiel du risque.

Un appel d’outil, étape par étape

La révision 2026-07-28 a rendu MCP sans état. Il n’y a plus de poignée de main initialize : chaque requête transporte sa version de protocole et les capacités du client dans un champ _meta, et les serveurs doivent implémenter une méthode server/discover pour qu’un client puisse demander d’emblée ce qu’ils prennent en charge. Un appel d’outil se déroule désormais ainsi :

1. Demande de l’utilisateur : créer un ticket pour ce bug

2. Étape 1

   Découverte

   • Le client peut appeler server/discover pour connaître versions et capacités
3. Étape 2

   Liste des outils

   • tools/list renvoie les noms, les descriptions et les schémas d’entrée
4. Étape 3

   Le modèle choisit un outil

   • L’hôte transmet les définitions d’outils au modèle
5. Étape 4

   Consentement de l’utilisateur

   • La spécification impose aux hôtes d’obtenir un consentement explicite avant d’invoquer un outil
6. Étape 5

   Appel

   • tools/call avec les arguments, version de protocole dans _meta

7. Entrée manquante ? Le serveur renvoie input_required ; le client relance avec les réponses

   Étape 6

   Résultat

8. Le résultat revient au modèle comme contexte

L’étape 6 est nouvelle dans cette révision. Un serveur qui a besoin d’informations supplémentaires n’envoie plus sa propre requête au client. Il renvoie un résultat marqué input_required, le client recueille la réponse, puis relance l’appel d’origine. La spécification appelle cela le schéma Multi Round-Trip Request.

Transports : stdio et Streamable HTTP

La spécification définit deux transports standard :

• stdio : le client lance le serveur comme sous-processus et échange du JSON-RPC délimité par des sauts de ligne sur l’entrée et la sortie standard. C’est ainsi que tournent la plupart des serveurs locaux, ce qui veut dire que le serveur s’exécute sur votre machine avec vos droits.
• Streamable HTTP : chaque message est un HTTP POST vers un point de terminaison unique, et les réponses reviennent sous forme d’objet JSON ou de flux d’événements limité à la requête. C’est ainsi que tournent les serveurs distants hébergés.

L’ancien transport HTTP+SSE est officiellement déprécié. La révision 2026-07-28 a aussi supprimé les sessions au niveau du protocole et l’en-tête Mcp-Session-Id : un serveur qui doit conserver un état entre plusieurs appels génère désormais son propre identifiant et le reçoit en retour comme un argument d’outil ordinaire.

Autorisation

L’autorisation est facultative dans MCP, et elle ne s’applique qu’à HTTP. Avec stdio, la spécification indique que les serveurs doivent plutôt récupérer leurs identifiants dans l’environnement. Avec HTTP, un serveur MCP protégé joue le rôle de serveur de ressources OAuth 2.1. Il doit publier ses métadonnées OAuth Protected Resource Metadata (RFC 9728) pour que les clients trouvent son serveur d’autorisation. Les clients doivent désigner précisément le serveur auquel un jeton est destiné (indicateurs de ressource RFC 8707). Les serveurs doivent rejeter tout jeton qui ne leur a pas été émis, et les recommandations de sécurité déclarent explicitement interdit le « token passthrough », c’est-à-dire le fait de transmettre tel quel le jeton d’un client à une API en aval.

Cette dernière règle compte plus qu’il n’y paraît. Un serveur qui relaie n’importe quel jeton reçu devient un proxy pour quiconque en détient un.

Ce qu’apporte MCP UI : des serveurs qui renvoient une interface

Les réponses textuelles cessent de fonctionner dès qu’un utilisateur doit comparer quarante lignes, ajuster un formulaire de douze champs ou approuver un lot de modifications une par une. « MCP UI » est le nom sous lequel les gens cherchent la solution : un serveur renvoie une interface interactive qui s’affiche dans le client IA, à côté de la conversation.

Le statut mérite d’être précisé. L’idée est née avec MCP-UI, un projet communautaire. OpenAI a conçu un mécanisme similaire dans son Apps SDK. Le projet MCP a proposé un standard commun avec ces deux initiatives le 21 novembre 2025, puis publié MCP Apps le 26 janvier 2026 comme première extension officielle de MCP. Les paquets MCP-UI implémentent désormais ce standard et restent un espace d’expérimentation pour de futures améliorations.

Aujourd’hui, MCP UI veut donc dire MCP Apps. C’est officiel, et c’est une extension, pas le cœur du protocole. Les extensions sont facultatives : le client et le serveur doivent tous deux les prendre en charge, et la documentation dit clairement que « la prise en charge par les hôtes varie selon le client ». La documentation de MCP Apps cite Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam et Archestra.AI comme hôtes compatibles. Un serveur dont les outils renvoient une interface doit tout de même fonctionner avec un client qui n’affiche que du texte.

Sur le plan mécanique, l’extension réutilise les briques de MCP :

1. La description d’un outil inclut un _meta.ui.resourceUri qui pointe vers une ressource ui://.
2. L’hôte récupère cette ressource, une page HTML avec ses scripts, et peut la précharger avant même l’appel de l’outil.
3. L’hôte l’affiche dans une iframe isolée (sandbox) qui ne peut lire ni la page parente, ni ses cookies, ni son stockage.
4. L’application et l’hôte communiquent via postMessage dans un dialecte JSON-RPC de MCP. L’application peut demander des appels d’outils, et l’hôte décide lesquels il autorise.

Le coût est réel. Vous livrez désormais un front-end web dans l’application de quelqu’un d’autre, avec une politique de sécurité du contenu à déclarer, des règles d’affichage que vous ne maîtrisez pas et une version texte de repli pour chaque hôte qui l’ignore. Le gain : le travail d’approbation n’est plus une transcription de chat. La liste des bons cas d’usage de la documentation se termine par « approuver des notes de frais, relire des modifications de code ou trier des tickets », et c’est là le cœur honnête du sujet : MCP UI excelle pour les décisions, pas pour la décoration.

Un exemple Tajo en lecture seule

L’interface Alto MCP de Tajo comprend query_contacts, qui recherche les contacts enregistrés dans l’espace connecté. Recherchez un contact existant par adresse e-mail et examinez son identifiant, son état de consentement e-mail et la date de sa dernière observation. L’outil distinct get_contact_topic_status lit ses abonnements thématiques.

Ces appels lisent les données de l’espace. Ils ne récupèrent pas un état actualisé chez le fournisseur, ne démarrent pas de synchronisation et n’envoient aucun message. Ils ne prouvent pas non plus que tous les connecteurs sont actifs. Recherchez à la source la cause de données manquantes ou anciennes. Un résultat vide ne prouve pas que la personne n’existe pas dans Brevo.

Utilisez la documentation MCP de Tajo pour connecter un client pris en charge et inspecter les outils réellement exposés à votre espace autorisé. Un panneau interactif facilite cette vérification lorsque l’hôte prend en charge MCP Apps. Le résultat textuel doit néanmoins expliquer ce qui s’est passé.

Un appel d’outil ne constitue pas une synchronisation durable

Une synchronisation récurrente exige aussi une planification, des identités stables, une progression enregistrée, des règles de nouvelle tentative et un journal des écritures terminées. Ces responsabilités appartiennent à l’application qui exécute le travail. MCP standardise l’accès aux outils ; leur présence dans une liste ne fournit pas ces règles métier.

Après un délai dépassé, une lecture peut généralement être répétée. Un envoi ou un paiement peut déjà avoir eu lieu. Conservez la trace d’exécution et rapprochez les résultats avant de réessayer. La confiance d’un modèle n’autorise pas l’action et ne rend pas sa répétition sûre.

Le guide de l’API Brevo détaille l’écriture de destination pour un parcours concret de contact. Le guide du reverse ETL explique quand des champs calculés justifient leur propre synchronisation maintenue.

La facture de sécurité arrive avec le protocole

L’objection mérite d’être formulée en entier : « MCP remet à un modèle probabiliste une liste de fonctions capables de supprimer des données et d’envoyer des e-mails, puis fait confiance à des textes écrits par des inconnus pour les décrire. Ce n’est pas un standard d’intégration. C’est une attaque de la chaîne d’approvisionnement avec une spécification. » L’essentiel est juste. La spécification en partage la prémisse. Sa section sécurité indique que les outils « représentent une exécution de code arbitraire et doivent être traités avec la prudence appropriée », que les descriptions d’outils « doivent être considérées comme non fiables, sauf si elles proviennent d’un serveur de confiance », et que MCP « ne peut pas faire respecter ces principes de sécurité au niveau du protocole ».

Voici le bilan à ce jour :

• Empoisonnement d’outils (tool poisoning). La divulgation d’Invariant Labs d’avril 2025, l’outil add évoqué plus haut. Le même article décrivait les rug pulls (le tapis tiré sous les pieds), où un serveur modifie la description d’un outil après votre approbation, et le shadowing (masquage), où un serveur malveillant réécrit le comportement du modèle vis-à-vis d’un serveur de confiance.
• Compromission de serveurs locaux. En juillet 2025, JFrog a divulgué CVE-2025-6514 dans mcp-remote, versions 0.0.5 à 0.1.15, qui permettait à un serveur malveillant d’exécuter des commandes sur la machine de l’utilisateur. Le même été, CVE-2025-49596 a touché le MCP Inspector d’Anthropic, livré par défaut sans authentification.
• Inflation des scopes. Les bonnes pratiques de sécurité officielles nomment le schéma : des jetons qui reçoivent files:* ou admin:* d’emblée, parce qu’un serveur listait tous les scopes et que le client les a tous demandés.
• Inquiétude officielle. En mai 2026, la National Security Agency américaine a déclaré que « la prolifération rapide » de MCP « a dépassé le développement de son modèle de sécurité ».

C’est sur la conclusion que l’objection se trompe. La solution n’a jamais été d’arrêter de connecter des modèles à des systèmes : les équipes le faisaient déjà, avec des clés d’API brutes collées dans des prompts et des scripts, sans aucune piste d’audit. La solution consiste à traiter un serveur MCP comme n’importe quelle autre dépendance privilégiée :

• N’installez des serveurs que depuis des sources à qui vous confieriez les mêmes identifiants en dehors de MCP.
• Préférez les serveurs distants avec OAuth et des scopes étroits aux binaires locaux qui détiennent des clés à longue durée de vie.
• Exigez une approbation humaine pour chaque écriture, et consignez qui a approuvé quoi.
• Figez les versions des serveurs, et relisez-les quand la description d’un outil change.
• Exposez des outils taillés pour la tâche, pas une API complète. Un modèle ne peut pas détourner un point de terminaison de suppression qui n’a jamais été exposé.

Le protocole a standardisé la boîte. Inspecter la cargaison reste votre travail.

Construire un serveur MCP ou en utiliser un existant

Des annuaires publics comme mcp.so recensent des serveurs créés par la communauté, et de nombreux éditeurs SaaS publient les leurs. Brevo, par exemple, propose un serveur MCP également découpé en serveurs individuels, si bien qu’un agent peut recevoir l’accès aux contacts sans les campagnes. La décision tient moins à l’effort qu’à la question de savoir à qui doit revenir la forme des outils.

Quel serveur MCP votre agent doit-il utiliser ?

1. L’éditeur publie un serveur qui couvre la tâche

   Utilisez le serveur de l’éditeur

   Il suit l’API et l’éditeur le maintient.

2. Un seul système, mais il vous faut moins d’actions ou des actions plus sûres

   Utilisez-le, en le restreignant

   Accordez des scopes minimaux et n’exposez que les groupes d’outils dont l’agent a besoin.

3. Des données internes ou un système sans serveur

   Construisez un petit serveur

   Quelques outils taillés pour la tâche au-dessus de votre propre API, avec votre propre authentification.

4. La tâche couvre deux systèmes ou plus

   Construisez ou adoptez une couche gouvernée

   Un seul jeu d’outils, de règles de consentement et d’historique d’audit pour tous les systèmes.

Construire un serveur de base est la partie facile. Avec un SDK officiel, un serveur stdio fonctionnel doté d’un outil représente un après-midi de travail. Le coût arrive plus tard : OAuth pour la version HTTP, les dépréciations (la révision 2026-07-28 a déprécié Roots, Sampling et Logging, ainsi que Dynamic Client Registration) et le travail permanent d’écrire des descriptions d’outils qu’un modèle lit correctement. Envelopper une API à raison d’un outil par point de terminaison est l’erreur la plus fréquente. Chaque description d’outil est un texte que le modèle doit lire et peser, donc une courte liste d’outils taillés pour la tâche vaut mieux que toute la surface de l’API.

MCP, API, intégrations et iPaaS

MCP ne remplace pas les API. Presque chaque serveur MCP enveloppe une API. C’est toujours l’API qui fait le travail, avec ses propres limites de débit, son modèle de données et ses bizarreries. MCP change qui peut l’appeler : un modèle, au moment de l’exécution, qui choisit l’appel à partir d’une description au lieu qu’un développeur le code en dur à l’avance.

Cette distinction trace une frontière nette avec les deux autres choses avec lesquelles on le confond :

• Les intégrations et l’iPaaS (les principales plateformes sont comparées ici) déplacent des données selon un calendrier ou un déclencheur, de façon déterministe, que quelqu’un soit en train de discuter ou non. Une synchronisation nocturne de 40 000 commandes vers un CRM ne devrait pas dépendre d’un modèle qui décide de faire 40 000 appels d’outils.
• Le reverse ETL renvoie des données modélisées depuis un entrepôt de données vers les outils opérationnels. Ce qu’est le reverse ETL et quand il convient est un sujet à part entière, et c’est un pipeline, pas une conversation.
• MCP sert aux moments où une personne ou un agent doit interroger, inspecter ou agir à travers ces systèmes, à la demande.

L’erreur se fait dans les deux sens. Des équipes construisent des serveurs MCP pour faire de la synchronisation en masse, et obtiennent des pipelines lents, coûteux et non reproductibles. D’autres construisent des intégrations soignées puis donnent à leur assistant IA une clé d’API brute pour les interroger, et obtiennent une porte dérobée sans gouvernance.

Pour une intégration prise en charge, le travail durable et les outils qui permettent de l’inspecter doivent partager une limite de permissions explicite. Vérifiez le connecteur, les actions autorisées et les résultats enregistrés pour le parcours concerné. La documentation des intégrations distingue les instructions de configuration des parcours restant à vérifier en production. MCP peut exposer des outils approuvés distincts ; leur présence ne prouve pas qu’une synchronisation récurrente ou tous les contrôles nécessaires sont actifs.

En 22 mois, MCP est passé de six serveurs de référence à un projet de la Linux Foundation que Claude, ChatGPT, VS Code et Cursor parlent tous. Connecter un modèle à un système est désormais la partie bon marché. Décider de ce qu’il a le droit d’y faire, c’est là qu’est le travail.