Agent Toolkit for AWS: Stop Letting Your Agent Half-Remember APIs

There's a specific failure mode I've watched dozens of times now, and you've probably lived it too. You ask your agent to set up an S3 bucket with the right lifecycle policy, or to wire a Lambda behind an API Gateway, or to provision an RDS instance with sane defaults. The agent writes something that looks right. The IAM policy has the right shape. The CLI flags are mostly there. And then you run it and AWS hands you back a wall of red because the parameter was renamed two years ago, or the service now requires an explicit VPC config, or that "default" the agent confidently invented was never a default at all.

The agent wasn't lying. It was doing the only thing it could: reconstructing an API surface from training data that's frozen in time and blurred across thousands of slightly-contradictory blog posts. AWS has hundreds of services and they change constantly. Asking a model to remember all of that precisely is asking it to memorize a phone book that gets reprinted every Tuesday.

The Agent Toolkit for AWS is AWS's answer to this, and it's the cleanest answer I've seen. Instead of hoping the model remembers, you give it a way to load the current, correct guidance on demand. It ships in the open SKILL.md format, which means it runs in Kiro, Claude Code, Cursor, and Codex without you reformatting anything. Let me walk you through what it actually is, how to set it up per-agent, and the workflows where it earns its keep.

What the Agent Toolkit for AWS actually is

The phrase "agent toolkit" gets thrown around loosely, so let me be precise. Announced in May 2026, the Agent Toolkit for AWS is the officially supported package for bringing AWS expertise into a coding agent. It's not one thing — it's three things that work together:

1. Plugins for Claude Code and Codex. These are the thin integration layer that registers the toolkit with your agent so the skills and the MCP server show up as first-class capabilities rather than something you bolt on by hand.
2. A curated collection of skills. Each skill is a SKILL.md file scoped to a service or a task — deploying a container, building a serverless API, working with a managed database. The skill carries the procedural knowledge: the steps, the gotchas, the verification checks.
3. The AWS MCP Server (GA on May 6, 2026). This is the live, programmatic bridge. Where skills tell the agent how to think about a task, the MCP server lets the agent act and query — pull current resource state, look up correct API shapes, and execute against your account through a controlled interface.

Here's the mental model I use. The skills are the playbook. The MCP server is the field radio. The plugin is the thing that hands both to the right player at the right moment.

The toolkit's whole premise is a separation of concerns: don't make the model memorize AWS, make AWS available to the model. Memorized knowledge goes stale. Available knowledge stays current because it's fetched, not recalled.

That premise is why I recommend this even to people who don't run on AWS yet. Studying how AWS packaged its own expertise into skills is one of the best examples you'll find of the format being used at production scale by a vendor who has every incentive to get it right.

Why service-specific skills beat training memory

Let me make the abstract concrete, because this is the part that actually changes how reliable your agent is.

When a model answers from training memory, three things degrade the answer:

• Recency. Training has a cutoff. Anything AWS shipped or changed after that date simply doesn't exist in the model's head. New services, renamed parameters, deprecated flags — all invisible.
• Blurring. The model didn't memorize the AWS docs verbatim. It absorbed a statistical average of the docs plus every Stack Overflow answer, every outdated tutorial, every half-correct Medium post. The result is plausible-sounding mush.
• No grounding. The model can't check itself. It doesn't know whether the bucket already exists, what region you're in, or which IAM role it's running under. It guesses, and guesses compound.

A service-specific skill fixes the first two by giving the model current, authoritative, narrow guidance exactly when the task calls for it. The MCP server fixes the third by letting the model look at reality before it acts.

Here's a comparison I find clarifying:

Dimension	Agent from training memory	Agent with toolkit (skills + MCP)
API correctness	Frozen at training cutoff, often stale	Current; fetched or verified at task time
Account awareness	None — guesses your setup	Reads real resource state via MCP
Service coverage	Whatever was popular in training data	Curated, maintained per service
Failure mode	Confident wrong answer	Loads guidance, then asks/verifies
Maintenance	You re-prompt every time	Skill updates flow from the repo
Portability	N/A	Same SKILL.md runs in Kiro, Claude Code, Cursor, Codex

