AWS enseña al registro de servidores MCP a actualizarse solo: esquema de herramientas sin ediciones manuales

Todo catálogo interno muere de la misma manera. Al principio es preciso; luego alguien añade una función nueva al servicio y olvida corregir la entrada, y al cabo de un mes todos acuden al código y al chat, porque ya nadie confía en el catálogo. Con un registro de servidores MCP ocurre lo mismo, solo que las consecuencias son peores: un agente puede invocar una herramienta con el esquema antiguo y obtener un comportamiento incomprensible sin un error explícito.

AWS ha publicado un análisis de cómo evitarlo en Agent Registry, parte de Amazon Bedrock AgentCore. La idea es sencilla: la actualización de un registro no debe depender de la disciplina del desarrollador. Debe dispararla el propio evento de despliegue.

Cómo funciona

La cadena de cinco servicios es la siguiente.

• El desarrollador actualiza el servidor MCP, por ejemplo con el comando agentcore deploy. Esto invoca la API UpdateAgentRuntime, y CloudTrail registra la llamada como evento de administración (management event).
• EventBridge, mediante una regla (origen aws.bedrock-agentcore, nombre de evento UpdateAgentRuntime), reenvía el evento a un bus central. En un esquema multicuenta, este se encuentra en la cuenta del registro.
• Lambda extrae del evento el ARN del runtime y construye a partir de él la URL de invocación del servidor MCP. La región y el ID de cuenta los toma del mismo ARN.
• Lambda obtiene un token OAuth a través de AgentCore Identity: primero un workload token para sí misma y después un token M2M del credential provider de la cuenta correspondiente. No hay secretos de cliente en las variables de entorno.
• Lambda llama a initialize y luego a tools/list, y obtiene la lista actualizada de herramientas.
• A continuación busca el registro cuyo esquema contenga el mismo ARN (o el ARN codificado, o la URL) y compara las listas.

Dónde hay ingeniería cuidada

La comparación está hecha para evitar escrituras innecesarias. Las herramientas se ordenan por nombre y se reducen a tres campos: name, description e inputSchema. La escritura en el registro solo ocurre si esos campos difieren, y en los logs queda constancia de qué se añadió o se eliminó exactamente.

Dos detalles útiles más. Para cada cuenta se configura su propio credential provider (una variable del tipo CREDENTIAL_PROVIDER_{ACCT_ID}), de modo que una sola Lambda atiende servidores de distintas cuentas. Y antes de la petición, el código comprueba que la URL empiece por https://, lo que cierra escenarios desagradables como file://.

Imagine un equipo de pagos que añadió a su servidor MCP la herramienta refund_status. Antes, el equipo de soporte se habría enterado por el chat una semana después. Ahora, 5–15 minutos después del despliegue, el registro ya contiene la nueva herramienta con el esquema actualizado, y en los logs de Lambda se ve qué cambió.

Limitaciones que conviene conocer

Primera: el servicio no crea registros. En el ejemplo, Lambda actualiza solo los registros ya dados de alta durante el onboarding y que contienen el ARN del runtime en mcpServer.data. Los registros en estado DRAFT se omiten; se requiere APPROVED. Esto conserva el proceso de aprobación existente, pero el registro inicial habrá que automatizarlo por separado.

Segunda: la latencia. CloudTrail entrega los eventos en aproximadamente 5–15 minutos, así que no sirve para el escenario «despliego y llamo de inmediato». Para un catálogo que leen personas y agentes al buscar herramientas, ese retraso suele ser tolerable.

Tercera: el disparador es específicamente UpdateAgentRuntime. Si el conjunto de herramientas de un servidor cambia de forma dinámica sin actualizar el runtime, no se producirá ningún evento y los registros deberán sincronizarse según un calendario.

Hay también dos observaciones sobre el código del propio artículo. La búsqueda del registro recorre la lista del registro y hace una petición get independiente por cada elemento, y en el fragmento mostrado no hay paginación. Con decenas de servidores es aceptable; con cientos conviene añadir un índice o guardar aparte la correspondencia entre ARN e ID del registro. Parte del código del artículo original se interrumpe, así que es mejor consultar la versión completa en el repositorio del ejemplo.

Qué hacer en la práctica

Si está construyendo un catálogo interno de servidores MCP, adopte el patrón completo: evento de despliegue, luego consulta de tools/list, luego diff y luego escritura. No está atado a AWS: en cualquier nube se puede montar lo mismo con un log de auditoría, un bus de eventos y una función. La regla principal es esta: la fuente de verdad sobre el esquema de herramientas es el propio servidor en ejecución, y la entrada del catálogo es solo su reflejo, que no debe dejarse a la actualización manual.