MCP expliqué : Comprendre et construire un serveur de Protocole de Contexte de Modèle

Tout le monde parle des MCP, mais que sont-ils réellement et représentent-ils vraiment la prochaine grande innovation dans le monde de l’IA ? Dans cet article, je vais expliquer ce qu’est un MCP, nous allons construire ensemble un serveur MCP que nous utiliserons dans Cursor, puis j’aborderai certaines limitations et problèmes que je perçois avec les MCP, ainsi que ce qui, selon moi, doit se produire pour que les MCP connaissent un véritable essor.

Qu’est-ce que le MCP ?

MCP signifie « Model Context Protocol » (Protocole de Contexte de Modèle) et ce n’est pas une nouvelle technologie. Il s’agit simplement d’un standard défini par Anthropic pour faciliter la communication entre les agents d’IA et d’autres systèmes logiciels. C’est essentiellement un ensemble de règles qu’une API doit suivre pour permettre à une IA d’interagir facilement avec cette API.

J’espère que cela dissipe beaucoup de confusion, car il n’y a vraiment pas grand-chose à comprendre : c’est juste un ensemble de règles qu’une API doit implémenter.

Pourquoi utiliser le MCP ?

Si c’est si simple, pourquoi s’en préoccuper ? En fait, le MCP est une bonne idée car il permet aux plateformes d’IA de ne pas avoir à s’intégrer individuellement avec tous les autres systèmes logiciels. Elles n’ont pas besoin de construire une centaine de connexions différentes – elles peuvent simplement s’intégrer avec le MCP et obtenir immédiatement accès à tous ces autres outils.

Ce que fait le MCP, c’est s’assurer que tous ces outils qui implémentent des API suivant le protocole décrivent correctement toutes les façons dont l’IA peut interagir avec leur système. Ils décriront les différents points d’accès (endpoints), comment ils peuvent recevoir des données, quel type de données ils peuvent renvoyer à l’IA. L’agent d’IA sera alors capable d’utiliser ces endpoints pour découvrir ce qui est possible, puis utiliser les appels d’outils appropriés pour récupérer et soumettre les données adéquates à cet autre système.

Vous pourriez absolument faire cela sans MCP – vous pourriez simplement créer une API, rédiger une documentation API, la donner à l’agent d’IA, et il pourrait communiquer avec votre système. Mais le MCP standardise ce processus, de sorte qu’en l’intégrant, vous pouvez immédiatement obtenir des intégrations avec tous les autres logiciels qui ont implémenté le MCP.

Construire notre propre serveur MCP

Passons maintenant à l’implémentation de notre propre serveur MCP. Comme vous le verrez, il s’agira d’un serveur backend assez simple avec quelques points d’accès API bien définis. Nous allons implémenter un MCP météo qui récupère les prévisions météorologiques pour un lieu particulier, en suivant ce guide pour commencer.

De nos jours, l’IA peut écrire la majeure partie de notre code, et Anthropic a fait un assez bon travail en compilant la documentation nécessaire pour qu’un agent puisse écrire des MCP pour nous.

Étape 1 : Préparation des fichiers de documentation

En suivant les étapes du guide, nous allons d’abord visiter un fichier TXT et copier tout son contenu dans un fichier de notre projet. J’ai un projet assez vide ici, je vais donc créer un nouveau fichier MCP-requirements.txt et y coller le contenu.

Ensuite, le guide indique que nous devons consulter soit le SDK TypeScript, soit le SDK Python. Je vais utiliser TypeScript, donc je vais cliquer sur cette option et copier le README, puis le coller dans notre projet sous le nom typescript-MCP.md.

Étape 2 : Demander à l’IA d’implémenter notre MCP

Maintenant que nous avons toute notre documentation en place, je vais demander à l’agent de Cursor : « Veuillez implémenter un MCP pour récupérer la météo pour un lieu particulier ».

Cursor va créer un projet pour nous, avec le fichier principal du serveur. Une fois tout le code généré, nous devons le construire avec npm run build.

Étape 3 : Configuration du serveur MCP dans Cursor

