4 leçons apprises en construisant avec les outils MCP et les API de Vonage

Le protocole de contexte de modèle (MCP) a évolué rapidement. Je me souviens de la première fois que j'en ai entendu parler en mars dernier à FOSSASIA 2025. Il est difficile de croire que cela fait moins d'un an, mais j'ai déjà l'impression qu'il est devenu omniprésent dans la programmation.

Même si j'en ai entendu parler très tôt, ce n'est qu'au cours des derniers mois que j'ai vraiment plongé dans l'aventure. J'ai joué avec la documentation de Vonage et Tooling MCP serversd'abord localement, puis par le biais d'articles de blog, de démonstrations, et enfin en aidant le serveur d'outils open-source. Il ne s'agit pas d'un récapitulatif des fonctionnalités MCP ou d'un guide de démarrage : Il s'agit d'un ensemble de leçons qui sont apparues en essayant de rendre les outils utilisables dans la pratique.

Première leçon : une erreur précoce : Les agents génèrent du code par défaut

Le premier véritable échec n'était pas un bogue technique. Il s'agissait d'un modèle mental défectueux.

J'ai connecté mon IDE au serveur MCP, confirmé que les outils étaient enregistrés et demandé à l'agent d'envoyer un message WhatsApp. Au lieu d'appeler l'outil existant, l'agent a ouvert un nouveau fichier et a commencé à écrire un script Node.js. Il a tenté d'importer le SDK de Vonage, de configurer l'authentification et d'effectuer l'appel API directement.

Rien ne clochait dans le modèle. Il faisait exactement ce pour quoi il avait été formé : résoudre des problèmes en écrivant du code.

Le problème résidait dans la manière dont je concevais le système. L'agent agissait comme un générateur de code plus intelligent, plutôt que comme une couche d'orchestration. Les outils existaient déjà. L'agent n'avait pas besoin de construire quoi que ce soit : il devait sélectionner et invoquer ce qui était disponible.

Une fois que j'ai ajusté la façon dont j'invitais l'agent, les choses se sont mises en place. Au lieu de lui demander de créer une fonctionnalité, je lui ai demandé de l'utiliser.

Ce changement semble mineur, mais il s'agit en réalité d'un changement mental important.

Ce qu'il faut retenir : Le MCP fonctionne mieux lorsque l'on cesse de penser en termes de scripts et que l'on commence à penser en termes d'outils. Si l'agent écrit un code de colle, cela signifie généralement que quelque chose en amont n'est pas structuré correctement.

Deuxième leçon : la configuration était une véritable perte de temps

Une fois le modèle mental corrigé, je m'attendais à ce que le reste du travail soit simple. Ce n'était pas le cas.

La partie la plus fastidieuse du développement local a été de faire en sorte que l'IDE se connecte de manière fiable au serveur MCP. La plupart des échecs ressemblaient à "l'outil ne s'affiche pas", ce qui permettait de supposer que le serveur était défectueux. Il s'agissait presque toujours de la configuration.

Différents IDEs attendent la configuration du MCP à des endroits différents. Par exemple, Windsurf ressemble à VS Code, mais ce n'est pas VS Code, et le chemin de configuration n'est pas là où la mémoire musculaire suggère qu'il devrait être. J'ai passé plus de temps que je ne voudrais l'admettre à chasser des bogues inexistants parce que le serveur n'a jamais été lancé en premier lieu.

Les configurations MCP ne se comportent pas non plus comme des scripts shell. Le client lance directement un processus. Vous ne pouvez pas compter sur sh -c, cdou les commandes enchaînées. Si vous n'utilisez pas de chemins absolus et de commandes explicites, les échecs ont tendance à être silencieux.

Une fois que tout a été configuré correctement, l'expérience s'est déroulée sans incident, dans le meilleur des cas. Redémarrer l'IDE, rafraîchir le panneau des plugins, et les outils apparaissent.

Ce qu'il faut retenir : MCP suit un schéma de programmation familier : la configuration est l'endroit où se produisent la plupart des maux de tête. Lorsque quelque chose ne fonctionne pas, il s'agit généralement d'une configuration. Une fois que vous êtes installé, MCP vous permet de voler !

Troisième leçon : Stdio fonctionne bien localement, moins bien ailleurs

Le transport stdio par défaut de MCP est bien adapté au développement local. Il est simple, rapide et évite d'exposer des ports ou des informations d'identification. Pour les flux de travail basés sur l'IDE, il fait exactement ce que vous voulez. Et c'est exactement la raison pour laquelle nous l'avons utilisé pour notre serveur d'outils. Nous voulions le mettre entre les mains des développeurs de manière rapide et flexible.

Cependant, certaines limitations apparaissent lorsque vous essayez d'utiliser les mêmes outils en dehors d'un IDE, comme l'intégration d'un système externe. Vous ne pouvez pas faire de requête HTTP à stdin. Il n'y a pas de point d'arrivée à sécuriser, ni d'endroit évident pour attacher l'authentification.

