AWS MCP Server GA: Secure AWS API Access for AI Agents

Every month a new MCP server ships and claims to "unlock" some platform for AI agents. Most of them are thin wrappers — an API key, a few REST calls, no audit trail. The AWS MCP Server is not that. AWS owns the infrastructure it exposes, which means it can wire agent-initiated API calls directly into IAM, CloudTrail, and CloudWatch in ways no third-party wrapper can match.

On May 6, 2026, AWS moved the MCP Server from preview (first shown at re:Invent November 2025) to general availability. This guide covers what changed, how to configure it against Claude Code, Cursor, or Kiro, and what the five exposed tools actually do. Effloow Lab scouted this tool from official AWS documentation, the AWS blog post, the Agent Toolkit for AWS docs, and community sources including the awslabs/mcp GitHub repository.

Why This Matters

The MCP ecosystem crossed 97 million monthly SDK downloads by March 2026, and Anthropic donated the protocol to the Linux Foundation's Agentic AI Foundation that December. Every major cloud provider now has an official hosted MCP endpoint. AWS's entry is different for one structural reason: it is not a public API wrapper. It is a managed server running inside AWS that calls AWS APIs on behalf of the agent — using that agent's own IAM identity.

That means every call an agent makes through the MCP Server appears in CloudTrail under the agent's IAM principal, tagged with two new condition keys (aws:ViaAWSMCPService and aws:CalledViaAWSMCP) that distinguish it from calls a human made. You can write an IAM policy that says "agents may only read; agents may not create or delete." You cannot do that with raw boto3 or a third-party MCP wrapper, because the wire-level calls look identical to human calls.

For teams with compliance requirements — SOC 2, PCI, HIPAA environments — that separation is not a nice-to-have. It is what makes agentic AWS automation safe enough to run in production.

Core Concepts: What AWS MCP Server Is

The AWS MCP Server is a fully managed, hosted MCP server. You do not run it yourself. It lives at two endpoints:

• US East (N. Virginia): https://aws-mcp.us-east-1.api.aws/mcp
• Europe (Frankfurt): https://aws-mcp.eu-central-1.api.aws/mcp

The server speaks OAuth 2.1. Your local IAM credentials are bridged to it through an open-source proxy called MCP Proxy for AWS (github.com/aws/mcp-proxy-for-aws), which runs locally, translates your IAM credential chain into signed OAuth-compatible requests, and forwards them to the hosted endpoint.

The server is part of the Agent Toolkit for AWS, which bundles it with three agent plugin packages:

• aws-core — full-stack application development on AWS
• aws-data-analytics — data pipelines, S3 Tables, Glue, Athena
• aws-agents — AI agent building with Bedrock AgentCore and API Gateway

You can use the raw MCP Server without a plugin bundle — all five tools are available — but the plugins add curated Skills and prebuilt workflows for specific domains.

The --metadata AWS_REGION=<region> parameter in your client config sets which AWS region the agent's API calls target. The hosting endpoint region and the operations region are independent. You can call the Frankfurt endpoint and direct API calls to ap-southeast-1 without issue.

What's New in GA: Key Features

The preview version shipped at re:Invent 2025 with a narrower surface. GA brought several meaningful changes:

IAM condition keys. All agent-initiated API calls now carry aws:ViaAWSMCPService and aws:CalledViaAWSMCP context keys automatically. No separate IAM permission is needed to activate this. It simply happens, and your existing IAM policies can reference these keys to restrict agent actions.

Documentation retrieval no longer requires authentication. In preview, accessing AWS docs through the MCP Server required credentials. At GA, aws___search_documentation and aws___read_documentation are open — agents can pull current documentation without extra auth configuration.

Sandboxed Python execution via run_script. The new aws___run_script tool lets agents execute Python code in a server-side sandbox. The sandbox has IAM permissions but no access to the local filesystem and no outbound network access. It is designed for multi-step, cross-service aggregation that would otherwise require the agent to orchestrate many sequential API calls.

On-demand skill loading. The "Agent SOPs" from preview have been replaced by Skills — maintainable, discoverable units of AWS service-team guidance. Skills load on demand rather than pre-populating the context window. This reduced token consumption per interaction is meaningful: earlier MCP setups often burned large portions of the context window on server-side instructions before the agent could start working.

Extended API coverage. The GA version covers all AWS services. The aws___call_aws tool can execute any of the 15,000+ AWS API operations, and new APIs launched by AWS become available within days of their release.

