View a markdown version of this page

Contrat de protocole MCP - Amazon Bedrock AgentCore
Exigences de mise en œuvre du protocoleExigences relatives aux contenantsExigences relatives au cheminRéponses d'authentification OAuth

Contrat de protocole MCP

Comprenez les exigences relatives à la mise en œuvre du protocole MCP (Model Context Protocol) afin que les agents puissent appeler des outils et des serveurs d'agents.

Pour un exemple de code, voir Déployer des serveurs MCP dans AgentCore Runtime.

Exigences de mise en œuvre du protocole

Votre serveur MCP doit implémenter ces exigences de protocole spécifiques :

  • Transport : Streamable-http le transport est obligatoire. Par défaut, utilisez le mode stateless (stateless_http=True) pour assurer la compatibilité avec AWS la gestion des sessions et l'équilibrage de charge.

  • Gestion de session : La plateforme ajoute automatiquement un Mcp-Session-Id en-tête pour l'isolation des sessions. En mode apatride, les serveurs doivent prendre en charge le fonctionnement sans état afin de ne pas rejeter l'en-tête généré par Mcp-Session-Id la plate-forme.

Astuce

Amazon Bedrock prend AgentCore également en charge les serveurs MCP dynamiques (stateless_http=False) qui permettent des fonctionnalités telles que l'élicitation (interactions utilisateur à plusieurs tours) et l'échantillonnage (contenu). LLM-generated Le mode dynamique est requis lorsque votre serveur MCP doit maintenir le contexte de session pour plusieurs demandes au cours d'un même appel d'outil. Pour plus d'informations et des exemples, consultez la section Fonctionnalités du serveur Stateful MCP.

Gestion des sessions MCP et rigidité des microVM

Le Model Context Protocol (MCP) utilise l'Mcp-Session-Iden-tête pour gérer l'état de session et acheminer les demandes. Pour la spécification MCP, voir MCP Streamable HTTP Transport.

MicroVM Stickiness : Amazon Bedrock AgentCore utilise l'Mcp-Session-Iden-tête pour acheminer les demandes vers la même instance de microVM. Les clients doivent saisir le résultat Mcp-Session-Id renvoyé dans la réponse et l'inclure dans toutes les demandes suivantes afin de garantir l'affinité de session. Sans identifiant de session cohérent, chaque demande peut être acheminée vers une nouvelle microVM, ce qui peut entraîner une latence supplémentaire en raison des démarrages à froid.

MCP apatride () stateless_http=True :

  • La plateforme le génère Mcp-Session-Id et l'inclut dans la demande adressée à votre serveur MCP.

  • Votre serveur MCP doit accepter l'ID de session fourni par la plateforme (ne le rejetez pas).

  • La plateforme renvoie la même chose Mcp-Session-Id au client dans la réponse.

  • Le client doit inclure cet ID de session dans toutes les demandes ultérieures d'affinité microVM.

MCP dynamique () stateless_http=False :

  • Le client envoie la demande d'initialisation sans Mcp-Session-Id en-tête.

  • La plateforme renvoie Mcp-Session-Id la réponse.

  • Le client doit l'inclure Mcp-Session-Id dans toutes les demandes ultérieures concernant à la fois l'état de session et l'affinité microVM.

Pour plus de détails sur la gestion dynamique des sessions MCP, consultez la spécification de gestion des sessions MCP.

Note

Dans les deux modes, Amazon Bedrock renvoie AgentCore toujours un Mcp-Session-Id en-tête aux clients. Capturez et réutilisez toujours cet en-tête pour des performances optimales.

Exigences relatives aux contenants

Votre serveur MCP doit être déployé en tant qu'application conteneurisée répondant aux spécifications suivantes :

  • Hôte : 0.0.0.0

  • Port : 8000 - Port standard pour les communications avec le serveur MCP (différent du protocole HTTP)

  • Plateforme : conteneur ARM64 - Nécessaire pour la compatibilité avec l'environnement d' AWS exécution Amazon Bedrock AgentCore

Exigences relatives au chemin

/mcp - POST

Objectif

Reçoit les messages MCP RPC et les traite grâce aux capacités de l'outil de votre agent, transmission complète de la charge utile de l'InvokeAgentRuntimeAPI avec des messages MCP RPC standard

Format de réponse

JSON-RPC request/response format basé, prenant en charge les deux types application/json et en text/event-stream tant que types de contenu de réponse

Cas d’utilisation

Le /mcp point de terminaison répond à plusieurs objectifs clés :

  • Invocation et gestion des outils

  • Découverte des capacités des agents

  • Accès aux ressources et manipulation

  • Multi-step flux de travail des agents

Réponses d'authentification OAuth

OAuth-configured les agents respectent les normes d'authentification RFC 6749 (OAuth 2.0). Lorsque l'authentification est absente, le service renvoie une réponse 401 Unauthorized avec un WWW-Authenticate en-tête (conformément à la RFC 7235), permettant aux clients de découvrir les points de terminaison du serveur d'autorisation via l'API. GetRuntimeProtectedResourceMetadata

401 Accès non autorisé

Renvoyé lorsque l'en-tête d'autorisation est manquant ou vide.

La réponse inclut WWW-Authenticate l'en-tête :

WWW-Authenticate: Bearer resource_metadata="https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{ESCAPED_ARN}/invocations/.well-known/oauth-protected-resource?qualifier={QUALIFIER}"
Note

SigV4-configured les agents renvoient le HTTP 403 avec une ACCESS_DENIED erreur et n'incluent pas les WWW-Authenticate en-têtes.