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.
Tópicos
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-Idcabeç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 pelaMcp-Session-Idplataforma.
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
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
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-Ide 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-Idpara 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-Idcabeçalho. -
A plataforma retorna
Mcp-Session-Idna resposta. -
O cliente deve incluir isso
Mcp-Session-Idem 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).
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.