Pour combler cette lacune, j'ai fini par construire une petite couche de traduction qui convertissait JSON-RPC sur stdio en HTTP afin que d'autres systèmes puissent interagir avec le serveur MCP. Cela a fonctionné, mais il s'agissait d'une infrastructure supplémentaire qui n'existait pas dans la configuration locale uniquement.

Les tests sont également devenus plus difficiles. L'expression "ça marche localement" n'est pas très significative si l'agent appelle l'outil depuis un autre endroit. Il n'existe actuellement aucun moyen propre de valider les outils MCP de manière isolée sans lancer une session d'agent complète.

Ce qu'il faut retenir : MCP facilite les flux de travail de l'IDE, c'est pourquoi nous avons commencé par là. Pour les développeurs qui sont à l'aise avec la gestion de leur propre hébergement et de leur authentification, ce compromis est raisonnable. Une fois que vous dépassez l'utilisation locale, stdio apporte des défis tels que l'authentification, les couches de traduction et les tests. Il s'agit moins de MCP lui-même que de l'emplacement de ce serveur. Gardez l'œil ouvert car nos offres MCP se développent.

Quatrième leçon : Planifier la croissance : Conception des outils et budget contextuel

Cette leçon n'a pas été tirée d'un incident. Elle est venue de l'examen du serveur d'outils et de la question suivante : "Que se passera-t-il lorsque davantage de personnes commenceront à contribuer ?"

En écrivant sur l'utilisation des outils MCP de Vonage l'utilisation des outils MCP de Vonage et encourager les contributions au code source ouvertil est apparu clairement que la structure du répertoire n'était pas conçue pour évoluer. Tout se trouvait dans un seul fichier. C'est gérable au début, mais ce n'est pas très évolutif. Ni pour les humains, ni pour les agents.

L'examen de la manière dont les autres serveurs MCP gèrent la croissance a fait apparaître une contrainte plus importante : chaque outil que vous exposez consomme une partie de la fenêtre contextuelle du modèle.

Les schémas d'outils ne sont pas libres. Les noms, les paramètres et les descriptions sont tous injectés dans l'invite du système. Au fur et à mesure que le nombre d'outils augmente, vous réduisez progressivement l'espace dont dispose le modèle pour raisonner sur la demande réelle de l'utilisateur.

La tentation est grande de construire des outils flexibles et polyvalents : un seul outil de type envoyer_message qui gère tous les canaux et tous les comportements. Du point de vue de l'API, c'est bien rangé. Du point de vue du modèle, c'est ambigu et coûteux.

Les outils plus petits et à usage unique ont tendance à mieux fonctionner. Ils sont plus faciles à sélectionner pour le modèle, moins coûteux à décrire et plus simples à raisonner. En interne, les implémentations peuvent toujours être partagées. Ce qui importe le plus, c'est ce que voit l'agent.

Le serveur d'outils open-source actuel n'implémente pas encore le chargement contextuel, et c'est intentionnel. Mais ces contraintes influencent déjà la façon dont nous envisageons un serveur MCP plus productif ; un serveur que tout le monde peut utiliser, et pas seulement les développeurs.

Ce qu'il faut retenir : Avec MCP, la performance n'est pas seulement une question de vitesse d'exécution. Il s'agit également de la quantité de contexte que vous consommez.

Réflexions finales

Travailler avec MCP a changé ma façon d'envisager le travail quotidien. Les processus que je considérais comme manuels ou répétitifs sont devenus des outils potentiels. Une fois ce changement opéré, vous commencez à voir des opportunités partout, non pas pour automatiser pour le plaisir, mais pour supprimer les frictions qui ralentissent le travail réel.

Le MCP est encore jeune, et de nombreuses aspérités sont compréhensibles. Mais une chose est apparue très rapidement : le succès d'un système basé sur le MCP ne dépend pas seulement du modèle que vous choisissez, mais aussi de la manière dont les outils sont conçus. Des limites claires, des responsabilités étroites et un comportement prévisible sont plus importants que des abstractions intelligentes. Lorsque ces éléments sont en place, il est plus facile de faire confiance au système et de l'étendre.

Ce que je trouve le plus intéressant, c'est la façon dont le MCP vous pousse à considérer le logiciel comme quelque chose qui est destiné à être utilisé. utilisés par des agents, et pas seulement par des humains. Cela change la façon dont vous écrivez les API, la façon dont vous structurez la documentation et la façon dont vous évaluez si quelque chose est "fait". Il s'agit d'un ensemble différent de compromis, qui est encore en train de prendre forme.

Au cours des prochaines semaines, j'expérimenterai d'autres outils MCP tels que Laravel Boost et MCP UI pour voir comment d'autres abordent ces problèmes. Si vous travaillez avec MCP, ou si vous y pensez, j'aimerais savoir ce que vous construisez et ce que vous avez appris en cours de route. Envoyez-moi un message sur LinkedIn ou sur le Slack des développeurs de Vonage.