Serveur MCP : ce qu’un protocole d’outils expose à ton agent avant toute connexion
Brancher un serveur MCP à un agent donne l’impression que tout devient possible. En réalité, rien n’est magique. Tu connectes un protocole, pas un superpouvoir. MCP sert surtout à rendre lisibles des capacités qui, sinon, resteraient cachées derrière des connecteurs maison et des scripts fragiles.
La différence est simple. Un agent compatible MCP découvre d’abord ce que le serveur expose, puis il décide quoi appeler. Tu vois la liste des outils, des ressources et des prompts avant d’appuyer sur quoi que ce soit. Si tu ne lis pas ce manifeste, tu navigues à l’aveugle.
Ce que MCP change vraiment
MCP est un standard ouvert pour relier une application d’IA à des systèmes externes, fichiers locaux, bases de données, outils, workflows et prompts spécialisés. La logique est la même qu’avec un port USB-C, une interface commune, plusieurs périphériques derrière.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Avant MCP, chaque intégration ressemblait à un petit projet à part. Un connecteur pour Google Docs, un autre pour PostgreSQL, un autre pour GitHub. Avec MCP, tu exposes des capacités dans un serveur, et un client compatible les consomme. Tu réduis le bricolage, mais tu ne supprimes pas la discipline. Le protocole ne corrige pas un mauvais périmètre.
Outils, ressources, prompts : ne pas tout mélanger
Dans MCP, un outil sert à agir. L’agent l’appelle pour écrire un fichier, lancer une requête, créer une issue, pousser une action. La ressource, elle, sert à lire un état. Un fichier, un schéma, une donnée de référence. Le prompt, enfin, est un cadre prêt à l’emploi pour lancer une tâche avec le bon contexte.
Cette distinction a l’air théorique, mais elle change la façon dont tu raisonnes. Un outil peut produire un effet. Une ressource ne doit pas en produire. Un prompt n’est pas un automatisme, c’est un point de départ. Si tu confonds les trois, tu finis avec des serveurs qui font tout un peu mal.
La spécification officielle le dit clairement : les serveurs peuvent exposer des outils, des ressources et des prompts, et le client les découvre avant de les utiliser. Ce n’est pas un catalogue marketing. C’est un contrat technique lisible, avec ses noms, ses schémas d’entrée et ses réponses.
Ce qu’il faut vérifier avant de brancher
Avant de connecter un serveur MCP, regarde d’abord le transport. En local, MCP passe souvent par stdio, donc par des flux d’entrée et de sortie standards entre deux processus sur la même machine. À distance, il passe par HTTP streamable. Ce n’est pas le même périmètre, ni la même surface d’exposition.
Si tu veux creuser ce choix sans te raconter d’histoire, j’ai déjà posé le cadre dans mémoire IA. Le point important est simple : le transport n’est pas un détail d’implémentation, c’est une décision de sécurité et d’exploitation.
Deuxième vérification : le nombre d’outils exposés. Un serveur peut en proposer trente, mais ton usage réel n’en demande souvent que trois. Plus tu laisses de surface, plus tu dois surveiller. Si un serveur expose delete_file, push_commit ou d’autres actions lourdes, demande-toi si tu assumes vraiment ce pouvoir.
Troisième vérification : les secrets. Un serveur local n’a pas vocation à recevoir tout ton environnement comme si de rien n’était. Déclare seulement ce qui est nécessaire, et rien d’autre. Un token en trop n’ajoute pas de confort. Il ajoute une fuite potentielle.
Quatrième vérification : la sortie elle-même. Un serveur utile peut aussi renvoyer un résultat mal formé, trop bavard, ou trompeur. MCP ne remplace ni la validation, ni la revue humaine, ni le bon sens. Il standardise l’échange. Il ne garantit pas que la réponse est bonne.
MCP dans Hermes : comment je le regarderais
Dans Hermes, je traiterais un serveur MCP comme une capacité à exposer, pas comme une brique à empiler sans recul. Je partirais du besoin concret : lire des fichiers, interroger une base, appeler un service métier, ou cadrer une tâche répétitive. Ensuite seulement je regarderais le serveur qui sait faire ça, et je couperais tout ce qui n’a pas de raison d’être.
C’est là que la lecture du manifeste compte. Tu n’évalues pas seulement le nom de l’outil. Tu regardes son schéma, ses paramètres obligatoires, ses limites, ses erreurs possibles. Un bon serveur MCP est souvent ennuyeux au bon sens du terme : peu de surface, peu d’ambiguïté, peu de surprise.
Si tu utilises plusieurs serveurs, pense aussi à la séparation. Un serveur fichiers n’a pas à avoir les mêmes droits qu’un serveur GitHub. Un serveur de base de données n’a pas à voir le reste du monde. Le protocole permet le branchement. À toi d’éviter le grand mélange qui finit toujours par coûter cher.
Si tu veux limiter ce qu’un agent voit vraiment, commence petit. J’explique le principe dans la défense contre la prompt injection d’un agent connecté. C’est plus lent au départ, mais tu réduis les dégâts possibles. Le jour où le serveur marche, tu préfères avoir un périmètre court et compréhensible plutôt qu’un monstre qui « fait tout » et que plus personne n’ose toucher.
Les erreurs qui reviennent tout le temps
La première erreur, c’est de croire que le serveur sait ce que tu veux dire. Non. Il sait ce qu’il déclare. S’il n’a pas de schéma clair, c’est ton problème, pas le sien.
La deuxième erreur, c’est de brancher un serveur distant comme si c’était un plugin local. À partir du moment où le transport sort de ta machine, tu changes de terrain. Tu rajoutes du réseau, de l’authentification, des dépendances, des points de rupture. Ce n’est pas un drame. C’est juste une autre classe de risque.
La troisième erreur, c’est d’oublier les cas d’échec. Un outil qui échoue doit échouer proprement. Un prompt qui manque de contexte doit le dire. Une ressource introuvable ne devrait pas faire semblant d’exister. C’est exactement ce que la spec essaie d’encadrer avec ses réponses, ses erreurs et ses capacités annoncées.
La quatrième erreur, enfin, c’est de considérer MCP comme une couche magique qui remplace l’architecture. Elle ne la remplace pas. Elle la rend plus lisible. Si ton système est bancal, MCP ne le rend pas solide par miracle.
Il y a aussi une erreur plus discrète : exposer des capacités qui ne servent à rien juste parce qu’elles sont là. Un serveur n’est pas bon parce qu’il expose beaucoup de choses. Il est bon parce qu’il expose les bonnes choses, au bon endroit, avec les bons droits.
Ce que tu dois retenir avant de passer à l’action
Un serveur MCP utile est un serveur lisible. Tu sais ce qu’il expose, pourquoi il l’expose, et dans quel cadre il le fait. Tu sais aussi ce qu’il n’expose pas. C’est cette frontière qui fait la différence entre une intégration propre et une porte ouverte de trop.
La bonne décision n’est pas « MCP ou pas MCP ». La bonne décision, c’est : quel serveur, quel transport, quels droits, quels outils, quel contrôle humain. Si tu réponds à ces cinq questions avant d’intégrer le serveur, tu évites déjà la moitié des ennuis.
Pour voir la spec officielle, lis la documentation MCP d’introduction, puis les pages tools, resources et prompts. Si tu veux le mettre en place proprement dans un cas réel, tu peux aussi faire une demande et partir d’un cadre simple plutôt que d’un branchement trop large.
