Ce qu'il normalise, et ce qu'il ne fait pas
Un assistant qui ne lit que le texte collé dans sa fenêtre sert à conseiller, pas à travailler. Le faire toucher un vrai système imposait d'écrire une intégration contre le format d'appel d'outils d'un fournisseur, puis de la réécrire pour le suivant, puis encore pour l'application de bureau : le même connecteur trois fois, divergeant dès le premier jour.
MCP définit la connexion. Un serveur expose une capacité ; un client, à l'intérieur de l'assistant, la consomme. Les deux bouts parlent JSON-RPC sur un transport défini, si bien qu'un serveur écrit pour un client est joignable depuis tout autre client implémentant le protocole.
Ce qu'il ne fait pas, c'est rendre le modèle habile à se servir de ce qu'il trouve. Le protocole porte la plomberie — découverte, invocation, résultats, erreurs — et le jugement sur le moment d'appeler et sur l'usage de la réponse reste entièrement au modèle et à ses instructions.
C'est une prise commune. Écrivez le connecteur une fois et tout assistant parlant MCP peut s'en servir.
Les trois choses qu'un serveur peut exposer
Les outils sont des actions que le modèle peut invoquer : lancer une requête, ouvrir un ticket, envoyer une demande. C'est la partie que tout le monde désigne en disant MCP, et celle qui peut changer le monde extérieur — d'où l'attente qu'un client interroge l'humain avant de l'exécuter.
Les ressources sont des choses que le modèle peut lire : un fichier, un enregistrement, une page. On les adresse au lieu de les appeler, et c'est ainsi que l'assistant obtient du contexte sans que l'utilisateur colle quoi que ce soit.
Les prompts sont des instructions prêtes que le serveur propose — une liste de relecture, la forme d'un rapport — présentées à la personne comme un choix, non au modèle comme un appel.
La distinction compte : c'est la différence entre un assistant qui peut lire vos données et un assistant qui peut agir dessus, et ce sont deux conversations différentes avec une équipe sécurité.
Différence avec l'appel de fonctions et avec un plugin
L'appel de fonctions est une capacité du modèle : il émet une demande structurée, votre code l'exécute. MCP ne le remplace pas, il se pose au-dessus, pour que ce que votre code exécute puisse être un serveur écrit par quelqu'un d'autre et découvert à l'exécution plutôt que figé dans le code.
Un plugin appartient à la plateforme qui le définit et fonctionne là. Un serveur MCP appartient à qui l'a écrit et fonctionne partout où le protocole est implémenté — c'est tout l'intérêt de normaliser la connexion plutôt que le catalogue.
Le test pratique : si changer d'assistant oblige à réécrire l'intégration, ce n'était pas du MCP.
Ce à quoi faire attention
- Un serveur est du code que vous exécutez. En installer un venu d'un inconnu tient de l'installation d'un paquet, pas de l'ajout d'un signet, et il hérite des identifiants que vous lui confiez.
- Le modèle lit les descriptions d'outils comme des instructions. Un serveur peut décrire le sien de façon à orienter l'assistant : surface d'attaque réelle, et raison d'être des demandes de confirmation.
- Les données atteintes par un serveur sont des données sorties de leur système. « L'assistant peut lire nos tickets » et « nos tickets sont dans le contexte d'un modèle » sont la même phrase dite deux fois.
- L'ampleur n'est pas gratuite. Chaque serveur connecté ajoute des descriptions au contexte que le modèle doit traiter, et un assistant disposant de quarante outils choisit mesurablement moins bien qu'un assistant qui en a six.
Pourquoi cela figure dans un glossaire sur la visibilité
Parce que le même déplacement est dessous. La recherche documentaire décide de ce qu'un assistant peut citer de vous ; MCP décide de ce qu'il peut atteindre et faire pour la personne qui demande. L'acheteur qui visitait votre site pour vérifier un fait dispose désormais d'un assistant capable de le vérifier dans un système connecté, et votre page publiée est en concurrence non seulement avec ce que le modèle retient, mais avec ce qu'il peut consulter en direct.
Cela change aussi la fonction d'une page de documentation. Un serveur est décrit au modèle en quelques phrases, et ces phrases sont tout ce qu'il sait avant d'agir : la discipline qui rend une page citable, avec moins de mots et moins de place pour le flou.
Questions fréquentes
MCP est-il un produit Anthropic ?
Il a été publié par Anthropic en novembre 2024 et diffusé comme norme ouverte, avec une spécification et des SDK ouverts. Des clients et des serveurs de nombreuses organisations l'implémentent, y compris sans lien avec Anthropic, et un serveur que vous écrivez n'est lié à aucun fournisseur.
Ai-je besoin de MCP pour donner accès à mes données à un modèle ?
Non. L'appel de fonctions contre votre propre code fonctionne et reste la bonne réponse pour une intégration à un seul endroit. MCP se justifie quand la même capacité doit être joignable depuis plusieurs assistants, ou quand vous voulez utiliser des connecteurs écrits par d'autres sans adopter leur pile.
Connecter un serveur signifie-t-il que le modèle peut tout faire ?
Cela signifie qu'il peut demander tout ce que le serveur expose. Ce qui s'exécute relève du client, dont on attend qu'il place l'humain devant tout outil qui modifie quelque chose. La question de sécurité porte donc sur les serveurs que vous connectez et sur leurs identifiants, pas sur le protocole.
Avoir un serveur MCP aide-t-il mon site à être cité par les assistants ?
Pas en soi, et y voir une tactique de référencement, c'est le lire de travers. Un serveur est joignable par ceux qui l'ont connecté, pas par un modèle répondant à un inconnu sur votre catégorie. Ce qui vous fait citer reste la page qu'un système de recherche peut lire et citer.
Demandé à voix haute
dit, non tapéLe même terme dans les mots employés en parlant à un assistant plutôt qu’en tapant dans un champ de recherche — écrit depuis la situation, et c’est pourquoi chaque question porte la situation dont elle vient.
Vous approuvez un logiciel qui détiendra des identifiants du support et en exposera des parties à un assistant, et tout ce que l'assistant lit sort du périmètre du support. Les bonnes questions : qui a écrit le serveur, quels identifiants il reçoit, s'il peut écrire et pas seulement lire, et si un humain confirme les écritures.
Une clé donne à un assistant une intégration que vous écrivez et maintenez. MCP est une forme commune de cette connexion : le même serveur fonctionne dans d'autres assistants, et les connecteurs d'autres personnes fonctionnent dans le vôtre. La question d'accès est identique — le protocole normalise le câblage, pas la confiance.
Non, et elles se complètent. Un serveur donne à l'agent de la portée : des choses à lire et à faire. Une compétence lui donne le savoir-faire : des instructions pour bien mener un travail précis, chargées quand ce travail se présente. Un agent doté d'un serveur de base de données et d'aucune compétence interrogera mal votre base.