View a markdown version of this page

Contrato de protocolo MCP - Base da Amazônia AgentCore

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Contrato de protocolo MCP

Entenda os requisitos para implementar o Model Context Protocol (MCP) para que os agentes possam chamar ferramentas e servidores de agentes.

Por exemplo, código, consulte Implantar servidores MCP em AgentCore tempo de execução.

Requisitos de implementação do protocolo

Seu servidor MCP deve implementar esses requisitos de protocolo específicos:

  • Transporte: o Streamable-http transporte é necessário. Por padrão, use o modo sem estado (stateless_http=True) para compatibilidade com o gerenciamento AWS de sessões e o balanceamento de carga.

  • Gerenciamento de sessão: a plataforma adiciona automaticamente o Mcp-Session-Id cabeçalho para isolamento da sessão. No modo sem estado, os servidores devem oferecer suporte à operação sem estado para não rejeitar o cabeçalho gerado pela Mcp-Session-Id plataforma.

dica

O Amazon Bedrock AgentCore também oferece suporte a servidores MCP com estado (stateless_http=False) que permitem recursos como elicitação (interações de vários usuários) e amostragem (conteúdo). LLM-generated Para a versão do protocolo MCP 2025-11-25 e anteriores, o modo de estado é necessário para elicitação e amostragem, porque o servidor entrega essas solicitações em uma sessão aberta. Para a versão 2026-07-28 e posterior, a elicitação e a amostragem usam o padrão de várias solicitações de ida e volta (MRTR), que não exige o modo de estado. Para obter mais informações sobre o MRTR, consulte Várias solicitações de ida e volta na documentação do Model Context Protocol.

O modo de estado carrega o estado dentro de uma sessão MCP em várias solicitações. Um servidor MCP sem estado mantém o estado em um repositório de apoio gerenciado pelo aplicativo, como um banco de dados. Ele usa identificadores de estado explícitos para fazer referência a esse estado. O servidor retorna um identificador de estado em um resultado de ferramenta e o cliente o devolve em chamadas posteriores à ferramenta para inserir a chave na loja. Para obter mais informações sobre identificadores de estado explícitos, consulte identificadores de estado explícitos na documentação do Model Context Protocol. Para obter mais informações sobre servidores MCP com estado, consulte Recursos do servidor MCP com estado.

Gerenciamento de sessões de MCP e aderência de microVM

O Model Context Protocol (MCP) usa o Mcp-Session-Id cabeçalho para gerenciar o estado da sessão e rotear solicitações. Para a especificação MCP, consulte MCP Streamable HTTP Transport.

Stickiness da microVM: o Amazon Bedrock AgentCore usa o Mcp-Session-Id cabeçalho para rotear solicitações para a mesma instância de microVM. Os clientes devem capturar o Mcp-Session-Id retornado na resposta e incluí-lo em todas as solicitações subsequentes para garantir a afinidade da sessão. Sem um ID de sessão consistente, cada solicitação pode ser roteada para uma nova microVM, o que pode resultar em latência adicional devido às partidas a frio.

MCP apátrida ()stateless_http=True:

  • A plataforma gera o Mcp-Session-Id e o inclui na solicitação ao seu servidor MCP.

  • Seu servidor MCP deve aceitar a ID de sessão fornecida pela plataforma (não a rejeite).

  • A plataforma retorna o mesmo Mcp-Session-Id para o cliente na resposta.

  • O cliente deve incluir esse ID de sessão em todas as solicitações subsequentes de afinidade com microVM.

MCP com estado ()stateless_http=False:

  • O cliente envia a solicitação de inicialização sem um Mcp-Session-Id cabeçalho.

  • A plataforma retorna Mcp-Session-Id na resposta.

  • O cliente deve incluir isso Mcp-Session-Id em todas as solicitações subsequentes para o estado da sessão e a afinidade com a microVM.

Para obter mais detalhes sobre o gerenciamento de sessões MCP com estado, consulte a especificação de gerenciamento de sessões MCP.

nota

Em ambos os modos, o Amazon Bedrock AgentCore sempre retorna um Mcp-Session-Id cabeçalho aos clientes. Sempre capture e reutilize esse cabeçalho para obter o desempenho ideal.

