AWS dropped the GA of its MCP Server this week โ a single managed endpoint that exposes every AWS API through Model Context Protocol, rather than the per-service implementations every cloud shop has been hand-rolling for the past year. Preview shipped November 2025; GA adds sandboxed Python execution for multi-step tasks plus comprehensive API coverage including long-running operations and file uploads. Service mentions in the release: Amazon S3 Vectors, Amazon Aurora DSQL, Amazon Bedrock AgentCore โ the three pieces enterprise AI builders have been hitting through manual SDK glue. Compatible with Claude Code, Kiro, Cursor, and Codex out of the box. For anyone shipping agents into AWS environments, this collapses the integration surface from "one MCP wrapper per service" to "one MCP endpoint, full IAM control plane."
The technically interesting bit is the auth bridge. MCP 2.1 standardised on OAuth 2.1 for authentication; AWS standardised on IAM + SigV4 decades ago. The two don't natively talk. AWS shipped an open-source MCP Proxy for AWS at github.com/aws/agent-toolkit-for-aws that runs locally next to your agent and translates IAM-based authentication into OAuth-compatible requests โ your agent thinks it's hitting a standard MCP server, the proxy signs the underlying call with SigV4 and forwards it. That's the canonical pattern for getting MCP into any cloud whose auth predates OAuth 2.1, and AWS's reference implementation is the first major one in the wild. Governance attaches the standard way: IAM policies for what the agent can call, CloudWatch metrics for what it's doing, CloudTrail for the full audit log. Pricing: the server is free; you pay for resources agents actually consume, billed normally.
Ecosystem read: this is the second major MCP infrastructure release in the past fortnight after Anthropic's MCP Tunnels preview. The pattern is consistent โ large platforms are converging on MCP as the standard agent-to-tool boundary, and the work happening at the moment is filling in the auth/governance/runtime pieces that the protocol itself doesn't dictate. AWS doing this at full-fleet API coverage with IAM as the control plane is a real signal: this is no longer the "one MCP server per integration" world, it's the "one MCP per cloud" world. The corollary is that the same MCP that lets your agent call s3:PutObject also lets it call iam:PassRole if the policy is loose. Which is exactly the gap one practitioner flagged in the InfoQ piece: "no gateways to restrict certain actions or operations" beyond the IAM layer. The blast-radius story is your IAM story.
Monday morning: if you're running agents that touch AWS, swap your per-service MCP wrappers for the unified server and tighten the IAM role attached to whichever credential your agent assumes. The new sandboxed Python execution means multi-step tasks (read X, transform, write Y) no longer need separate orchestration glue โ they happen inside the MCP server's sandbox. The honest blocker is the gateway-restriction gap: IAM is the only gate, so a misconfigured policy is the entire failure mode. Until AWS ships finer-grained action gates, treat the MCP server's IAM role as you'd treat a least-privilege production role: scope it to exactly the ARNs and actions the agent needs, log everything via CloudTrail, alert on anomalous patterns. The reference proxy and toolkit live at github.com/aws/agent-toolkit-for-aws.