Cibles des serveurs MCP
Les serveurs MCP fournissent des outils locaux, un accès aux données ou des fonctions personnalisées pour vos interactions avec les modèles et les agents dans AgentCore Bedrock. Dans Bedrock AgentCore, vous pouvez définir un serveur MCP préconfiguré comme cible lors de la création d'une passerelle.
Les serveurs MCP hébergent des outils, des instructions et des ressources que les agents peuvent découvrir et utiliser. Dans Bedrock AgentCore, vous utilisez une passerelle pour associer des cibles à ces fonctionnalités et les connecter à l'environnement d'exécution de votre agent. Vous vous connectez à des serveurs MCP externes via l'SynchronizeGatewayTargetsAPI qui effectue des handshakes de protocole et indexe les fonctionnalités disponibles. Pour plus d'informations sur l'installation et l'utilisation des serveurs MCP, consultez Amazon Bedrock AgentCore MCP Server : Vibe coding with your coding assistant.
Rubriques
Principales considérations et limites
Mode de liste
ListingMode peut être défini comme DYNAMIC ou DEFAULT pour les cibles du serveur MCP.
-
En mode DYNAMIC, les clients découvrent les fonctionnalités du serveur MCP lorsqu'un utilisateur appelle une opération MCP. Gateway récupère les capacités du serveur en transférant les demandes au serveur MCP. Actuellement, le mode DYNAMIC n'est pas interopérable avec la recherche sémantique ou le protocole OAuth à trois étapes (3LO) sortant.
-
Sauf modification, le mode de liste est défini sur DEFAULT. En mode DEFAULT, les clients découvrent les fonctionnalités du serveur MCP grâce à une opération de synchronisation fournie par l' SynchronizeGatewayTargets API.
Synchronisation implicite
Pour les cibles en mode DEFAULT, CreateGatewayTarget les UpdateGatewayTarget opérations déclenchent automatiquement la découverte et l'indexation des capacités. Lorsque l'une ou l'autre opération est appelée, Gateway récupère les outils disponibles à l'aide des tools/list fonctionnalités de MCP, les invite à les utiliserprompts/list, les ressources utilisent resources/list etresources/templates/list, et ajoute les fonctionnalités renvoyées au catalogue unifié.
Synchronisation explicite
Les catalogues de capacités pour les cibles en mode DEFAULT peuvent être actualisés manuellement en appelant l'SynchronizeGatewayTargetsAPI. Lorsqu'elle est appelée, elle met à jour la liste des fonctionnalités disponibles de la passerelle. Vous devez appeler l'API chaque fois que l'outil, l'invite ou les définitions de ressources d'un serveur MCP changent.
La synchronisation est un mécanisme essentiel pour maintenir des catalogues de capacités précis lors de l'intégration de serveurs MCP. La synchronisation implicite se produit automatiquement lors de la création et de la mise à jour des cibles, lorsque Gateway découvre et indexe immédiatement les outils, les invites et les ressources du serveur MCP afin de garantir la disponibilité des fonctionnalités de recherche sémantique et de liste unifiée. La synchronisation explicite est effectuée à la demande via l'SynchronizeGatewayTargetsAPI, ce qui permet de découvrir le catalogue de fonctionnalités MCP lorsque les serveurs MCP modifient leurs capacités de manière indépendante.
Quand appeler SynchronizeGatewayTargets
Chaque fois que le mode de listage d'une cible de serveur MCP est défini sur DEFAULT, utilisez l'SynchronizeGatewayTargetsAPI une fois que des outils, des invites ou des ressources ont été ajoutés, supprimés ou modifiés. Étant donné que Gateway précalcule les intégrations vectorielles pour la recherche sémantique et gère des catalogues de capacités normalisés, la synchronisation est nécessaire pour garantir que vos utilisateurs puissent découvrir et invoquer les derniers outils, instructions et ressources disponibles.
Comment appeler l'API
Envoyez une requête PUT à /gateways/ {GatewayIdentifier} /synchronisez avec l'ID cible dans le corps de la demande. L'API renvoie immédiatement une réponse 202 et traite la synchronisation de manière asynchrone. Surveillez l'état de la cible GetGatewayTarget pour suivre la progression de la synchronisation, car l'opération peut prendre plusieurs minutes pour de grands ensembles de capacités.
Stratégie d'autorisation
Les types de stratégie d'autorisation suivants sont pris en charge.
-
Aucune autorisation : la passerelle appelle le serveur MCP sans autorisation préconfigurée. Cette approche n'est pas recommandée.
-
OAuth — La passerelle prend en charge à la fois l'OAuth à deux branches (type d'octroi des informations d'identification du client) et l'OAuth à trois étapes (type d'autorisation du code d'autorisation). Vous configurez le fournisseur d'autorisation dans Amazon Bedrock AgentCore Identity dans le même compte et dans la même région pour que la passerelle passe des appels vers le serveur MCP.
-
IAM (AWS Signature Version 4 (Sig V4)) — La passerelle signe les demandes au serveur MCP à l'aide de SigV4 avec les informations d'identification du rôle de service de passerelle. Vous configurez un
IamCredentialProvideravec un nom de service requis pour la signature Sigv4 et une région facultative (par défaut, la région de passerelle). -
Clé d'API — La passerelle utilise un fournisseur d'informations d'identification de clé d'API pour s'authentifier auprès du serveur MCP. Vous configurez le fournisseur de clés d'API dans Amazon Bedrock AgentCore Identity dans le même compte et dans la même région que la passerelle.
Important
L'autorisation sortante IAM (SigV4) nécessite que le serveur MCP soit hébergé derrière un AWS service qui prend en charge nativement l'authentification IAM. La passerelle signe les demandes sortantes avec SigV4 mais ne modifie pas la configuration d'authentification sur la cible. Le service cible doit être en mesure de vérifier les signatures Sigv4.
Les AWS services suivants prennent en charge nativement l'authentification IAM et sont compatibles avec l'autorisation sortante IAM pour les cibles du serveur MCP :
-
Passerelle Amazon Bedrock AgentCore
-
Amazon Bedrock AgentCore Runtime (voir Déployer des serveurs MCP dans AgentCore Runtime)
-
Amazon API Gateway
-
URL des fonctions Lambda
Les services qui ne vérifient pas de manière native les signatures Sigv4, tels que Application Load Balancer ou les points de terminaison directs Amazon EC2, ne sont pas compatibles avec l'autorisation sortante IAM. Si votre serveur MCP est hébergé derrière l'un de ces services, utilisez plutôt OAuth ou l'autorisation par clé API.
Considérations relatives à la configuration des cibles de serveur MCP
Les éléments suivants doivent être configurés.
-
Le serveur MCP doit disposer de fonctionnalités d'outil. Les fonctionnalités d'invite et de ressources sont facultatives et sont synchronisées automatiquement lorsque le serveur les annonce.
-
Les versions du protocole MCP prises en charge sont les suivantes : 2025-06-18, 2025-03-26 et 2025-11-25.
-
Pour ce qui est fourni par URL/endpoint le serveur, l'URL doit être codée. La passerelle utilisera la même URL pour appeler le serveur.
Astuce
Si votre serveur MCP est hébergé sur AgentCore Runtime, activez les sessions MCP sur votre passerelle ou ajoutez-les Mcp-Session-Id comme en-tête de demande et de réponse autorisé dans celui de la cible. metadataConfiguration Cela permet d'éviter une initialisation répétée avec le serveur MCP à chaque demande et de réduire le temps de latence pour les appels d'outils suivants.
Connexion à un serveur OAuth-protected MCP à l'aide du flux de code d'autorisation
Pour prendre en charge le type d'octroi du code d'autorisation (OAuth à trois branches) avec les cibles de serveur MCP, Amazon Bedrock AgentCore Gateway propose deux méthodes de création de cibles.
Synchronisation implicite lors de la création de la cible du serveur MCP
Avec cette méthode, l'utilisateur administrateur complète le flux de code d'autorisation pendant CreateGatewayTarget ou SynchronizeGatewayTargets des opérations à l'aide de l'URL d'autorisation renvoyée dans la réponse. UpdateGatewayTarget Cela permet à Amazon Bedrock AgentCore Gateway de découvrir et de mettre en cache les outils du serveur MCP dès le départ.
Note
Vous ne pouvez pas supprimer, mettre à jour ou synchroniser une cible dont l'état d'autorisation est en attente (CREATE_PENDING_AUTHUPDATE_PENDING_AUTH, ouSYNCHRONIZE_PENDING_AUTH). Attendez que l'autorisation soit terminée ou qu'elle échoue avant d'effectuer d'autres opérations sur la cible.
Fournir un schéma dès le départ lors de la création de la cible du serveur MCP
Avec cette méthode, les utilisateurs administrateurs fournissent le schéma de l'outil directement pendant CreateGatewayTarget les UpdateGatewayTarget opérations utilisant le mcpToolSchema champ, plutôt qu'Amazon Bedrock AgentCore Gateway les récupère dynamiquement depuis le serveur MCP. Amazon Bedrock AgentCore Gateway analyse le schéma fourni et met en cache les définitions des outils.
Note
Vous ne pouvez pas synchroniser une cible pour laquelle un schéma d'outil statique (mcpToolSchema) est configuré. Supprimez le schéma statique via un UpdateGatewayTarget appel pour activer la synchronisation dynamique des outils.
Liaison de session URL
La liaison de session par URL d'autorisation OAuth 2.0 vérifie que l'utilisateur qui a initié la demande d'autorisation OAuth est le même que celui qui a donné son consentement. Une fois que l'utilisateur a donné son consentement, le navigateur est redirigé vers une URL de retour configurée sur la cible avec un URI de session unique. L'application est ensuite chargée d'appeler l'CompleteResourceTokenAuthAPI, en présentant à la fois l'identité de l'utilisateur et l'URI de session. Amazon Bedrock AgentCore Identity vérifie que l'utilisateur qui a lancé le flux est le même que celui qui l'a terminé avant d'échanger le code d'autorisation contre un jeton d'accès.
Cela permet d'éviter un scénario dans lequel un utilisateur partage accidentellement l'URL d'autorisation et où quelqu'un d'autre donne son consentement, ce qui accorderait des jetons d'accès à la mauvaise partie. L'URL d'autorisation et l'URI de session ne sont valides que pendant 10 minutes, ce qui limite encore davantage les possibilités d'utilisation abusive. La liaison de session s'applique lors de la création de la cible (synchronisation implicite) et lors de l'invocation de l'outil.
Note
Lorsque vous effectuez des opérations cibles (créer, mettre à jour ou synchroniser) et que vous autorisez via la console de AWS gestion, l'CompleteResourceTokenAuthappel est effectué au nom du propriétaire de la ressource, aucune autre action n'étant requise après l'autorisation.
Configuration des autorisations
Le rôle IAM que vous utilisez pour créer, mettre à jour ou synchroniser les cibles des serveurs MCP doit disposer des autorisations indiquées dans l'exemple suivant.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:CreateGateway", "bedrock-agentcore:GetGateway", "bedrock-agentcore:CreateGatewayTarget", "bedrock-agentcore:GetGatewayTarget", "bedrock-agentcore:SynchronizeGatewayTargets", "bedrock-agentcore:UpdateGatewayTarget" ], "Resource": "arn:aws:bedrock-agentcore:*:*:*gateway*" }, { "Effect": "Allow", "Action": [ "bedrock-agentcore:CreateWorkloadIdentity", "bedrock-agentcore:GetWorkloadAccessToken", "bedrock-agentcore:GetWorkloadAccessTokenForUserId", "bedrock-agentcore:GetResourceOauth2Token", "bedrock-agentcore:GetResourceApiKey", "bedrock-agentcore:CompleteResourceTokenAuth", "secretsmanager:GetSecretValue" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kms:EnableKeyRotation", "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey*", "kms:ReEncrypt*", "kms:CreateAlias", "kms:DisableKey", "kms:*" ], "Resource": "arn:aws:kms:*:123456789012:key/*" } ] }