Requisitos de container

Seu servidor MCP deve ser implantado como um aplicativo em contêiner que atenda às seguintes especificações:

  • Host: 0.0.0.0

  • Porta: 8000 - Porta padrão para comunicação com o servidor MCP (diferente do protocolo HTTP)

  • Plataforma: contêiner ARM64 - necessário para compatibilidade com o ambiente de execução AWS Amazon Bedrock AgentCore

Requisitos de caminho

/mcp - PUBLICAR

Finalidade

Recebe mensagens MCP RPC e as processa por meio dos recursos da ferramenta do seu agente, passagem completa da carga útil da InvokeAgentRuntime API com mensagens RPC MCP padrão

Formato de resposta

JSON-RPC request/response formato baseado, suportando ambos application/json e text/event-stream como tipos de conteúdo de resposta

Casos de uso

O /mcp endpoint serve a vários propósitos principais:

  • Invocação e gerenciamento de ferramentas

  • Descoberta da capacidade do agente

  • Acesso e manipulação de recursos

  • Multi-step fluxos de trabalho do agente

Tratamento de erros

Os servidores MCP retornam erros como respostas de erro padrão JSON-RPC 2.0. A maioria dos erros é transmitida no JSON-RPC error objeto com um código de status HTTP 200, conforme exigido pela especificação MCP. Somente erros de autenticação, autorização e solicitação em nível de protocolo usam códigos de status HTTP diferentes de 200. A tabela a seguir mapeia cada exceção de tempo de execução para seu código de JSON-RPC erro, código de status HTTP e mensagem. Algumas exceções compartilham um código de JSON-RPC erro, mas retornam mensagens diferentes, então elas são listadas como linhas separadas.

JSON-RPC Código de erro Exceção de execução Código de erro HTTP Mensagem de erro

-32001

UnauthorizedException

401

Erro de autenticação - Credenciais inválidas

-32002

AccessDeniedException

403

Erro de autorização - Permissões insuficientes

-32003

ThrottlingException

200

Limite de taxa excedido - Muitas solicitações

-32003

ServiceQuotaExceededException

200

Limite de taxa excedido - Muitas solicitações

-32004

ResourceNotFoundException

200

Recurso não encontrado - O recurso solicitado não existe

-32005

ConflictException

200

Conflito de recursos - O recurso já existe

-32005

RetryableConflictException

200

Operação da sessão em andamento, tente novamente

-32006

ValidationException

200

Erro de validação - dados de solicitação inválidos

-32010

RuntimeClientError

200

Erro de execução da ferramenta - Verifique seus CloudWatch registros para obter mais informações

-32011

McpRequestUnacceptableException

406

Erro de cabeçalho de aceitação - o protocolo MCP requer o cabeçalho de aceitação: application/json, text/event -stream

-32603

Qualquer outra exceção

200

Erro interno - Erro do servidor

ConflictExceptione RetryableConflictException ambos usam código JSON-RPC de erro -32005 (HTTP 200), mas são diferenciados por sua mensagem. O serviço retorna RetryableConflictException (Session operation in progress, please retry) quando uma segunda operação tem como alvo uma sessão enquanto o serviço está provisionando ou desativando essa sessão. Como o MCP retorna HTTP 200 com o erro no JSON-RPC corpo, o chamador deve inspecionar o corpo da resposta e tentar novamente com um pequeno recuo exponencial — os clientes MCP não tentam novamente automaticamente.

Exemplo de resposta de erro:

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

Respostas de autenticação OAuth

OAuth-configured os agentes seguem os padrões de autenticação RFC 6749 (OAuth 2.0). Quando a autenticação está ausente, o serviço retorna uma resposta 401 não autorizada com um WWW-Authenticate cabeçalho (de acordo com a RFC 7235), permitindo que os clientes descubram os endpoints do servidor de autorização por meio da API. GetRuntimeProtectedResourceMetadata

401 Não autorizado

Retornado quando o cabeçalho de autorização está ausente ou vazio.

A resposta inclui WWW-Authenticate cabeçalho:

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

SigV4-configured os agentes retornam HTTP 403 com um ACCESS_DENIED erro e não incluem WWW-Authenticate cabeçalhos.