Développement de serveurs MCP : l'IA agentique comme « client zéro » des API

Les équipes d'ingénierie de Red Hat Trusted Profile Analyzer (TPA) et de Trustify ont testé le protocole MCP (Model Context Protocol). Cet article présente les défis que nous avons rencontrés. Nous espérons qu'il aidera d'autres équipes à mener à bien des projets similaires.

L'outil Red Hat TPA sert à gérer les nomenclatures logicielles. Il les stocke et met en corrélation leurs paquets avec les vulnérabilités publiques connues. Il se base sur le projet en amont Trustify.

Globalement, son architecture est assez « traditionnelle » :

• Le développement front-end s'appuie sur des composants React et PatternFly (trustify-ui).
• Le développement back-end s'appuie sur Rust. TPA se connecte à une instance de base de données et stocke les nomenclatures logicielles dans un système de stockage S3.

Voici les principales étapes que nous avons suivies :

1. Conception de l'intégration du serveur MCP à TPA/Trustify
2. Définition des descriptions des outils du serveur MCP
3. Conception des paramètres des outils du serveur MCP

Découvrez les éléments pris en compte à chaque étape et le serveur MCP qui en résulte, disponible sur GitHub. 

Conception de l'intégration du serveur MCP à TPA/Trustify

Avant même de définir l'intégration entre le serveur MCP et Trustify, nous avons dû surmonter l'une des difficultés les plus courantes de l'ingénierie logicielle : choisir la bibliothèque à adopter pour ce projet. Nous pouvions également partir de zéro et développer nous-mêmes toutes les ressources nécessaires.

Parce que nous avons confiance en l'Open Source, nous nous sommes intéressés aux bibliothèques Rust actuelles (le projet Trustify est principalement développé avec Rust, ce qui en faisait le choix le plus évident) pour la mise en œuvre d'un serveur MCP.

Il s'avère que l'environnement GitHub du protocole MCP met à disposition des bibliothèques officielles, dont une développée avec Rust.

En plus d'inclure le code nécessaire au développement d'un serveur MCP, cette bibliothèque fournit de nombreux exemples pour se lancer.

Nous avons immédiatement compris que nous devions non seulement gérer les particularités de la bibliothèque pour exécuter le serveur MCP et définir les outils disponibles avec leurs paramètres, mais aussi configurer l'accès du serveur MCP aux données « back-end ».

Nous avons évalué deux options de récupération des données :

• Connexion directe à la base de données dans laquelle le back-end de Trustify stocke les données
• Appel aux points de terminaison REST fournis par le back-end Trustify

Chaque option a ses avantages et ses inconvénients, résumés ci-dessous.

Avantages de la connexion directe à la base de données :

1. Accès performant aux données
2. Possibilité de transformer le texte en requêtes SQL

Inconvénients :

1. Le serveur MCP doit se trouver au même niveau d'architecture que le back-end.
2. Il faut dupliquer le code pour gérer l'accès aux données, contrairement au code back-end.
3. Il faut gérer le format des données pour définir les sorties des appels des outils MCP.

Avantages de l'appel aux points de terminaison REST :

1. Les appels respectent les systèmes d'authentification et d'autorisation déjà en place dans les API back-end.
2. Les données disponibles sur le serveur MCP sont cohérentes avec celles qui sont disponibles dans l'interface utilisateur, car elles utilisent la même source de données.
3. Une sortie JSON est disponible gratuitement, simplement en envoyant la sortie renvoyée par les API back-end.

Inconvénients :

1. Baisse des performances en raison d'un plus grand nombre de niveaux d'architecture à traverser

En fin de compte, nous avons décidé d'appeler les points de terminaison REST à partir des outils du serveur MCP, car le positionnement du serveur MCP à côté du back-end et à proximité de la base de données peut représenter un obstacle, en particulier lorsque le transport stdio du serveur MCP est exécuté en local sur les hôtes de développement.

Au cours de cette phase de développement initiale, il était également avantageux d'obtenir « gratuitement » toutes les données au format JSON.

Définition des descriptions des outils du serveur MCP

Après avoir opté pour les appels aux API back-end, nous devions décrire les différents outils. À la première itération, chaque outil MCP devait appeler un seul point de terminaison d'API back-end.

Trustify documente les points de terminaison disponibles à l'aide du fichier OpenAPI openapi.yaml. Nous avons donc décidé d'utiliser la description et les définitions des points de terminaison OpenAPI comme description de l'outil MCP afin d'évaluer la qualité de la documentation sur ces points de terminaison pour nos utilisateurs. Ainsi, notre IA agentique a joué le rôle de « client zéro » de nos propres API.

Tout au long du processus, nous avons suivi une approche d'amélioration continue. Si les descriptions des API Trustify sont suffisamment abouties pour qu'un grand modèle de langage (LLM) puisse les gérer, les utilisateurs doivent également être en mesure de les comprendre.

Cette approche permet d'améliorer chaque point de terminaison et de préparer la décision de conception suivante.

Conception des paramètres des outils du serveur MCP

À ce stade, nous avons fait face au problème lié aux paramètres d'entrée pour l'invocation de l'outil. Nous avons dû revenir en arrière pour le résoudre. Le point de terminaison de Trustify qui permet de récupérer une liste d'entités accepte un paramètre de requête q. Avec ce paramètre, les utilisateurs peuvent rédiger une requête qui se base sur une grammaire définie dans la documentation OpenAPI. 

Nous avions deux options :

1. Exposer directement le paramètre q path du point de terminaison comme paramètre d'entrée de l'outil MCP
2. Exposer les champs internes de création de la valeur de requête pour le paramètre q comme paramètres d'entrée de l'outil MCP

Nous avons testé ces deux approches.

La première nécessite une description exhaustive du paramètre de requête, qui n'est pas encore fournie dans la documentation OpenAPI. Nous pensons qu'il est indispensable d'ajouter la liste complète des champs pour lesquels une requête est possible. Tous les utilisateurs bénéficieraient de ces informations.

La deuxième approche simplifie le processus pour l'agent IA. Une liste explicite des paramètres à interroger (tels que la gravité de la vulnérabilité, la date de publication ou la description) permet au LLM d'utiliser les informations plus facilement. Ainsi, le LLM n'a pas besoin d'interpréter la grammaire d'une requête, ce qui représente une difficulté dans la première approche.

Une liste explicite de tous les paramètres disponibles dans l'outil MCP nécessite également un travail continu pour maintenir la cohérence avec la mise en œuvre réelle du point de terminaison back-end. À l'inverse, le fait de n'exposer qu'un sous-ensemble des paramètres disponibles réduit la polyvalence de l'outil sans garantir une baisse des coûts de maintenance.

Nous avons décidé d'utiliser un paramètre de requête q pour l'outil MCP et nous allons en améliorer la description dans la définition OpenAPI afin que tous les utilisateurs puissent en profiter.

Conclusion

Pour concevoir un serveur MCP, nous avons adopté l'approche suivante :

• Le serveur MCP exploite les API existantes.
• Le serveur MCP exploite la documentation OpenAPI existante.
• Les outils du serveur MCP exposent le même paramètre que celui attendu par le point de terminaison d'API distant.

Comme indiqué précédemment, le résultat est disponible sur GitHub.