Le fichier index.js est notre MCP réel, et l’exécution de ce fichier va essentiellement démarrer le serveur MCP. Je vais maintenant configurer Cursor pour utiliser notre MCP :

Aller dans Fichier > Préférences > Paramètres de Cursor
Descendre et cliquer sur « Ajouter un nouveau serveur MCP »

Je vais l’appeler « weather »

Il y a un menu déroulant avec deux options : « command » ou « server-sent events ». Cela signifie que si vous utilisez le type « command », c’est un serveur MCP qui s’exécute directement sur votre ordinateur et utilise l’entrée/sortie standard pour communiquer avec l’outil d’IA. Le « SSE » sera une API REST standard qui utilisera les événements envoyés par le serveur pour communiquer avec l’agent d’IA.

Le MCP que nous venons de créer est basé sur les commandes, donc je vais copier le chemin de mon fichier index et l’ajouter ici. Nous allons écrire « node » parce que c’est la commande qui va l’exécuter, puis coller le chemin complet du fichier, et l’appeler « weather ». Cliquez sur Ajouter.

Une fenêtre apparaît, c’est Cursor qui démarre essentiellement le MCP dans son propre environnement, et il semble s’être correctement connecté.

Étape 4 : Test du MCP

Je vais ouvrir un nouveau chat agent et demander : « Quelles sont les prévisions météorologiques actuelles à New York ? »

L’agent Cursor connaît les coordonnées et essaie maintenant d’appeler notre MCP. Il va passer ces données à notre MCP, et plus précisément, il appelle le point d’accès « get_forecast ». Nous allons l’exécuter, et il va également récupérer toutes les alertes.

Toutes ces données ont été récupérées en temps réel via notre MCP.

Analyse du code du serveur MCP

Examinons le code réel pour comprendre ce qui se passe :

Au début, nous créons ce nouveau serveur MCP, puis nous définissons des points d’accès spécifiques dans ce serveur. Nous disons : « Voici un outil disponible », nous lui donnons un nom, une description qui aidera l’agent d’IA à déterminer quand il doit utiliser cet outil, puis nous fournissons une description de ce à quoi ressembleront les entrées. C’est ce que l’agent est censé soumettre à votre outil pour l’utiliser.

Si nous regardons l’outil de prévisions, nous attendons une latitude et une longitude, avec certaines restrictions sur le type de nombres que nous pouvons soumettre, et une description de ce que signifie réellement l’entrée. Cela sera utilisé par l’agent d’IA pour communiquer correctement avec cet outil.

Ensuite, nous définissons une fonction pour ce qu’il faut faire avec ces entrées. Dans notre cas, nous allons appeler cette API et, si pour une raison quelconque nous n’avons pas l’emplacement, cet outil renverra une erreur. Il y a quelques autres gestionnaires d’erreurs ici, et enfin, nous allons obtenir les prévisions, les formater en chaîne de caractères, puis les renvoyer.

C’est ce qui se passe quand ça réussit : il renverra ce texte de prévision à l’agent d’IA, qui pourra l’utiliser dans ce qu’il fait.

Après avoir fait fonctionner ce MCP localement via le transport de commande, j’ai essayé de le convertir en une version basée sur une API REST du serveur MCP, mais j’ai eu du mal à faire dire à Cursor exactement ce qui n’allait pas. Je n’ai donc pas pu le faire fonctionner. Je pourrais revenir sur ce sujet dans un tutoriel plus technique sur les MCP, mais pour l’instant, je pense qu’il est préférable de passer à autre chose.

Limitations des MCP

Parlons maintenant de certaines limitations des MCP et de la question de savoir s’ils valent vraiment la peine d’être développés actuellement.

Je pense que l’idée dans son ensemble est bien intentionnée, et je vois l’intérêt d’essayer de standardiser un protocole pour que l’IA puisse communiquer avec différents systèmes. Cependant, je ne suis pas sûr que le MCP soit entièrement nécessaire, car nous avons déjà d’autres protocoles standard qui permettent une communication standardisée entre les systèmes logiciels.

