Présentation du protocole MCP (Model Context Protocol) dans Apigee

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Cette page explique comment utiliser Apigee pour exposer vos API en tant qu'outils MCP aux applications agentiques. MCP dans Apigee est disponible pour les organisations avec abonnement, avec paiement à l'usage et d'évaluation, y compris celles pour lesquelles la résidence des données est activée. À partir de la version 1.17.0 d'Apigee hybrid, MCP est également disponible pour Apigee hybrid. Le plan de données d'exécution s'exécute dans votre propre cluster Kubernetes plutôt que sur une infrastructure gérée par Google. Consultez Activer MCP dans Apigee hybrid pour connaître le flux d'installation et de configuration spécifique à Hybrid.

Qu'est-ce que MCP ?

Le Model Context Protocol (MCP) est un protocole Open Source développé par Anthropic qui standardise la façon dont les applications d'IA se connectent aux sources de données, aux workflows et aux outils.

Les applications d'IA peuvent utiliser MCP pour accéder aux services Google Cloud et Apigee en tant qu'outils. Dans ce contexte, il est utile de comprendre les termes suivants du programme MCP :

  • Hôte MCP : application ou environnement d'IA qui interagit avec l'utilisateur. L'hôte MCP utilise des grands modèles de langage (LLM) pour traiter les requêtes qui peuvent nécessiter des données ou des outils externes.
  • Client MCP : composant de l'hôte MCP qui aide le LLM et le serveur MCP à communiquer entre eux. Il traduit les requêtes du LLM pour le serveur MCP et convertit les réponses du serveur MCP pour le LLM. Il recherche et utilise également les serveurs MCP disponibles.
  • Serveur MCP : service externe qui fournit le contexte, les données ou les capacités au LLM, en agissant comme un proxy entre le LLM et le client MCP.

Fonctionnement de MCP dans Apigee

Les points de terminaison MCP pour Google, Google Cloudet Apigee implémentent la spécification du serveur MCP. Les clients MCP conformes peuvent y accéder pour :

  • Découvrez les points de terminaison disponibles.
  • Lister les outils disponibles sur un point de terminaison.
  • Authentifiez-vous auprès d'un point de terminaison.
  • Appelez les outils en fonction des règles d'accès définies.

Tout client MCP compatible avec les points de terminaison MCP distants via HTTP/S peut accéder à ces outils. Comme les points de terminaison sont gérés, vous n'avez pas besoin d'installer ni de gérer des serveurs MCP locaux ou distants, ni d'infrastructure supplémentaire pour permettre aux applications agentiques d'accéder à vos services.

Dans Apigee, MCP est compatible avec JSON-RPC pour les méthodes tools/list et tools/call. Vous pouvez personnaliser votre point de terminaison MCP avec des paramètres de détectabilité, de sécurité, de disponibilité du réseau et d'observabilité.

Modèles de déploiement