Getting Started: Setup and Configuration

Prerequisites

Before configuring any MCP client, you need:

1. An AWS account with appropriate IAM permissions
2. AWS CLI v2.32.0 or later
3. Python 3.10 or later
4. uv package manager from Astral — install on macOS/Linux with:

curl -LsSf https://astral.sh/uv/install.sh | sh

On Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Configure AWS credentials

Run aws login to authenticate. The AWS login flow auto-rotates credentials every 15 minutes and keeps them valid for up to 12 hours. Verify your identity before proceeding:

aws sts get-caller-identity

If you use SSO or cross-account roles, aws configure with your preferred credential chain works as well.

Remove conflicting MCP servers (if applicable)

If you previously added aws-api-mcp-server or aws-knowledge-mcp-server from the awslabs open-source collection to your MCP client config, remove them. They expose overlapping tool names that conflict with the managed server tools. Restart your MCP client after the config change.

Configure your MCP client

The configuration is the same JSON structure across Claude Desktop, Cursor, and most other clients that read an mcp.json or similar config file:

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=us-west-2"
      ]
    }
  }
}

For Claude Code CLI, add the server with a single command:

claude mcp add-json aws-mcp --scope user \
  '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'

For Kiro CLI (~/.kiro/settings/mcp.json in TOML format):

[mcp_servers.aws_mcp]
command = "uvx"
args = ["mcp-proxy-for-aws@latest", "https://aws-mcp.us-east-1.api.aws/mcp", "--metadata", "AWS_REGION=us-west-2"]
startup_timeout_sec = 60

Test the connection

After restarting your MCP client, wait for initialization — the first startup can take a few minutes while the proxy downloads and the server handshake completes. Then ask the agent: "What AWS Regions are available?" A valid response confirms the connection. In Kiro, run /tools or /mcp to verify that aws___search_documentation and aws___retrieve_skill appear.

The most common setup failure is expired or missing credentials. If tools do not appear in the agent, run aws sts get-caller-identity first. If that also fails, re-run aws login.

Available Tools and Resources

The managed AWS MCP Server exposes exactly five tools to connected agents:

aws___call_aws — The primary workhorse. Executes any of the 15,000+ AWS API operations using the agent's existing IAM credentials. The server handles syntax validation and error formatting before returning results to the agent, which reduces the back-and-forth cycles that raw API failures otherwise create. File uploads and long-running operations are supported.

aws___search_documentation — Searches all AWS documentation, API references, best practices, and What's New entries at query time. At GA, this no longer requires authentication. Because documentation is fetched live rather than embedded in the server's training data, the agent gets current API signatures rather than potentially outdated ones.

aws___read_documentation — Fetches and converts a specific AWS documentation page to markdown for the agent to read inline. Complements search_documentation for when the agent needs the full content of a specific guide.

aws___run_script — Executes Python code in a sandboxed server-side environment. The sandbox carries the agent's IAM permissions, so it can make AWS API calls. It has no access to the local filesystem and no outbound network connectivity beyond AWS. This is the right tool for multi-step operations that require aggregation across services or parallel API calls.

aws___retrieve_skill — Loads a domain-specific Skill on demand. Skills are curated procedures maintained by AWS service teams covering areas like serverless architecture, data analytics, IaC best practices, and Bedrock AgentCore. They load only when needed, keeping context window usage low.

Open-source server collection

Beyond the managed server, AWS maintains the awslabs/mcp repository (open source, 8,900+ GitHub stars) with 45 to 60+ specialized servers. Notable ones include:

• aws-documentation-mcp-server — standalone documentation search with search_documentation, read_documentation, read_sections, and recommendations tools
• aws-iac-mcp-server — CDK and CloudFormation template validation, compliance checking, best-practice enforcement
• aws-serverless-mcp-server — Lambda event schema guidance, SAM/CDK selection, multi-trigger architecture advice
• cloudwatch-mcp-server — AI-powered root cause analysis using CloudWatch data
• aws-pricing-mcp-server — cost estimation and bulk pricing queries
• amazon-bedrock-agentcore-mcp-server — 122 tools for agent lifecycle management including memory, identity, gateways, cloud browser automation, and sandboxed code execution

Install open-source servers via uvx:

uvx awslabs.aws-documentation-mcp-server@latest

