AWS ensina o registro de servidores MCP a se atualizar sozinho: esquema de tools sem edições manuais

Todo catálogo interno morre da mesma forma. No início ele é preciso; depois alguém adiciona uma nova função ao serviço e esquece de corrigir o registro, e um mês depois todos recorrem ao código e ao chat, porque ninguém mais confia no catálogo. Com o registro de servidores MCP é a mesma história, só que as consequências são piores: o agente pode chamar uma ferramenta pelo esquema antigo e obter um comportamento incompreensível, sem erro explícito.

A AWS publicou uma análise de como evitar isso no Agent Registry, parte do Amazon Bedrock AgentCore. A ideia é simples: a atualização do registro não deve depender da disciplina do desenvolvedor. Ela deve ser disparada pelo próprio evento de deploy.

Como funciona

A cadeia de cinco serviços é assim.

• O desenvolvedor atualiza o servidor MCP, por exemplo com o comando agentcore deploy. Isso chama a API UpdateAgentRuntime, e o CloudTrail registra a chamada como management event.
• O EventBridge, por meio de uma regra (origem aws.bedrock-agentcore, nome do evento UpdateAgentRuntime), encaminha o evento para um barramento central. Em um esquema multiconta, ele fica na conta do registro.
• A Lambda extrai do evento o ARN do runtime e monta a partir dele a URL de chamada do servidor MCP. A região e o ID da conta ela obtém do mesmo ARN.
• A Lambda obtém um token OAuth via AgentCore Identity: primeiro um workload token para si mesma, depois um token M2M do credential provider da conta correspondente. Não há segredos de cliente nas variáveis de ambiente.
• A Lambda chama initialize e depois tools/list, obtendo a lista atual de ferramentas.
• Em seguida, ela procura o registro cujo esquema contenha o mesmo ARN (ou o ARN codificado, ou a URL) e compara as listas.

Onde há engenharia bem feita

A comparação é feita sem gravações desnecessárias. As ferramentas são ordenadas por nome e reduzidas a três campos: name, description e inputSchema. A gravação no registro só ocorre se esses campos forem diferentes, e os logs mostram exatamente o que foi adicionado ou removido.

Mais dois detalhes úteis. Para cada conta é configurado um credential provider próprio (uma variável do tipo CREDENTIAL_PROVIDER_{ACCT_ID}), de modo que uma única Lambda atende servidores de contas diferentes. E, antes da requisição, o código verifica se a URL começa com https://, o que fecha cenários desagradáveis como file://.

Imagine uma equipe de pagamentos que adicionou ao seu servidor MCP a ferramenta refund_status. Antes, a equipe de suporte descobriria isso pelo chat uma semana depois. Agora, 5–15 minutos após o deploy, o registro já contém a nova ferramenta com o esquema atualizado, e nos logs da Lambda é possível ver o que mudou.

Limitações que vale conhecer

Primeira: o serviço não cria registros. No exemplo, a Lambda atualiza apenas registros já cadastrados no onboarding e que contêm o ARN do runtime em mcpServer.data. Registros com status DRAFT são ignorados; é necessário APPROVED. Isso preserva o processo de aprovação existente, mas o cadastro inicial terá de ser automatizado separadamente.

Segunda: a latência. O CloudTrail entrega eventos em cerca de 5–15 minutos, portanto não serve para o cenário «fiz o deploy e chamo imediatamente». Para um catálogo lido por pessoas e agentes na busca por ferramentas, esse atraso geralmente é tolerável.

Terceira: o gatilho é especificamente o UpdateAgentRuntime. Se o conjunto de ferramentas de um servidor muda dinamicamente sem atualização do runtime, nenhum evento será gerado, e os registros terão de ser sincronizados por agendamento.

Há também duas observações sobre o código do próprio artigo. A busca do registro percorre a lista do registro e faz uma requisição get separada para cada item, e no trecho mostrado não há paginação. Com dezenas de servidores isso é aceitável; com centenas, convém adicionar um índice ou armazenar separadamente a correspondência entre ARN e ID do registro. Parte do código no artigo original é cortada, então é melhor consultar a versão completa no repositório do exemplo.

O que fazer na prática

Se você está construindo um catálogo interno de servidores MCP, adote o padrão inteiro: evento de deploy, depois consulta a tools/list, depois diff, depois gravação. Ele não está preso à AWS: em qualquer nuvem é possível montar o mesmo com um log de auditoria, um barramento de eventos e uma função. A regra principal é esta: a fonte da verdade sobre o esquema das ferramentas é o próprio servidor em execução, e a entrada no catálogo é apenas o seu reflexo, que não pode ser deixado para atualização manual.