The thing I want to underline: this isn't about making the model "smarter." It's about changing where the knowledge lives. The model stays the same. The knowledge moves from frozen weights to a fresh, fetchable layer. That's the entire trick, and it's a good one.

If you want the deeper theory of why feeding an agent the right context at the right moment beats trying to cram everything into a prompt, I've written about that pattern at length in my guide on context engineering — the toolkit is a textbook application of it.

The open format is the quiet superpower

AWS made a decision here that's easy to skip past: they shipped in the open SKILL.md format rather than inventing a proprietary AWS-only thing. That matters more than it sounds.

A SKILL.md is just a Markdown file with YAML frontmatter — a name, a one-line description, and a body of instructions. Any agent that understands the format can load it. So the exact same AWS skill you pull into Kiro also works in Claude Code, in Cursor, in Codex. You write your infrastructure workflow once and it follows you across whatever tool you're using that day.

This is the same open ecosystem that lets community skills like skilld and packaging tools like ship-skills-with-package exist. AWS adopting it is a strong signal: the format is stable enough that a major cloud vendor is willing to bet their official tooling on it. When you learn the format once, you're not learning an AWS thing — you're learning a portable skill that transfers everywhere.

# The shape every SKILL.md shares — AWS's included
---
name: aws-serverless-api
description: Build and deploy a serverless HTTP API on AWS Lambda + API Gateway.
---

# Instructions follow as plain Markdown...

That uniformity is why npx skills add works the same regardless of which AWS skill you're pulling, and why the skills compose with everything else in your toolbox.

Per-agent setup

Setup is per-agent — there's no single global switch, because each agent has its own way of registering plugins and MCP servers. Below are the paths I actually use. The skills install command is the same everywhere; the MCP server wiring differs.

The one command you'll use everywhere

To pull the curated skill collection into any agent that supports the format:

npx skills add aws/agent-toolkit-for-aws/skills

This drops the AWS skills into your project's skills directory. From that point the agent can discover and load them by name when a task matches.

Kiro

In Kiro the flow is two steps: register the AWS MCP Server through MCP config, then pull the skills.