Each server has a dedicated documentation page at https://awslabs.github.io/mcp/servers.

Python Sandbox Execution

The aws___run_script tool deserves its own section because it closes a real workflow gap. Before it existed, an agent that needed to list all EC2 instances unused for 30 days costing over $500/month had to make many sequential API calls: describe instances, query CloudWatch metrics for CPU, cross-reference Cost Explorer data, filter and aggregate the results. Each call returned a partial answer, and the agent had to track state across them.

With run_script, the agent writes a Python script that does all of that in a single sandboxed execution. The script can call multiple services, loop over paginated results, aggregate data, and return a clean answer. The sandbox has persistent IAM credentials but no access to the local filesystem and no general internet access. It cannot reach your laptop's files or call arbitrary external APIs.

This is not the same as the sandboxed code execution in Amazon Bedrock AgentCore, which is a separate product with its own persistence model (variables and imports persist across calls within a session, and it supports Python, JavaScript, and TypeScript). The run_script tool in the managed MCP Server is scoped to single-execution AWS API work.

For agent sandbox patterns more broadly, the design principle is the same: isolate execution, inherit identity, prevent exfiltration. The AWS implementation follows that pattern at the infrastructure level rather than relying on application-layer sandboxing.

A practical example the agent might run through run_script:

import boto3
from datetime import datetime, timedelta

ec2 = boto3.client('ec2')
cw = boto3.client('cloudwatch')

instances = ec2.describe_instances(
    Filters=[{'Name': 'instance-state-name', 'Values': ['running']}]
)

idle_instances = []
for reservation in instances['Reservations']:
    for instance in reservation['Instances']:
        instance_id = instance['InstanceId']
        # Check average CPU over last 30 days
        metrics = cw.get_metric_statistics(
            Namespace='AWS/EC2',
            MetricName='CPUUtilization',
            Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}],
            StartTime=datetime.utcnow() - timedelta(days=30),
            EndTime=datetime.utcnow(),
            Period=86400,
            Statistics=['Average']
        )
        avg_cpu = sum(p['Average'] for p in metrics['Datapoints']) / max(len(metrics['Datapoints']), 1)
        if avg_cpu < 5.0:
            idle_instances.append({'id': instance_id, 'avg_cpu': avg_cpu})

print(idle_instances)

The agent submits that script through aws___run_script, it executes in the sandbox, and the result comes back as structured output. No separate orchestration layer needed.

Practical Use Cases

FinOps and cost analysis. Ask: "What were my EC2 costs last month by region and instance type?" The agent uses aws___call_aws to query Cost Explorer, then aws___run_script to aggregate the data if the result set is large. Compliance auditors get a clean CloudTrail log of exactly which Cost Explorer APIs the agent called.

IaC development. Ask: "Generate a CDK stack for an API Gateway Lambda integration with DynamoDB following current best practices." The agent loads the relevant Skill via aws___retrieve_skill, then checks current API signatures via aws___search_documentation before writing code. Stale API signatures — a common hallucination source — are avoided because documentation is fetched live.

Incident response. Ask: "Which Lambda functions had elevated error rates in the last hour?" The agent queries CloudWatch metrics through aws___call_aws, optionally runs aggregation through aws___run_script, and returns a ranked list. The CloudTrail log gives the on-call team an audit record of which queries the agent ran.

Environment inspection. Ask: "What resources exist in my staging account?" For read-only access, create an IAM policy that allows Describe/List/Get operations but blocks Create, Delete, and Update. The agent's credential chain picks up that restriction automatically. No application-layer permission enforcement needed.

Bedrock AgentCore provisioning. When building agents on Bedrock AgentCore, the aws___retrieve_skill for aws-agents bundle loads validated procedures for setting up runtimes, memory stores, and identity providers — steps that otherwise require reading through multiple documentation pages and stitching together a dozen boto3 calls.

Common Mistakes and Limitations

Credential expiration during long sessions. The AWS login flow rotates credentials every 15 minutes, but the session stays valid for up to 12 hours. If you see ExpiredTokenException, run aws login again and restart your MCP client. The MCP proxy does not auto-refresh mid-session.

Forgetting to remove conflicting open-source servers. If you have awslabs.aws-api-mcp-server installed alongside the managed server, you will have duplicate tool names. The agent may call the wrong implementation or fail to resolve the call entirely. Remove the open-source variant from your config when using the managed server.

