Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'
Apigee Edge.
Cette page explique comment utiliser les produits d'API Apigee pour contrôler l'accès aux outils MCP. Que vous utilisiez le proxy de découverte Apigee MCP ou que vous redirigiez le trafic vers votre propre serveur MCP, vous pouvez authentifier les clients MCP, appliquer des quotas par outil et filtrer la visibilité des outils en fonction de la configuration du produit d'API.
Les serveurs MCP utilisent un seul point de terminaison (par exemple, /mcp) pour toutes les invocations d'outils. Contrairement aux API REST, où les opérations sont distinguées par le chemin d'URL et la méthode HTTP, MCP intègre l'opération dans le corps de la requête JSON-RPC. Apigee utilise la règle ParsePayload pour extraire ces opérations afin que les règles standards de gestion des API (authentification, application des quotas et filtrage des outils) puissent être appliquées pour chaque outil.
Présentation
Pour gérer l'accès à l'outil MCP avec des produits d'API, procédez comme suit :
- Ajoutez la règle ParsePayload pour extraire le nom de l'outil MCP du corps de la requête.
- Configurez un produit d'API avec des opérations d'outil MCP et des quotas par outil.
- Enregistrez une application de développeur pour obtenir les identifiants client.
- Ajoutez des règles d'authentification (clé API ou OAuth 2.0) pour vérifier les identifiants client par rapport au produit d'API.
- Ajoutez une règle de quota pour appliquer des limites de débit par outil.
- Filtrage de l'outil de test pour confirmer que les réponses
tools/listsont filtrées en fonction de la configuration du produit d'API.
Ajouter la règle ParsePayload
La règle ParsePayload analyse le corps de la requête JSON-RPC et extrait l'opération MCP, telle que tools/call/get_weather ou tools/list. L'opération extraite est stockée dans une variable de flux précédée du nom de la règle (par exemple, parsepayload.ParsePayload-MCP.operation), que les règles en aval utilisent pour l'authentification et l'application des quotas.
Ajoutez la règle ParsePayload suivante au PreFlow de requête de votre proxy MCP :
<ParsePayload name="ParsePayload-MCP"> <DisplayName>Parse MCP Payload</DisplayName> <Source>request</Source> <PayloadType>JSON-RPC-2.0</PayloadType> <Protocol>MCP</Protocol> </ParsePayload>
Où :
<Source>: message à analyser. La valeur par défaut estrequest.<PayloadType>: format de la charge utile. Doit êtreJSON-RPC-2.0.<Protocol>: protocole à utiliser pour l'analyse. Doit être défini surMCPpour les serveurs MCP.
Après l'exécution, la règle renseigne les variables de flux précédées du nom de l'instance de la règle, selon le modèle parsepayload.policyName.suffix.
Pour une règle nommée ParsePayload-MCP, les variables suivantes sont définies :
| Variable de flux | Description | Exemple de valeur |
|---|---|---|
parsepayload.ParsePayload-MCP.operation |
Nom de l'opération dérivée utilisée pour la mise en correspondance des produits d'API et l'application des quotas. | tools/call/get_weather |
parsepayload.ParsePayload-MCP.json-rpc.request.method |
Champ method JSON-RPC de la requête. |
tools/call |
parsepayload.ParsePayload-MCP.json-rpc.request.id |
Champ id JSON-RPC de la requête. |
1 |
parsepayload.ParsePayload-MCP.json-rpc.request.params.name |
Champ params.name de la requête. |
get_weather |
Configurer un produit d'API avec des opérations d'outil MCP
Un produit d'API définit les outils MCP auxquels une application cliente peut accéder et les limites de quota pour chaque outil. Vous configurez les opérations de l'outil MCP à l'aide du champ payloadOperationGroup dans la définition du produit d'API.
Chaque entrée de payloadOperationGroup.operationConfigs spécifie :
- Proxy d'API qui dessert les outils MCP (
apiSource). - Une ou plusieurs opérations d'outil (par exemple,
tools/call/get_stock_price,tools/list). - Quota facultatif pour cet ensemble d'opérations.
Utilisez l'appel d'API suivant pour créer un produit d'API avec des opérations d'outil MCP :
curl -X POST \ "https://apigee.googleapis.com/v1/organizations/ORG_NAME/apiproducts" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ -d '{ "name": "PRODUCT_NAME", "displayName": "PRODUCT_DISPLAY_NAME", "approvalType": "auto", "payloadOperationGroup": { "operationConfigs": [ { "apiSource": "MCP_PROXY_NAME", "operations": [ { "operation": "tools/call/get_stock_price" }, { "operation": "tools/call/get_company_news" } ], "quota": { "limit": "100", "interval": "1", "timeUnit": "minute" } }, { "apiSource": "MCP_PROXY_NAME", "operations": [ { "operation": "tools/list" } ], "quota": { "limit": "300", "interval": "1", "timeUnit": "minute" } } ] } }'
Où :
ORG_NAMEest le nom de votre organisation Apigee.PRODUCT_NAMEest le nom interne du produit d'API.PRODUCT_DISPLAY_NAMEcorrespond au nom à afficher du produit d'API.MCP_PROXY_NAMEest le nom du proxy d'API qui achemine le trafic vers votre serveur MCP. Il peut s'agir d'un proxy de découverte MCP Apigee ou d'un proxy avec votre propre serveur MCP comme backend.
Configurer des quotas par outil
Vous pouvez configurer différents quotas pour chaque outil. Par exemple, la configuration suivante limite get_stock_price à 300 appels par minute, mais restreint get_company_news à seulement trois appels par minute :
{ "payloadOperationGroup": { "operationConfigs": [ { "apiSource": "MCP_PROXY_NAME", "operations": [ { "operation": "tools/call/get_stock_price" } ], "quota": { "limit": "300", "interval": "1", "timeUnit": "minute" } }, { "apiSource": "MCP_PROXY_NAME", "operations": [ { "operation": "tools/call/get_company_news" } ], "quota": { "limit": "3", "interval": "1", "timeUnit": "minute" } }, { "apiSource": "MCP_PROXY_NAME", "operations": [ { "operation": "tools/list" } ], "quota": { "limit": "300", "interval": "1", "timeUnit": "minute" } } ] } }
Vous pouvez créer plusieurs produits d'API avec différents sous-ensembles d'outils pour proposer un accès par niveau.
Par exemple, un produit Basic peut n'inclure que tools/call/get_stock_price, tandis qu'un produit Premium inclut tous les outils disponibles avec des quotas plus élevés. Chaque application de développeur est associée à un ou plusieurs produits d'API. Ainsi, différents clients ont automatiquement accès à différents ensembles d'outils avec des limites de fréquence indépendantes.
Enregistrer l'application d'un développeur
Pour obtenir une clé API ou des identifiants OAuth à des fins de test, enregistrez un développeur et créez une application de développeur associée au produit d'API que vous avez créé à l'étape précédente.
- Enregistrez un développeur d'applications dans votre organisation Apigee.
- Créez une application de développeur et associez-la à votre produit d'API.
- Obtenez la clé client (clé API) à partir des identifiants de l'application. Utilisez cette clé dans les exemples d'authentification qui suivent.
Ajouter des règles d'authentification
Après avoir ajouté la règle ParsePayload, ajoutez une règle d'authentification pour vérifier que le client est autorisé à utiliser l'outil MCP demandé. Apigee fait correspondre l'opération extraite aux opérations définies dans le produit d'API du client.
Si l'outil demandé ne figure pas dans le produit API du client, Apigee renvoie une erreur 401 Unauthorized.
Option 1 : Authentification par clé API
Utilisez la règle VerifyAPIKey pour authentifier les clients à l'aide d'une clé API. Ajoutez cette règle au PreFlow de requête après la règle ParsePayload :
<VerifyAPIKey name="VerifyAPIKey-1"> <DisplayName>Verify API Key</DisplayName> <APIKey ref="request.queryparam.apikey"/> </VerifyAPIKey>
Le client transmet la clé API en tant que paramètre de requête lorsqu'il appelle le proxy MCP :
curl -X POST "https://RUNTIME_HOSTNAME/mcp?apikey=API_KEY" \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "get_stock_price", "arguments": { "ticker": "GOOGL" } }, "id": 1 }'
Vous pouvez également configurer la règle pour lire la clé API à partir d'un en-tête :
<VerifyAPIKey name="VerifyAPIKey-1"> <DisplayName>Verify API Key</DisplayName> <APIKey ref="request.header.x-api-key"/> </VerifyAPIKey>
Option 2 : Authentification OAuth 2.0
Utilisez la règle OAuthV2 avec l'opération VerifyAccessToken pour authentifier les clients à l'aide de jetons d'accès OAuth 2.0. Ajoutez cette règle au PreFlow de requête après la règle ParsePayload :
<OAuthV2 name="OAuthV2-VerifyAccessToken"> <DisplayName>Verify OAuth Access Token</DisplayName> <Operation>VerifyAccessToken</Operation> </OAuthV2>
Le client transmet le jeton d'accès dans l'en-tête Authorization :
curl -X POST "https://RUNTIME_HOSTNAME/mcp" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -d '{ "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "get_stock_price", "arguments": { "ticker": "GOOGL" } }, "id": 1 }'
Pour en savoir plus sur la configuration d'OAuth 2.0 dans Apigee, consultez Premiers pas avec OAuth2.
Ajouter une règle Quota
Ajoutez une règle de Quota pour appliquer les limites de débit par outil définies dans le produit d'API.
La règle utilise UseQuotaConfigInAPIProduct pour appliquer automatiquement la configuration de quota à partir de l'opération de produit d'API correspondante.
Ajoutez la règle de quota suivante au PreFlow de la requête après la règle d'authentification :
<Quota name="Quota-PerToolLimit"> <DisplayName>Per-Tool Quota</DisplayName> <UseQuotaConfigInAPIProduct stepName="AUTH_POLICY_STEP_NAME"/> <Distributed>true</Distributed> </Quota>
Où AUTH_POLICY_STEP_NAME correspond à la valeur de l'attribut name dans l'élément XML de la règle d'authentification (VerifyAPIKey-1 ou OAuthV2-VerifyAccessToken dans les exemples de cette page). Il doit correspondre à l'attribut name de la règle, et non à <DisplayName>.
Avec cette configuration, chaque opération d'outil est limitée en termes de fréquence de manière indépendante en fonction du quota défini dans le produit d'API. Par exemple, si tools/call/get_stock_price a un quota de 300 requêtes par minute et tools/call/get_company_news un quota de 3 requêtes par minute, chaque limite est appliquée séparément, même si les deux outils sont accessibles via le même proxy.
Terminer la configuration du proxy
L'exemple suivant montre la configuration complète du PreFlow de la requête pour un proxy MCP avec ParsePayload, l'authentification par clé API et l'application de quotas par outil :
<ProxyEndpoint name="default"> <PreFlow> <Request> <Step> <Name>ParsePayload-MCP</Name> </Step> <Step> <Name>VerifyAPIKey-1</Name> </Step> <Step> <Name>Quota-PerToolLimit</Name> </Step> </Request> </PreFlow> <HTTPProxyConnection> <BasePath>/mcp</BasePath> </HTTPProxyConnection> <RouteRule name="default"> <TargetEndpoint>default</TargetEndpoint> </RouteRule> </ProxyEndpoint>
Filtrage des outils
Lorsqu'un client envoie une requête tools/list via un proxy MCP avec une clé API ou une authentification OAuth, Apigee filtre automatiquement la réponse pour n'inclure que les outils enregistrés dans le produit d'API du client.
Par exemple, si le produit d'API d'un client inclut les opérations tools/call/get_stock_price et tools/call/get_company_news, une réponse tools/list du serveur MCP sera filtrée pour ne renvoyer que get_stock_price et get_company_news, même si le serveur MCP expose des outils supplémentaires.
Ce filtrage est effectué par défaut lorsque la configuration suivante est en place. Aucune règle de filtrage dédiée n'est requise :
- Le PreFlow de la requête inclut ParsePayload et une règle d'authentification (VerifyAPIKey ou OAuthV2).
- Le produit d'API inclut
tools/listdanspayloadOperationGroup. - Le produit d'API spécifie les opérations d'outil (par exemple,
tools/call/get_stock_price) auxquelles le client est autorisé à accéder.
Pour tester le filtrage des outils, envoyez une requête tools/list avec la clé API du client :
curl -X POST "https://RUNTIME_HOSTNAME/mcp?apikey=API_KEY" \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }'
Si le produit d'API inclut tools/call/get_stock_price et tools/call/get_company_news, la réponse filtrée ressemble à ce qui suit, même si le serveur MCP expose des outils supplémentaires :
{ "jsonrpc": "2.0", "result": { "tools": [ { "name": "get_stock_price", "description": "Get the current stock price for a given ticker symbol.", "inputSchema": { "type": "object", "properties": { "ticker": { "type": "string", "description": "Stock ticker symbol" } }, "required": ["ticker"] } }, { "name": "get_company_news", "description": "Get recent news articles for a company.", "inputSchema": { "type": "object", "properties": { "company": { "type": "string", "description": "Company name" } }, "required": ["company"] } } ] }, "id": 1 }
Les outils qui ne figurent pas dans le produit d'API (par exemple, delete_account ou admin_reset) sont automatiquement supprimés de la réponse.
La session de débogage suivante montre l'étape McpToolsFilterExecution dans le flux de réponse, avec la propriété mcp_flow_info.mcp.allowed.tools listant les outils autorisés par le produit d'API :
Utiliser des flux conditionnels pour la logique par outil
Utilisez des flux conditionnels lorsque vous avez besoin d'une logique par outil au-delà de ce que fournissent les quotas de produits d'API, par exemple pour appliquer des taux SpikeArrest spécifiques à un outil, pour effectuer un routage vers différents backends ou pour ajouter des transformations de requêtes pour des outils spécifiques. Les flux conditionnels utilisent la variable de flux parsepayload.policyName.operation pour correspondre à l'opération MCP extraite.
Pour une règle ParsePayload nommée ParsePayload-MCP :
<Flows> <Flow name="ListTools"> <Condition>(parsepayload.ParsePayload-MCP.operation = "tools/list")</Condition> <Request/> </Flow> <Flow name="GetStockPrice"> <Condition>(parsepayload.ParsePayload-MCP.operation = "tools/call/get_stock_price")</Condition> <Request> <Step> <Name>SpikeArrest-StockPrice</Name> </Step> </Request> </Flow> <Flow name="GetCompanyNews"> <Condition>(parsepayload.ParsePayload-MCP.operation = "tools/call/get_company_news")</Condition> <Request> <Step> <Name>SpikeArrest-CompanyNews</Name> </Step> </Request> </Flow> </Flows>
Déboguer la configuration du proxy
Utilisez l'outil Debug d'Apigee pour vérifier que la règle ParsePayload extrait correctement l'opération MCP et que les règles d'authentification et de quota fonctionnent comme prévu.
Dans la session de débogage, recherchez les variables de flux suivantes après l'étape de la règle ParsePayload (où ParsePayload-MCP est le nom de la règle) :
parsepayload.ParsePayload-MCP.operation: doit contenir le nom complet de l'opération (par exemple,tools/call/get_stock_price).parsepayload.ParsePayload-MCP.json-rpc.request.method: doit contenir la méthode JSON-RPC (par exemple,tools/call).
Limites
- La règle "ParsePayload" n'accepte que
JSON-RPC-2.0comme type de charge utile. - Les opérations d'outil de produit d'API ne sont compatibles qu'avec les méthodes
tools/callettools/list. Le filtrage des outils pour les réponsestools/listne s'applique qu'aux opérationstools/callconfigurées dans le produit d'API. - La règle ParsePayload analyse l'intégralité du corps de la requête. Apigee applique une limite de taille par défaut de 10 Mo pour le corps des requêtes, qui peut être configurée jusqu'à 30 Mo à l'aide de la propriété
request.payload.parse.limit. Pour en savoir plus, consultez la documentation de référence sur les propriétés des points de terminaison. - La règle ParsePayload avec le protocole MCP n'analyse que les charges utiles des requêtes JSON-RPC (contenant les champs
methodetparams). Les charges utiles de réponse MCP ne sont pas analysées. - Le filtrage des outils pour les réponses
tools/listnécessite les règles ParsePayload et d'authentification dans le PreFlow de la requête.
Étapes suivantes
- Pour en savoir plus sur MCP dans Apigee, consultez Présentation de MCP dans Apigee.
- Pour commencer à utiliser les proxys MCP, consultez Premiers pas avec Apigee et MCP.
- En savoir plus sur les produits d'API et la gestion des produits d'API
- En savoir plus sur la limitation du débit dans Apigee.
- En savoir plus sur l'authentification par clé API et OAuth 2.0