Avant USB, chaque périphérique arrivait avec son propre câble et son propre pilote. Les imprimantes avaient un connecteur, les scanners un autre, et ajouter un appareil signifiait espérer que quelqu'un avait écrit le logiciel pour votre machine.
L'intégration d'outils pour l'IA a passé ses premières années exactement dans cet état — et le Model Context Protocol est la réponse.
Le problème qu'il existe pour résoudre
Un agent n'est utile qu'à la mesure de ce qu'il peut atteindre. L'atteindre signifiait écrire une intégration sur mesure pour chaque combinaison — tel framework d'agent, telle API, dans tel langage — et chacune était unique.
Avec une poignée d'outils, c'est fastidieux. Avec des centaines, c'est intenable — et le travail part à la poubelle à chaque changement de framework.
MCP inverse le problème. Au lieu que chaque agent implémente chaque intégration, un service expose ses capacités une fois, dans une forme standard, et tout agent parlant MCP peut les utiliser. Écrivez le serveur une fois ; chaque client l'obtient gratuitement.
C'est toute l'idée. Sa valeur vient de l'adoption plutôt que de l'ingéniosité — c'est pourquoi la question intéressante n'a jamais été technique.
Ce qu'un serveur MCP expose réellement
Trois choses — et la distinction entre elles compte plus qu'il n'y paraît.
Les tools sont des actions que l'agent peut invoquer — créer une facture, chercher des commandes, envoyer un message. Chacun a un nom, une description et un schéma d'entrée typé. La description n'est pas de la documentation ; c'est sur elle que le modèle décide d'appeler ou non la chose — ce qui en fait le texte au plus fort levier de votre serveur.
Les resources sont du contexte lisible — un document, un fichier de configuration, un enregistrement de base de données. L'agent les lit, il n'agit pas dessus. Elles remplissent la fenêtre de contexte au lieu de changer le monde.
Les prompts sont des gabarits réutilisables qu'un serveur propose pour les tâches courantes, qu'un client peut présenter comme des flux prêts à l'emploi.
La plupart des serveurs sont surtout des tools. Bien faire le partage compte, parce que les tools impliquent des effets de bord et les resources non — et les clients les traitent différemment au moment de décider ce qui exige l'approbation d'un humain.
Fig. — Le sujet n'est pas le protocole. C'est de transformer un problème N×M en N+M.
Pourquoi l'adoption a été si rapide
Les standards échouent, d'habitude. Celui-ci s'est répandu vite pour quelques raisons pratiques.
Il est arrivé avec des implémentations qui marchent, plutôt qu'avec une spécification et de bonnes intentions. Des serveurs de référence pour les systèmes courants existaient dès le premier jour — la première question d'un développeur trouvait sa réponse en lançant quelque chose.
Il est délibérément petit. Le protocole ne s'essaie pas aux schémas d'authentification, à la logique métier ni à l'orchestration — il décrit comment un client découvre et appelle des capacités, puis s'arrête. Les petits standards se font adopter ; les exhaustifs se font débattre.
Et l'incitation s'aligne pour tout le monde. Si vous exploitez une API, un serveur MCP rend votre produit utilisable depuis chaque agent que quelqu'un construit — une distribution que vous n'avez pas eu à négocier. Être injoignable par les agents devient discrètement un problème concurrentiel.
Devriez-vous en construire un ?
La réponse honnête pour la plupart des équipes : oui, si vous avez déjà une API correcte — et c'est un projet plus petit que prévu.
Un serveur MCP est une couche mince sur ce que vous exposez déjà. Si votre API REST ou GraphQL est bien conçue, le serveur est en gros une traduction d'endpoints en définitions de tools avec de bonnes descriptions. Une première version, c'est des jours, pas des semaines.
Si votre API est mal conçue, le serveur héritera de chaque problème. Des endpoints qui exigent cinq appels successifs pour une chose utile produisent un agent qui fait cinq appels et se perd à mi-chemin. Autant le savoir avant de commencer — MCP révèle la qualité de conception d'une API avec une dureté inhabituelle, parce que le consommateur ne peut pas lire votre doc et contourner les endroits malcommodes.
Les cas où ça paie clairement : vos clients sont techniques, votre API est le produit, ou vos utilisateurs demandent déjà si vous vous intégrez à leur outillage IA. Le cas où non : un système interne à trois utilisateurs, sans agent à l'horizon.
Comment la connexion se fait vraiment
Un détail pratique décide beaucoup de votre déploiement : les serveurs MCP existent sous deux formes, adaptées à des situations différentes.
Un serveur local tourne comme processus sur la même machine que le client et communique par l'entrée-sortie standard. C'est ainsi que la plupart des outils IA de bureau se connectent aux choses — le serveur a les accès de l'utilisateur, aucune exposition réseau, pas d'authentification séparée. Excellent pour l'outillage développeur et l'automatisation personnelle, inutilisable pour un service consommé par d'autres.
Un serveur distant tourne sur HTTP — c'est ce qu'il vous faut si vous exposez un produit. Reviennent alors toutes les préoccupations ordinaires — authentification, limitation de débit, isolation des tenants, sécurité du transport — et c'est là que se trouve l'essentiel de la vraie ingénierie. Le protocole ne dit presque rien de l'authentification, délibérément : vous utilisez votre schéma existant plutôt que d'en adopter un nouveau.
Pour une entreprise qui expose une API, le serveur distant est la forme pertinente — et le cadrage honnête est que vous livrez une surface publique de plus, avec tout ce que ça implique. Ce n'est pas un plugin.
Ce qu'il faut réussir
Les descriptions sont l'interface. Un tool nommé search décrit comme « cherche des choses » sera appelé au hasard. Un tool décrit comme « Recherche les commandes clients par e-mail, numéro de commande ou plage de dates. Retourne jusqu'à 50 résultats avec statut et total. » sera appelé correctement. Passez-y du vrai temps ; ça compte plus que le code.
Dimensionner les tools sur des tâches complètes. Un tool qui fait une chose utile bat trois tools à enchaîner. Chaque appel supplémentaire est une occasion de plus pour le modèle de perdre le fil.
Retourner des erreurs exploitables par un agent. « Requête invalide » est une impasse. « La date doit être AAAA-MM-JJ ; vous avez envoyé 12/03/2026 » permet une reprise réussie.
Supposer que l'appelant peut être manipulé. Un agent qui lit l'e-mail d'un client peut se voir ordonner, par cet e-mail, d'appeler votre tool de suppression. Votre serveur est une frontière : imposez l'autorisation à chaque appel plutôt que de présumer qu'un agent bien élevé se trouve en face. C'est de la sécurité d'API ordinaire — et elle compte davantage ici, parce que le client est réellement imprévisible.
Garder les réponses petites. Tout ce que vous retournez coûte du contexte. Un tool qui déverse cent champs quand six suffisaient rend l'agent moins bon et l'appel plus cher.
Commencez par trois tools couvrant votre cas d'usage le plus fréquent, écrivez les descriptions avec soin, et essayez contre un vrai agent. Un après-midi à le regarder mal choisir vous apprendra plus que n'importe quelle quantité de conception.
Trois outils, des descriptions soignées, un agent réel — c'est par cet après-midi-là que commencent nos projets d'agents. Nous le faisons avec vous.
