AWS MCP Server goes GA with IAM context keys

AWS has made its MCP Server generally available with tighter IAM controls and better agent tooling.

AWS says the AWS MCP Server is now generally available, and the timing matters: the company is pitching it as a way to give AI agents authenticated access to AWS without dumping the whole account into the model’s hands. The server exposes more than 15,000 AWS API operations through a small toolset, and AWS says it can keep up as new APIs launch within days.

Why AWS built this now

The problem AWS is trying to solve is familiar to anyone who has watched an agent fumble through cloud work. A model can know how to write code, but if its training data is stale, it will miss newer services like Amazon S3 Vectors, Amazon Aurora DSQL, or Amazon Bedrock AgentCore. It may also default to the AWS CLI when a higher-level AWS tool would be a better fit, or generate IAM policies that are broader than the task really needs.

AWS is making a clear bet here: current documentation plus authenticated API access beats model memory every time. That is a practical answer to one of the biggest weaknesses in agentic coding today, especially in cloud environments where the difference between read-only and mutating access matters.

The new server is part of the Agent Toolkit for AWS, which also includes skills and plugins. AWS is keeping the tool surface small on purpose, because a short list is easier for agents to use correctly and easier for humans to audit.

• call_aws can invoke any of 15,000+ AWS API operations
• search_documentation and read_documentation pull live docs at query time
• run_script executes short Python code in a sandbox with no network access
• Skills replace older Agent SOPs and are maintained by AWS service teams

The new controls are the real story

The most interesting part of the GA release is not the headline launch itself. It is the control plane around the launch. AWS says the server now supports IAM context keys, so you do not need a separate IAM permission just to use the server. That makes access easier to express in a normal IAM policy, which is exactly where enterprise teams want this kind of control to live.

Documentation retrieval also no longer requires authentication. That sounds small, but it removes friction from the exact workflow where agents need current facts fast. AWS also says it reduced the number of tokens needed per interaction, which matters when an agent is chaining together several API calls and reasoning steps.

“The AWS MCP Server is now generally available” — Sébastien Stormacq, AWS News Blog

The sandboxed run_script tool is the other smart move. It lets an agent write and run short Python code on the server side, using the caller’s IAM permissions but without network access. That gives the agent a place to combine API results, filter data, and compute outputs without touching your local machine or asking for shell access.

For teams worried about overprivileged agents, AWS is also drawing a line between human and agent permissions. The blog says you can use IAM policies or Service Control Policies to allow a human to mutate resources while keeping the MCP server read-only. That is the kind of split security teams can actually reason about.

What the demo shows in practice

AWS used Claude Code for the demo, but the company says the server works with any MCP-compatible client, including Cursor, Kiro, and Codex. The demo is useful because it shows the failure mode first. With a model that has a May 2025 cutoff, a question about storing embeddings on S3 produces decent but outdated answers that do not use S3 Vectors.

Once the AWS MCP Server is connected, the agent can ask for the live documentation and answer with the current service. That is the point: the model does not need to remember every AWS launch, because the server can fetch the right answer on demand.

AWS also explains how it bridges local IAM credentials to MCP’s OAuth 2.1 world using an open source proxy, the MCP Proxy for AWS. In the example, the proxy runs locally and forwards requests to one of the regional AWS MCP endpoints.

• Available in US East (N. Virginia) and Europe (Frankfurt)
• No additional charge for the MCP Server itself
• You still pay for AWS resources and data transfer
• Works with any MCP-compatible client, not just AWS tools

How this compares with the old agent workflow

The old pattern for cloud agents was simple: ask the model, hope the training data is fresh enough, then patch the result by hand. AWS is trying to replace that with a loop that is more grounded in live services and policy-aware access. That matters because the cost of a wrong answer in cloud infrastructure is not just a bad suggestion; it can become a bad deployment.

Here is the practical comparison:

• Model-only answer: fast, but often stale when AWS ships new services
• MCP-backed answer: slower by a few seconds, but tied to current docs and real IAM permissions
• CLI-heavy workflow: powerful, but often too low-level for an agent to choose well
• Server-side script execution: useful for multi-step API work without exposing your local shell

That tradeoff is why this release matters more for enterprise teams than hobbyist demos. The value is not that an agent can now “talk to AWS.” The value is that it can do so with current documentation, scoped permissions, audit trails in Amazon CloudWatch, and records in AWS CloudTrail.

What builders should do next

If you are already experimenting with AI agents on AWS, this is worth testing now rather than later. The combination of live docs, authenticated API access, and sandboxed server-side scripts gives agents a much better shot at producing useful cloud work without wandering into stale advice or unsafe permissions.

The next question is whether teams will trust agents enough to let them move beyond lookups and into real operational workflows. My guess is the first wins will come from infrastructure discovery, documentation lookup, and controlled read-only automation. If AWS keeps tightening the policy model and the tool surface stays small, the MCP Server could become the default bridge between AI assistants and AWS accounts.

For now, the actionable takeaway is simple: if your agents are still guessing at AWS services, connect them to the AWS MCP Server and see how much of that guesswork disappears.