MCP est disponible dans deux modèles de déploiement Apigee :

  • Apigee (SaaS) : le plan de données MCP est hébergé sur une infrastructure gérée par Google. Vous déployez le proxy de découverte MCP et le point de terminaison est immédiatement disponible.
  • Apigee hybrid (auto-hébergé, à partir d'Apigee hybrid 1.17.0) : le plan de données MCP s'exécute dans votre propre cluster Kubernetes. Le plan de contrôle Apigee génère la configuration de l'outil MCP à partir de votre spécification OpenAPI, et votre cluster récupère cette configuration selon son propre calendrier. Le trafic des requêtes MCP ne quitte jamais votre cluster. Consultez Activer MCP dans Apigee hybrid.

Architecture du plan de données MCP dans Apigee hybrid

Le schéma suivant montre comment les composants MCP sont répartis entre le plan de contrôle Apigee et votre cluster Apigee hybrid.

MCP dans l'architecture Apigee hybrid : les clients MCP appellent votre entrée Apigee existante via HTTPS, qui est routée vers votre processeur de messages, puis vers le nouveau plan de données MCP dans le cluster. La configuration de l'outil MCP est générée par le plan de contrôle Apigee et extraite par votre cluster. Le plan de contrôle Apigee n'appelle jamais votre cluster.

Deux propriétés de cette architecture sont importantes pour la planification et l'examen de la sécurité :

  • Le trafic des requêtes MCP reste dans votre cluster. Les clients MCP accèdent à votre entrée Apigee existante à la même URL que celle qu'ils utiliseraient pour tout autre proxy Apigee. Votre processeur de messages achemine ensuite la requête vers le plan de données MCP dans le même cluster. Aucune requête ni réponse MCP ne franchit la limite vers Google Cloud au moment de la requête.
  • La configuration est extraite, et non envoyée. La configuration de l'outil MCP est générée par le plan de contrôle Apigee et récupérée par un composant de votre cluster selon une planification. Le plan de contrôle Apigee n'initie jamais de connexion à votre cluster. Consultez Exigences réseau sortant pour connaître les points de terminaison exacts que la sortie de votre cluster doit autoriser.

Principales fonctionnalités de MCP dans Apigee

MCP dans Apigee propose des fonctionnalités de découverte, de sécurité et de gouvernance des outils. Ces fonctionnalités vous aident à gérer la façon dont les applications agentiques interagissent avec vos services.

Découverte d'outils simplifiée avec le hub d'API

Vous pouvez découvrir les points de terminaison MCP disponibles pour les services Apigee à l'aide d'un service d'annuaire accessible via une interface REST. Chaque point de terminaison MCP est également compatible avec la méthode MCP tools/list, qui permet aux clients MCP de découvrir les outils disponibles dans ce point de terminaison.

De plus, MCP s'intègre au hub d'API Apigee. Lorsqu'un proxy de découverte MCP est déployé, le hub d'API ingère automatiquement sa spécification OpenAPI, lui attribue le style d'API MCP et mappe les opérations d'API à des outils MCP individuels. Cela permet aux développeurs de filtrer facilement les API compatibles avec MCP dans le hub d'API et d'utiliser la recherche sémantique avec des requêtes en langage naturel pour trouver les outils adaptés à leurs applications agentiques.

Sécurité

MCP dans Apigee inclut plusieurs niveaux de sécurité pour protéger vos services. Vous pouvez contrôler l'accès à l'aide de l'authentification, de l'autorisation, des limites du réseau et de l'analyse du contenu.

Authentification

Les points de terminaison MCP hébergés par Apigee sont compatibles avec OAuth 2.1 et OpenID Connect (OIDC) pour l'authentification. Ainsi, seuls les agents, les clients MCP et les utilisateurs finaux disposant d'identités établies peuvent accéder à vos points de terminaison MCP et appeler les outils MCP. Les métadonnées de ressources protégées permettent aux clients de découvrir les serveurs d'autorisation OAuth.

Règles d'autorisation précises

Vous pouvez limiter l'accès à vos outils MCP en fonction des identités des clients OAuth. Par exemple, vous pouvez configurer une règle dans votre proxy MCP Discovery pour spécifier que seuls les agents désignés avec des identités client connues peuvent accéder à un outil MCP pour un service de paiement.

Responsabilité du client concernant les appels d'outils

Les applications clientes MCP sont responsables de l'application de la supervision humaine des appels d'outils, par exemple en invitant l'utilisateur avant d'exécuter des opérations de mutation d'état. Pour en savoir plus, consultez la documentation sur le protocole de contexte du modèle.

Observabilité et analyse

Pour les points de terminaison hébergés par Apigee, vous pouvez utiliser Apigee Analytics pour afficher des informations détaillées sur l'utilisation de vos outils MCP. Analytics vous permet de segmenter le trafic spécifique à MCP du trafic API standard et d'afficher les métriques au niveau de chaque outil, comme le volume de requêtes tools/list (découverte) par rapport aux requêtes tools/call (exécution). Les métriques de performances vous aident également à faire la distinction entre la surcharge du proxy et le temps de réponse cible, ce qui vous permet d'identifier plus efficacement les goulots d'étranglement.

Fiabilité et dépannage

Pour faciliter le dépannage et offrir une meilleure visibilité sur le processus de déploiement, Apigee affiche des erreurs d'infrastructure et de configuration spécifiques dans l'UI. Si un déploiement échoue en raison d'une spécification OpenAPI non valide ou d'un problème d'infrastructure régionale, l'interface utilisateur fournit des informations exploitables pour vous aider à résoudre le problème sans avoir besoin de l'intervention de l'assistance.

Utiliser MCP avec Apigee

Vous pouvez exposer vos API Apigee existantes en tant qu'outils MCP et les rendre accessibles via des points de terminaison MCP. Ces points de terminaison peuvent être configurés au niveau de chaque hôte ou de chaque groupe d'environnements. Par exemple, si votre organisation cymbal comporte huit noms d'hôte (par exemple, api.cymbal.com, partners.cymbal.com), chacun associé à un groupe d'environnement différent, vous pouvez héberger un serveur MCP dédié pour chaque nom d'hôte.

Un point de terminaison cible géré (ORG_NAME.mcp.apigee.internal) est déployé à l'aide d'un proxy MCP Discovery spécialisé dans votre organisation Apigee, où vos serveurs MCP sont mis à disposition.

Le tableau suivant montre comment les clients, y compris l'organisation fictive de cymbales, peuvent configurer plusieurs points de terminaison MCP à l'aide d'Apigee.

Client Nom d'hôte et chemin de base MCP Point de terminaison cible du serveur MCP proxy d'API Environnement / Groupe d'environnements
cymbale api.cymbal.com/mcp cymbal.mcp.apigee.internal
(projet locataire de l'organisation Cymbal)		 mcp-api-proxy1 prod/prod-env-group
api-internal.cymbal.com/mcp cymbal.mcp.apigee.internal
(projet locataire de l'organisation Cymbal)		 mcp-api-proxy2 internal/internal-env-group
api-service.cymbal.com/mcp cymbal.mcp.apigee.internal
(projet locataire de l'organisation Cymbal)		 mcp-api-proxy3 dev/dev-env-group

Limites

Les limites suivantes s'appliquent à MCP dans Apigee :

  • Le nombre d'outils MCP dans une organisation Apigee est limité à 1 000.
  • Le déploiement de l'infrastructure MCP peut être soumis à des limites de capacité dans les régions suivantes :
    • europe-central2
    • europe-southwest1
    • europe-west9
    • me-central2

    Si une erreur de provisionnement s'affiche ou si l'état du provisionnement ne passe jamais à Déployé, cela peut être dû à des limites temporaires de capacité d'infrastructure dans la région sélectionnée. Essayez de déployer le proxy dans un environnement situé dans une autre région.

  • MCP dans Apigee est compatible avec les versions OpenAPI suivantes : 3.0.0, 3.0.1 et 3.0.2. 3.0.3.
  • Les insights sur les API dans le hub d'API Apigee ne sont pas disponibles pour les API et outils MCP déployés dans les organisations Apigee avec VPC-SC activé.
  • Les appels GET sur les réponses d'erreur MCP renvoient une erreur 405, car le serveur MCP n'est actuellement pas compatible avec les flux d'événements envoyés par le serveur (SSE).
  • Les insights sur les API du hub d'API Apigee n'afficheront pas les API de style MCP ni le trafic pour les ressources MCP tant que la version 1-17-0-apigee-6 d'Apigee n'aura pas été entièrement déployée dans toutes les régions disponibles.
  • Vous ne pouvez pas définir l'attribut de style d'API sur MCP pour une ressource d'API qui comporte déjà des opérations d'API.

Limites spécifiques à Apigee hybrid

Les limites suivantes s'appliquent au MCP dans Apigee hybrid :

  • Le nombre d'outils MCP est limité par la taille, et non par un nombre fixe. Contrairement à Apigee (qui applique un nombre maximal fixe d'outils MCP par organisation), Apigee hybrid limite la capacité des outils à l'aide de quatre limites de taille : la taille du fichier de spécification OpenAPI, la taille du bundle de proxy MCP, la taille de la réponse tools/list par nom d'hôte et le nombre de noms d'hôte par groupe d'environnements. Pour la plupart des spécifications OpenAPI, vous pouvez généralement vous attendre à ce que 10 000 outils MCP par organisation soient compatibles avec la limite de taille de réponse par défaut. La capacité réelle varie en fonction de la forme spécifique de votre spécification (dominée par le nombre de paramètres et les propriétés du corps de la requête, ainsi que par la longueur de la description). Les schémas de réponse ne sont pas pris en compte dans le budget. Pour estimer la capacité de vos spécifications OpenAPI spécifiques et consulter les quatre limites strictes et leurs modes d'échec, consultez Estimer la capacité de l'outil MCP.
  • L'activation ou la désactivation du MCP déclenche une version Canary progressive des pods MessageProcessor. L'opérateur Apigee met à jour la spécification du pod Processeur de messages lorsque vous activez ou désactivez MCP. Le contrôleur Processeur de messages ApigeeDeployment exécute la modification via une version Canary par étapes plutôt que via un redémarrage progressif Kubernetes standard. La version n'est déclenchée que lors des transitions d'activation et de désactivation, et non lors de l'activité de déploiement MCP en cours ni du trafic MCP à l'état stable. Planifiez l'activation initiale et les désactivations ultérieures pendant un intervalle de maintenance approuvé.
  • Le dimensionnement des ressources de pod MCP est géré par le client. Les pods MCP s'exécutent avec les demandes et les limites de ressources définies par les valeurs par défaut intégrées dans les charts Helm Apigee hybrid. Si votre charge de travail nécessite plus de capacité, ajustez le CPU et la mémoire dans overrides.yaml. Consultez la documentation de référence sur les champs overrides.yaml pour connaître les champs disponibles.
  • Un plan de données MCP par organisation Apigee et par cluster. Dans la version 1.17.0, l'opérateur Apigee provisionne un plan de données MCP pour chaque organisation Apigee installée dans le cluster. Un cluster qui héberge plusieurs organisations Apigee exécute un plan de données MCP par organisation. Les plans de données sont indépendants et ne partagent pas de configuration.
  • L'activation uniforme dans un groupe d'environnements est requise. Activez MCP de manière uniforme sur tous les clusters desservant le même groupe d'environnements Apigee. Si MCP est activé sur certains clusters d'un groupe, mais pas sur d'autres, les requêtes MCP qui sont acheminées vers un cluster sur lequel MCP n'est pas activé recevront une réponse 503 Service Unavailable.
  • TLS unidirectionnel entre le processeur de messages et le plan de données MCP. La version 1.17.0 utilise le protocole TLS unidirectionnel entre le processeur de messages et le plan de données MCP.
  • Le plan de données MCP s'appuie sur le processeur de messages pour l'identité de l'appelant. Le plan de données MCP dans le cluster n'authentifie pas indépendamment ses appelants dans 1.17.0. Il part du principe que les requêtes qui lui parviennent ont déjà été authentifiées par un proxy Apigee exécuté dans le processeur de messages. Chaque requête MCP qui doit être authentifiée doit arriver via un proxy MCP Apigee qui applique une règle d'authentification (voir Gérer l'accès à l'outil MCP). Les clients en production doivent appliquer des contrôles d'entrée de cluster afin que seuls les pods Processeur de messages (libellé Kubernetes app=apigee-runtime dans le même espace de noms Kubernetes où Apigee hybrid est installé) puissent accéder au service MCP sur le port TCP 443. Utilisez le moteur de règles compatible avec votre plate-forme (Kubernetes NetworkPolicy, Cilium, Calico, Istio AuthorizationPolicy) pour appliquer cette restriction.

Étapes suivantes