Region targeting confusion. The endpoint URL (us-east-1.api.aws) is the hosting region for the MCP Server itself. It has nothing to do with which region your API calls target. Set --metadata AWS_REGION=<your-region> to the region where your resources live.

No action gateway or operation deny-list. Community feedback from DevOps teams, including coverage by InfoQ, notes that there is no built-in mechanism to block specific API operations below the IAM policy level. If you want to prevent agents from calling ec2:TerminateInstances, you must write an IAM deny policy. You cannot configure the MCP Server directly to block specific operations. For teams wanting that second layer of control, this is a limitation to plan around.

Geographic availability. At GA launch (May 2026), the managed server is only hosted in US East N. Virginia and Europe Frankfurt. AWS has indicated expansion through 2026, but if your data residency requirements exclude both regions, the managed server is not available to you yet. The open-source awslabs servers running locally do not have this constraint.

Sandboxed Python limits. aws___run_script does not persist state across invocations. Each script execution is isolated. If you need stateful sessions with variable persistence across multiple code executions, the Amazon Bedrock AgentCore code interpreter is the right product — it maintains execution context within a session.

Comparison: AWS MCP Server vs. Alternatives

FAQ

Q: Does the AWS MCP Server work with any MCP client, or only Claude Code and Kiro?

Any MCP-compatible client works. AWS has documented configuration for Claude Code, Kiro (including Kiro CLI), Cursor, and Codex. Any client that supports stdio transport and can run a local process via uvx can use the MCP Proxy for AWS to connect. The proxy is the only local component — the server itself is hosted by AWS.

Q: If the managed server is free, what am I actually paying for?

You pay for the AWS resources your agents create or use (EC2 instances, S3 storage, Lambda invocations, Cost Explorer API calls, etc.) and standard data transfer costs. CloudTrail and CloudWatch metrics for agent activity have their standard AWS pricing. The MCP Server itself adds no line item.

Q: Is there a difference between the managed AWS MCP Server and the open-source awslabs/mcp servers?

Yes, and the distinction matters for production use. The open-source servers (pip-installable via uvx awslabs.<server-name>@latest) run locally on your machine and rely on your local credential chain. They have no server-side sandboxing, no automatic CloudTrail agent tagging, and no IAM condition keys. They are well-suited for local development, offline use, or deep-service-specific work (the IaC, serverless, or pricing servers, for example). The managed server is the right choice when you need audit separation, enterprise governance, or the sandboxed Python execution tool.

Q: Can I use the AWS MCP Server if I am in a region that does not have an endpoint yet?

Yes, with a caveat. The server is hosted in US East N. Virginia and Europe Frankfurt. You connect to one of those endpoints, but you can direct your API calls to any AWS region via the --metadata AWS_REGION=<region> parameter. Your actual resource operations happen in whatever region your resources live. The constraint is only on which region hosts the MCP Server process — not which region your AWS services are in.

Q: How does the Skills system replace Agent SOPs?

In the preview, "Agent SOPs" were static instruction sets loaded at server startup. They consumed context window space even when the agent did not need them. Skills are the replacement: shorter, focused, and loaded on demand via the aws___retrieve_skill tool. The agent asks for a Skill by domain (serverless, data analytics, IaC), the server loads the relevant guidance, and the rest of the context window stays available for the actual task. AWS service teams maintain the Skills, so they reflect current best practices rather than documentation that was correct at server release time.

Key Takeaways

AWS MCP Server GA is a production-ready foundation for agentic AWS workflows, not a prototype. The three things that set it apart from every other approach are: IAM condition keys for agent-vs-human audit separation, sandboxed Python execution for multi-step cross-service operations, and live documentation retrieval that prevents stale API hallucinations.

The setup path is short — install uv, configure mcp-proxy-for-aws in your MCP client config, and you have 15,000+ API operations available to any connected agent. The open-source awslabs server collection (45+ servers) covers specialized use cases the managed server does not, and both work in the same ecosystem.

The main constraints to know before adopting: the managed server is currently in two regions only, there is no per-operation deny-list below the IAM policy level, and the sandboxed Python environment does not persist state across invocations. If none of those are blockers for your use case, GA makes this safe to adopt in production today.

For teams already using MCP in TypeScript agent workflows, adding the AWS MCP Server as a parallel tool server gives those agents authenticated, audited AWS access without additional credential management at the application layer.