AWS levou seu MCP Server ao GA essa semana — um endpoint gerenciado único que expõe cada API AWS através do Model Context Protocol, em vez das implementações per-serviço que cada cloud shop tava montando na mão no último ano. Preview em novembro 2025; GA adiciona execução Python sandboxada pra tarefas multi-passo mais cobertura completa de API incluindo ops long-running e file uploads. Serviços mencionados no release: Amazon S3 Vectors, Amazon Aurora DSQL, Amazon Bedrock AgentCore — as três peças que builders AI enterprise tavam tocando através de glue SDK manual. Compatível com Claude Code, Kiro, Cursor e Codex out of the box. Pra quem ship agentes em ambientes AWS, isso esmaga a superfície de integração de "um wrapper MCP por serviço" pra "um endpoint MCP, control plane IAM completo."
A parte tecnicamente interessante é a ponte de auth. MCP 2.1 padronizou no OAuth 2.1 pra autenticação; AWS padronizou no IAM + SigV4 há décadas. Os dois não falam nativamente. AWS soltou um MCP Proxy for AWS open-source em github.com/aws/agent-toolkit-for-aws que roda localmente ao lado do teu agente e traduz autenticação baseada em IAM pra requests OAuth-compatible — teu agente pensa que tá batendo num MCP server padrão, o proxy assina a chamada subjacente com SigV4 e forwarda. Esse é o padrão canônico pra colocar MCP em qualquer cloud cuja auth precede o OAuth 2.1, e a implementação de referência da AWS é a primeira maior in the wild. Governança se anexa da maneira padrão: policies IAM pro que o agente pode chamar, métricas CloudWatch pro que ele tá fazendo, CloudTrail pro log de auditoria completo. Pricing: o servidor é grátis; você paga pelos recursos que agentes realmente consomem, cobrado normal.
Leitura ecossistema: esse é o segundo release maior de infra MCP na quinzena depois do preview MCP Tunnels da Anthropic. O padrão é consistente — grandes plataformas convergem no MCP como a fronteira padrão agente-pra-ferramenta, e o trabalho que tá rolando agora é preencher as peças auth/governança/runtime que o protocolo em si não dita. AWS fazendo isso com cobertura API full-fleet e IAM como control plane é sinal real: não estamos mais no mundo "um MCP server por integração", estamos no mundo "um MCP por cloud." O corolário é que o mesmo MCP que deixa teu agente chamar s3:PutObject deixa também chamar iam:PassRole se a policy tá frouxa. Que é exatamente o gap que um practitioner flegou no piece da InfoQ: "sem gateways pra restringir certas ações ou operações" além da camada IAM. A história do blast-radius é tua história IAM.
Segunda de manhã: se você roda agentes que tocam AWS, troque teus wrappers MCP per-serviço pelo servidor unificado e aperte o role IAM anexado ao credential que teu agente assume. A nova execução Python sandboxada significa que tarefas multi-passo (lê X, transforma, escreve Y) não precisam mais de glue de orquestração separada — acontecem dentro do sandbox do MCP server. O blocker honesto é o gap de restrição gateway: IAM é o único gate, então uma policy mal configurada é o failure mode inteiro. Até a AWS shipar gates de ação mais finos, trate o role IAM do MCP server como você trataria um role produção least-privilege: scopeie ele exatamente aos ARNs e ações que o agente precisa, log tudo via CloudTrail, alerte em padrões anômalos. O proxy de referência e o toolkit vivem em github.com/aws/agent-toolkit-for-aws.