I Switched to the Agent Toolkit for AWS. Here's Why.

#aws #mcp #ai #devtools

I've been using AI coding agents like Kiro, Claude Code, with AWS for a while now. To connect them to my AWS account, I was running the community MCP servers from awslabs; the AWS one, the documentation one, sometimes both.

It worked. But it felt like handing my house keys to a very enthusiastic intern and hoping they didn't rearrange the furniture while I was out. The agent had my credentials but no restrictions on what it could do, and zero audit trail of what it actually did.

Then I switched to the Agent Toolkit for AWS. It's the difference between that enthusiastic intern and a contractor who shows up with their own tools, follows the scope you agreed on, and leaves you a detailed invoice of every change they made.

What is it?

The Agent Toolkit for AWS is the official, AWS-managed suite of tools that helps AI coding agents build, deploy, and manage things on AWS. Four components:

AWS MCP Server : a managed remote server that gives agents secure access to AWS APIs via the Model Context Protocol
Skills : curated step-by-step workflows for specific tasks (deploying serverless apps, debugging Lambda cold starts, etc.)
Plugins : single-install packages that bundle MCP config + skills for your IDE
Rules files : project-level configuration to guide agent behavior

Why I switched

Here's the thing. The old community servers were fine for experimenting. But the moment I started trusting agents with real infrastructure, I needed more control.

Security that actually means something.

The managed AWS MCP Server supports IAM condition keys. I can restrict exactly which actions an agent can perform. Scope the IAM role down to the minimum permissions the agent needs for the task, and it can only operate within those bounds.

The MCP Server automatically tags every request with condition keys (aws:CalledViaAWSMCP). So you can write IAM policies that treat agent actions differently from your own. For example, this would prevent the agent from deleting buckets, even if your credentials normally allow it:

{
  "Effect": "Deny",
  "Action": "s3:DeleteBucket",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "aws:CalledViaAWSMCP": "true"
    }
  }
}

You still have full access. The agent doesn't.

Even better: use a separate IAM profile for your agent with only the permissions it needs. The condition keys are a safety net, but a scoped-down profile is the first line of defense. And if you're just getting started, point it at a dev account, not production.

Sandboxed code execution.

The toolkit includes a sandboxed Python runtime with boto3 access. Agents can write and run multi-step scripts, list resources, filter, aggregate, without touching my local machine.

The agent wrote a boto3 call, ran it remotely, and got structured results back. My machine never ran that code.

I can see what it did.

Every API call goes through CloudTrail. Metrics flow to CloudWatch. I get a full audit trail. With the old server, I'd have to dig through terminal history and hope I caught everything.

Every MCP-initiated call shows invokedBy: aws-mcp.amazonaws.com in the event fields. When you call aws s3 ls from your terminal, the sourceIPAddress would be your IP. When the MCP Server makes the call, it's aws-mcp.amazonaws.com. That's how you tell them apart.

Built-in docs search.

No more running a separate documentation MCP server. The Agent Toolkit has native tools to search AWS docs, read full pages, get content recommendations, and check regional availability. All in one server.

Expert skills.

These are curated workflows that go beyond documentation. Decision frameworks, troubleshooting trees, step-by-step procedures. For example, the aws-serverless skill covers Lambda, API Gateway, Step Functions, EventBridge, SAM, and CDK with guidance on cold starts, CORS debugging, concurrency, and production readiness.

We will explore these in future posts!

Multi-profile support.

If you work across multiple AWS accounts, there's built-in profile switching. Pass --profile in the config and the agent routes requests through the right credentials, check setup guide below on how to do this.

Side by side

Let the table do the talking:

	Old (`awslabs.aws-api-mcp-server`)	New (Agent Toolkit `aws-mcp`)
Type	Community/labs, runs locally	Official AWS-managed remote server
Auth	Local credentials, no restrictions	SigV4 + IAM condition keys
Security	No guardrails	Fine-grained IAM controls
Observability	None	CloudWatch + CloudTrail
Code execution	Not available	Sandboxed Python with boto3
Skills	Not included	Curated expert workflows
Documentation	Needed separate server	Built-in search + read
Maintenance	Manual `uvx` updates	AWS-managed, always current
Multi-profile	Not supported	Built-in

Getting started

If you're still running the old community MCP servers, the switch took me about five minutes. Try it and let me know what you think.

Prerequisites

AWS CLI v2.32.0+ installed
uv installed (for the proxy)
Valid AWS credentials

The Agent Toolkit itself is free. You only pay for the AWS resources your agent provisions or interacts with, at standard pricing. There are default quotas to be aware of, the main one being 3 requests per second per account. Fine for individual use, but worth knowing if you have multiple agents running in the same account.

Disable conflicting servers

If you have any of the old awslabs MCP servers configured (like aws-mcp-server or aws-documentation-mcp-server), disable them to avoid tool conflicts. You can always re-enable them later if you need to compare.

MCP Configuration

Using Claude Code, Cursor, or something else? Check the GitHub repo for setup instructions across platforms.

For Kiro, add this to ~/.kiro/settings/mcp.json:

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

Two regions in this config. The endpoint in the URL (us-east-1 or eu-central-1) is where the MCP Server itself runs. AWS_REGION is where your AWS resources live, set it to the region you work in. So, change the AWS_REGION fr your workloads.

If you use a named profile:

"args": [
  "mcp-proxy-for-aws==1.6.0",
  "https://aws-mcp.us-east-1.api.aws/mcp",
  "--metadata", "AWS_REGION=us-west-2",
  "--profile", "your-profile-name"
]