AWS Agent Toolkit: cómo usar MCP con agentes de código sin abrir demasiado la cloud

AWS Agent Toolkit convierte una noticia reciente en una decisión duradera: cómo dar acceso cloud a agentes de código sin entregarles una llave maestra.

El 6 de mayo de 2026 AWS anunció la disponibilidad general de AWS MCP Server y lo situó dentro de Agent Toolkit for AWS. La noticia no es solo que exista otro servidor MCP. La señal técnica es que un proveedor cloud grande está intentando empaquetar documentación actual, llamadas autenticadas, skills y controles de auditoría en una capa pensada específicamente para agentes de código.

La conclusión práctica es incómoda pero necesaria: instalar el servidor es la parte fácil. El trabajo serio está en políticas, scopes, logs, budgets, revisión de prompts de proyecto y pruebas de reversibilidad.

run_script no es una shell local

La herramienta `run_script` es una de las piezas más interesantes porque permite que el agente agrupe varias llamadas AWS, filtre resultados y compute respuestas en un solo viaje. AWS explica que se ejecuta server side en un sandbox, hereda permisos IAM y no tiene acceso de red general ni al sistema de archivos local.

Eso no la convierte en inocua. Un script con permisos de lectura puede enumerar inventario sensible. Un script con permisos de escritura puede cambiar muchos recursos rápido. Pero sí mejora el diseño frente a entregar una terminal local completa: reduces superficie, haces la operación más observable y evitas que el agente mezcle AWS, filesystem local, secretos del repo y comandos arbitrarios en el mismo espacio.

Mi regla sería permitir `run_script` primero para consultas agregadas de lectura: inventario, compliance básico, comparativas regionales, costes estimados o checks de configuración. Para mutaciones, exigiría PR de infraestructura, plan revisable y despliegue separado.

Coste y contexto

AWS insiste en que el toolkit puede reducir tokens porque mantiene corta la lista de herramientas y recupera skills/documentación bajo demanda. Eso importa. Un agente con 40 herramientas genéricas y documentación pegada en el prompt no solo cuesta más; también tiene más oportunidades de elegir mal.

Checklist de piloto

• Empieza con un entorno sandbox o una cuenta AWS de desarrollo sin datos sensibles.
• Activa primero documentación y skills; retrasa acciones mutables.
• Crea una política IAM específica para el camino MCP con permisos de solo lectura.
• Usa context keys o condiciones equivalentes para separar acciones humanas y acciones del agente.
• Etiqueta recursos creados por flujos de agente y define una rutina de teardown.
• Revisa CloudTrail y métricas CloudWatch después de cada sesión piloto.
• Prohíbe secretos de producción en prompts, logs y rules files del agente.
• Define qué comandos o herramientas requieren confirmación humana explícita.
• Mide coste: tokens, tiempo humano, recursos AWS creados y cambios aceptados.
• Documenta un rollback antes de permitir mutaciones reales.

La meta no es que el agente despliegue más rápido por sí solo. La meta es que llegue a una propuesta mejor informada, con menos documentación obsoleta, menos IAM demasiado amplio y más evidencia para el reviewer.