// Kiro MCP config — add the AWS MCP Server
{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": ["awslabs.aws-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "your-profile",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

Then, from your project root:

npx skills add aws/agent-toolkit-for-aws/skills

Now Kiro has both halves: the skills for the how and the MCP server for the act and verify.

Claude Code

Claude Code gets the plugin treatment. Install the toolkit's plugin so the skills and MCP server register together, and add the MCP server to your config:

# Add the AWS MCP server to Claude Code
claude mcp add aws -- uvx awslabs.aws-mcp-server@latest

# Pull the skills
npx skills add aws/agent-toolkit-for-aws/skills

With the plugin installed, Claude Code surfaces the AWS skills automatically and routes MCP calls through the server you configured. Make sure your AWS credentials are resolvable in the environment Claude Code runs in — profile, env vars, or an assumed role all work.

Codex

Codex follows the same plugin-plus-MCP shape as Claude Code. Install the Codex plugin from the toolkit, point its MCP configuration at the AWS MCP Server, and run the skills install command. The instructions in the repo track each agent's current config syntax, which is worth checking because these surfaces move quickly.

Credentials, once

Whatever the agent, the credential story is the same as any AWS tooling: the MCP server uses your standard AWS credential chain. I strongly prefer a named profile scoped to least privilege over long-lived root keys. Set AWS_PROFILE and AWS_REGION in the server's env block and you're done. If you assume roles, make sure the role the server runs under is the one you actually want the agent acting as — because it will act as that role.

Workflow 1: Deployment

This is the bread-and-butter case. You've got an app and you want it on AWS without hand-writing every flag.

A good session looks like this. You ask the agent to deploy a containerized service. Because the deployment skill is loaded, the agent doesn't start improvising — it follows the skill's procedure: confirm the container image and registry, choose the right compute target (ECS, App Runner, or Lambda depending on the workload shape), set up networking, and wire up logging. Crucially, before it provisions anything, it uses the MCP server to check what already exists in your account so it doesn't collide with a resource that's already there.

A realistic exchange:

You: Deploy this Dockerized API to AWS, low traffic, keep it cheap.

Agent: Loading the AWS deployment skill. Checking your account via the
AWS MCP server...
- Region: us-east-1 (from your profile)
- No existing App Runner service named "orders-api" found
- Found an ECR repo "orders-api" with one image, tag v3

Given low traffic and a cost preference, the skill recommends App Runner
over an always-on ECS service. App Runner scales to a low floor and you
pay closer to actual usage. Proceed with App Runner pointed at
orders-api:v3?

You: Yes.

Agent: Creating the App Runner service. I'll set health checks on /healthz
per the skill's defaults and route logs to CloudWatch. Verifying the
service reaches RUNNING before I report success...

Notice three things the toolkit bought you: a current recommendation (App Runner vs. ECS, decided by the skill, not by stale memory), account grounding (it checked for collisions and read your real region), and verification (it waited for RUNNING instead of declaring victory at submit time). That last one is the difference between a deploy that works and a deploy that "worked."

If you want the broader discipline around describing what you want before the agent builds it, my guide on spec-driven development with AI agents pairs well with this — write the deployment spec, let the skill execute it.

Workflow 2: Serverless

Serverless is where half-remembered APIs hurt the most, because the surface is so wide: Lambda, API Gateway, EventBridge, Step Functions, DynamoDB, SQS, and the IAM glue holding them together. The number of ways to get a permission boundary subtly wrong is enormous.

The serverless skill encodes the patterns that actually work and the traps that actually bite. When you ask for a serverless HTTP API, the agent:

• Scaffolds the Lambda with a sane handler signature and the runtime you asked for.
• Creates the API Gateway integration with the correct payload format version (a classic thing the model gets wrong from memory because the format versions changed).
• Generates a least-privilege execution role instead of a wildcard policy, because the skill knows the specific actions the function needs.
• Wires up structured logging and, if you want it, a dead-letter queue for async invocations.

# The kind of handler the serverless skill scaffolds —
# correct event shape for API Gateway payload format v2.0
import json

def handler(event, context):
    method = event["requestContext"]["http"]["method"]
    path = event["rawPath"]
    # ... your logic ...
    return {
        "statusCode": 200,
        "headers": {"content-type": "application/json"},
        "body": json.dumps({"ok": True, "method": method, "path": path}),
    }

The payload format detail is exactly the sort of thing a model fumbles from memory — event["requestContext"]["http"]["method"] is the v2.0 shape, but a model averaging over years of examples will often hand you the v1.0 event["httpMethod"] and leave you debugging a KeyError at runtime. The skill pins the current shape so you don't.

And again, the MCP server closes the loop: after deploying, the agent can invoke the function through the server, read the CloudWatch logs, and confirm the API actually returns 200 before it tells you it's done.

Workflow 3: Database work

Database tasks are the third pillar, and they're where I'm most grateful for grounding. Provisioning an RDS or Aurora instance, choosing instance classes, setting up parameter groups, configuring backups and the maintenance window — these are decisions with real money and real downtime attached.

The database skill gives the agent a checklist that reflects current best practice: pick the engine and version, size the instance to the workload, put it in private subnets, enforce encryption at rest, set a backup retention window, and never leave it publicly accessible by accident. The MCP server lets the agent verify the resulting configuration against what you intended.

A pattern I lean on:

You: Stand up a Postgres database for staging. Small, encrypted,
not internet-facing.

Agent: Loading the AWS database skill. Per the skill's staging profile:
- Engine: PostgreSQL (latest supported minor)
- Instance: db.t4g.micro (burstable, right-sized for staging)
- Storage encrypted with the default KMS key
- PubliclyAccessible: false, placed in your private subnet group
- Backups: 7-day retention, automated

Checking via MCP: your VPC has a private subnet group "staging-db" with
two AZs — good for the subnet placement. Creating now and I'll confirm
the endpoint is reachable only from inside the VPC.

The skill made the defaults defensible, and the MCP server confirmed the facts (the subnet group exists, in two AZs). That combination is what turns "the agent set up a database" from a sentence that makes me nervous into one that doesn't.

For schema and migration work, the same pattern holds: the agent reads the current schema state through the MCP server before generating a migration, so it's editing reality rather than its imagination.

What to verify, every time

The toolkit makes the agent far more reliable, but "more reliable" is not "unsupervised." I treat every agent-driven AWS action as a proposal I approve, not a fact I accept. My standing checklist:

• Read the plan before the apply. If the agent is about to create or modify resources, make it show you the resource list and the IAM changes first.
• Check the blast radius of IAM. A least-privilege role from the skill is the goal, but verify it. Wildcards ("Action": "*" or "Resource": "*") are a smell, not a sentence.
• Confirm the region and account. The MCP server reads these from your profile. Make sure they're the staging/dev ones you think they are, not prod.
• Verify reachability, not just creation. "Created" means the API accepted the request. "Working" means you got a 200 or connected to the endpoint. Insist on the second.
• Watch the cost shape. Always-on instances, NAT gateways, and provisioned capacity add up. Ask the agent to name the cost model of what it's building.
• Keep a teardown path. For anything experimental, have the agent record how to delete it cleanly. Orphaned resources are the tax on agent-driven exploration.

If you want a structured way to pressure-test an agent's plan before you let it run, my grill-me skill is built for exactly that adversarial review step — point it at the proposed change and let it poke holes.

Where the toolkit fits in a bigger setup

I run the Agent Toolkit for AWS alongside a small stack of general-purpose skills, and they compose nicely. The AWS skills handle the cloud-specific how; broader skills handle planning, review, and packaging. If you're building your own internal skills on top of AWS workflows — say, your company's specific deployment conventions — the packaging discipline in ship-skills-with-package is how you'd distribute them to your team in the same open format AWS uses.

And if you're newer to the whole idea of agent skills, start with the landscape view in my roundup of the most popular AI coding skills, then come back here once you've got the format under your fingers. The AWS toolkit is a great second skill to install precisely because it shows you the format being used seriously.

One more honest note on the rating. I have this at 4.7, not 5, for a simple reason: per-agent setup is more friction than a single universal installer would be, and the MCP server's surface evolves fast enough that you'll occasionally hit a config detail that's newer than whatever guide you're reading. The fix is always the same — check the repo. But it's friction, and I'd rather tell you it's there.

Should you install it if you don't use AWS?

Yes, and I mean that. Here's the reasoning.

The Agent Toolkit for AWS is the best-maintained, highest-stakes example of the skills-plus-MCP pattern in the wild. Even if you never deploy to AWS, reading how the skills are scoped, how they hand off to the MCP server, and how they encode verification steps will make your own skills better. It's a reference implementation you can learn from for free.

And the day you do touch AWS — and most of us touch it eventually — you'll have an agent that loads service-specific guidance instead of guessing. That's the whole pitch, and it's a good one: stop letting your agent half-remember APIs. Give it the current docs, on demand, in a format that follows you across every tool you use.

Resources & links

External repositories and tools:

• aws/agent-toolkit-for-aws — the official toolkit: plugins for Claude Code and Codex, the curated skill collection, and pointers to the AWS MCP Server. Start here.
• AWS MCP Server (awslabs) — the AWS Labs MCP server repositories, GA as of May 6, 2026; the live bridge the toolkit uses to read state and act on your account.
• Model Context Protocol — the open standard the AWS MCP Server implements, if you want to understand the wiring.
• npx skills CLI — the installer behind npx skills add aws/agent-toolkit-for-aws/skills.

Internal guides and skills:

• Context engineering — the underlying discipline of feeding agents the right knowledge at the right moment, which the toolkit applies directly.
• grill-me — adversarially review an agent's proposed AWS change before you let it run.
• ship-skills-with-package — package and distribute your own AWS workflow skills to your team in the same open format.
• skilld — a community skill that shows the format AWS adopted, useful for comparison.
• Spec-driven development with AI agents — write the deployment spec first, then let the skill execute it.
• Most popular AI coding skills — where the AWS toolkit fits in the broader skills landscape.
• Agentic automation track — the full learning path this skill belongs to.