Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 :

Gestion des sessions MCP et adhérence des microVM

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

Stickiness de la microVM  : 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 les informations Mcp-Session-Id renvoyées dans la réponse et les 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 :

MCP dynamique () stateless_http=False :

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

Exigences relatives aux conteneurs

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

Exigences relatives au chemin

/mcp - POSTE

Objectif

Reçoit les messages MCP RPC et les traite via les fonctionnalités de l'outil de votre agent, transmission complète de la charge utile de l'InvokeAgentRuntimeAPI avec les messages MCP RPC standard

Format de réponse

JSON-RPC request/response format basé, supportant à la fois les types application/json de contenu et text/event-stream en tant que réponse

Cas d’utilisation

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

Gestion des erreurs

Les serveurs MCP renvoient des erreurs sous forme de réponses d'erreur standard JSON-RPC 2.0. La plupart des erreurs sont contenues dans l' JSON-RPC errorobjet avec un code d'état HTTP 200, comme l'exige la spécification MCP. Seules les erreurs d'authentification, d'autorisation et de demande au niveau du protocole utilisent des codes d'état HTTP autres que 200. Le tableau suivant associe chaque exception d'exécution à son code JSON-RPC d'erreur, à son code d'état HTTP et à son message. Certaines exceptions partagent un code JSON-RPC d'erreur mais renvoient des messages différents. Elles sont donc répertoriées sur des lignes distinctes.

ConflictExceptionet RetryableConflictException les deux utilisent un code JSON-RPC d'erreur -32005 (HTTP 200) mais se distinguent par leur message. Le service return RetryableConflictException (Session operation in progress, please retry) lorsqu'une deuxième opération cible une session pendant que le service provisionne ou supprime cette session. Comme MCP renvoie HTTP 200 avec l'erreur dans le JSON-RPC corps, l'appelant doit inspecter le corps de la réponse et réessayer avec un court délai exponentiel. Les clients MCP ne réessayent pas automatiquement.

Exemple de réponse d'erreur :

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "error": {
    "code": -32005,
    "message": "Session operation in progress, please retry"
  }
}

Réponses d'authentification OAuth

OAuth-configured les agents suivent les normes d'authentification RFC 6749 (OAuth 2.0). Lorsque l'authentification est manquante, 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 Authorization est manquant ou vide.

La réponse inclut un WWW-Authenticate 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}"