Il existe quelque chose appelé « Open API Spec » (que certains d’entre vous connaissent peut-être sous le nom de Swagger Docs), qui est une approche standard pour documenter les API REST. Il a déjà été adopté par des milliers d’outils et de développeurs différents, et OpenAI l’a utilisé comme base pour leurs GPT personnalisés.

Je comprends que le MCP essaie d’être un peu plus dogmatique et axé sur ce cas d’utilisation d’agent d’IA, mais je ne suis toujours pas entièrement convaincu que ce soit nécessaire. En effet, cela oblige tous ces développeurs qui créent les outils ou ces serveurs MCP à créer ces ensembles supplémentaires de points d’accès qui suivent ces règles spécifiques.

La valeur marginale pour un outil d’ajouter la compatibilité MCP n’est pas très claire pour moi, surtout lorsque les agents d’IA peuvent lire une documentation arbitraire et la suivre pour appeler votre API standard.

Problèmes majeurs avec les MCP

Mais même si nous supposons que chaque outil va implémenter la compatibilité MCP, il reste des problèmes majeurs :

Absence de directives d’authentification ou d’autorisation : Le MCP n’offre aucune orientation en termes d’authentification ou d’autorisation, ce qui signifie que tous ces serveurs MCP que vous construisez supposent essentiellement que vous êtes dans un environnement sécurisé et que vous devriez avoir accès à toutes les données. Ce ne sera pas le cas dans une application d’entreprise où vous voulez vous assurer que les utilisateurs ne peuvent voir que ce qu’ils devraient pouvoir voir. Anthropic a placé ce point en tête de sa liste de priorités pour l’ajout au MCP, mais jusqu’à ce que ce soit en place, il n’y a pas vraiment de bonnes solutions pour s’assurer que vos serveurs MCP sont sécurisés.

Problèmes de découvrabilité : Comme vous l’avez vu dans notre démo, nous avons dû ajouter notre MCP à Cursor. Ce sera le cas avec n’importe quel serveur MCP, et il n’y a pas de référentiel central ou de gestionnaire de packages pour les MCP. Vous devez donc soit mettre en place vos propres MCP, soit simplement faire confiance au fait qu’un MCP aléatoire que quelqu’un héberge sera acceptable pour vous. Mais étant donné que ces MCP contiennent du code backend arbitraire, ce n’est vraiment pas une bonne idée d’utiliser les MCP d’autres personnes, à moins de savoir exactement ce qu’ils font. Car, pour autant que vous sachiez, leur MCP pourrait demander vos clés API, et votre agent d’IA les leur remettrait simplement.
Manque de contrôle de qualité : Comme n’importe qui peut créer des MCP et qu’il n’y a pas d’autorité centrale veillant à ce qu’ils soient de haute qualité, vous devez être très prudent quant au code qui s’exécute réellement dans ce MCP et vous assurer qu’il fonctionne correctement. C’est vraiment une situation de Far West en ce moment, et je ne pense pas que cela s’améliorera tant qu’il n’y aura pas une sorte de marché central pour les MCP qui vous permettra de vous intégrer rapidement avec eux, avec des avis d’utilisateurs pour vous assurer que c’est légitime, et idéalement avec une sorte de processus de vérification pour les personnes qui créent ces MCP afin que vous ayez une idée de leur qualité.

Conclusion

La dernière chose que je noterai est que c’est juste un protocole de communication. Vous êtes donc toujours responsable du développement du serveur MCP, de son hébergement, de son déploiement. C’est juste une couche supplémentaire par-dessus votre API existante.

Bien que je pense que c’est une bonne idée de doter ces agents d’IA d’un ensemble standardisé d’outils, je pense qu’il reste encore beaucoup de travail à faire pour rendre les MCP pratiques et utiles dans des scénarios réels.

Mais que pensez-vous des MCP ? Faites-le moi savoir dans les commentaires ci-dessous et, comme toujours, merci d’avoir lu cet article.

Note : Le code complet de ce projet est disponible via un lien dans la description.