AWS llevó su MCP Server a GA esta semana — un endpoint gestionado único que expone cada API de AWS a través de Model Context Protocol, en lugar de las implementaciones per-servicio que cada cloud shop ha estado armando a mano durante el último año. Preview en noviembre 2025; GA añade ejecución Python sandboxeada para tareas multi-paso más cobertura completa de API incluyendo ops long-running y file uploads. Servicios mencionados en el release: Amazon S3 Vectors, Amazon Aurora DSQL, Amazon Bedrock AgentCore — las tres piezas que los builders AI enterprise estaban tocando a través de glue SDK manual. Compatible con Claude Code, Kiro, Cursor y Codex out of the box. Para quien ship agents en entornos AWS, esto aplasta la superficie de integración de "un wrapper MCP por servicio" a "un endpoint MCP, control plane IAM completo."
La parte técnicamente interesante es el puente de auth. MCP 2.1 estandarizó en OAuth 2.1 para autenticación; AWS estandarizó en IAM + SigV4 hace décadas. Los dos no hablan nativamente. AWS sacó un MCP Proxy for AWS open-source en github.com/aws/agent-toolkit-for-aws que corre localmente al lado de tu agente y traduce autenticación basada en IAM a requests OAuth-compatible — tu agente piensa que está tocando un MCP server estándar, el proxy firma la llamada subyacente con SigV4 y forwardea. Ese es el patrón canónico para meter MCP en cualquier cloud cuya auth precede a OAuth 2.1, y la implementación de referencia de AWS es la primera mayor en el wild. Gobernanza se adjunta de la manera estándar: políticas IAM para lo que el agente puede llamar, métricas CloudWatch para lo que está haciendo, CloudTrail para el log de auditoría completo. Precio: el servidor es gratis; pagas por los recursos que los agentes realmente consumen, facturado normal.
Lectura ecosistema: este es el segundo release mayor de infra MCP en la quincena tras el preview MCP Tunnels de Anthropic. El patrón es consistente — las grandes plataformas convergen en MCP como la frontera estándar agente-a-herramienta, y el trabajo que está pasando ahora es rellenar las piezas auth/gobernanza/runtime que el protocolo en sí no dicta. AWS haciendo esto con cobertura API full-fleet y IAM como control plane es señal real: ya no estamos en el mundo "un MCP server por integración", estamos en el mundo "un MCP por cloud." El corolario es que el mismo MCP que deja a tu agente llamar s3:PutObject lo deja también llamar iam:PassRole si la política está suelta. Que es exactamente el gap que un practitioner flagó en el piece de InfoQ: "no hay gateways para restringir ciertas acciones u operaciones" más allá de la capa IAM. La historia del blast-radius es tu historia IAM.
Lunes por la mañana: si corres agentes que tocan AWS, cambia tus wrappers MCP per-servicio por el servidor unificado y aprieta el rol IAM adjunto al credential que tu agente asume. La nueva ejecución Python sandboxeada significa que tareas multi-paso (lee X, transforma, escribe Y) ya no necesitan glue de orquestación separada — pasan dentro del sandbox del MCP server. El blocker honesto es el gap de restricción gateway: IAM es el único gate, así que una política mal configurada es el failure mode entero. Hasta que AWS shippee gates de acción más finos, trata el rol IAM del MCP server como tratarías un rol producción least-privilege: scopealo exactamente a los ARNs y acciones que el agente necesita, log todo vía CloudTrail, alerta en patrones anómalos. El proxy de referencia y el toolkit viven en github.com/aws/agent-toolkit-for-aws.