The Agent Toolkit for AWS is the least glamorous, most useful thing AWS shipped this quarter: one AWS CLI command that stops your AI coding agent from confidently making things up about your cloud. Run aws configure agent-toolkit once, and Kiro, Claude Code, Codex, and Cursor all get the same curated, AWS-maintained knowledge layer plus a live, auditable connection to real AWS APIs. No more guessing which S3 API is current this month.
What the Agent Toolkit for AWS actually installs
The command isn’t magic — it’s a wizard that does two concrete things. First, it detects which supported agents live on your machine and lets you pick which ones to configure. Second, for each agent you select, it installs a default set of AWS skills — a curated catalog of Markdown files, each one maintained by the actual AWS service team that owns the feature — and wires up a connection to the AWS MCP Server. That’s the whole trick: static knowledge (skills) plus live capability (MCP), bundled into a setup step that takes seconds.
# Requires AWS CLI v2.35.0+
aws configure agent-toolkit
# Non-interactive (CI, dev containers)
aws configure agent-toolkit --yes
The interactive version prompts you per agent; --yes accepts the defaults, which is what you want baked into a Dockerfile or a CI image so every fresh environment gets the same agent context without a human clicking through a wizard.
The AWS MCP Server: the part that actually moves the needle
Skills are documentation your agent reads before it writes code. The AWS MCP Server is different — it’s a live connection, built on the Model Context Protocol, that lets your agent list resources, search documentation, and call AWS APIs directly using your existing IAM credentials. That last part matters: it’s not a shadow credential or a scraped API key sitting in a config file somewhere. It rides on the permissions you already have, which means every call it makes is attributable to your identity and shows up wherever you’d expect an IAM-authenticated call to show up.
Compare that to what an agent does without it. Ask a raw LLM-backed coding agent to “spin up an S3 bucket with the right access controls” and it’s reasoning from training data with a knowledge cutoff, or from whatever it scraped off a web search — half of which is a Stack Overflow answer from 2019 recommending a bucket policy AWS deprecated the security guidance on years ago. With the MCP Server in the loop, the agent can actually query current AWS state and current API shapes instead of pattern-matching against stale internet noise.
Curated skills vs. “the model already knows AWS”
Every modern coding agent has some AWS knowledge baked into its training. The problem is staleness and specificity. AWS ships new services and deprecates old API shapes constantly — a model trained even a year ago doesn’t know about a feature that shipped last month, and it has no reliable way to tell you it doesn’t know. It’ll just answer anyway, confidently, with the wrong SDK call.
The skills catalog closes that gap by being versioned and owned by the people who build the service. When a service team ships a new capability, they can ship a skill alongside it. Your agent picks it up the next time you run aws agent-toolkit update-skill, not the next time some foundation model gets retrained.
# See what's currently installed
aws agent-toolkit list-installed-skills
# Search the full catalog for something not in your default set
aws agent-toolkit search-skills --search-query vectors
# Install a specific skill by name
aws agent-toolkit add-skill --skill-name storing-and-querying-vectors
# Target a single agent instead of all detected agents
aws agent-toolkit add-skill --skill-name aws-cdk --agent claude-code
That last example is the real-world case AWS calls out directly: build a serverless document pipeline that needs semantic search over uploaded files, reach for Amazon S3 Vectors since it’s new enough that the default skill set won’t include it, and your agent has zero context on it until you go get the skill. search-skills finds it, add-skill installs it, and the agent’s next suggestion actually uses the current API instead of hand-rolling a vector index in DynamoDB because that’s the pattern it remembers from training.
Supported agents, and why that list matters
The toolkit currently targets Kiro, Claude Code, Codex, and Cursor, with more agents landing over time. That’s a deliberate design choice worth noticing: AWS didn’t build a Kiro-only feature and call it a day. The skills catalog and the MCP Server are agent-agnostic infrastructure. Whichever tool your team standardizes on — or if half your engineers use Cursor and the other half live in the terminal with Claude Code — everyone gets the same underlying AWS expertise instead of five different flavors of “pretty sure this is right.”
Managing the toolkit as a moving target, not a one-time setup
The mistake teams will make with this is treating aws configure agent-toolkit as a one-and-done install. It isn’t. The whole value proposition depends on the skills catalog and the MCP Server staying current, which means the setup command is really the start of a small maintenance habit, not the end of one. Run aws configure agent-toolkit help if you want the full option list without digging through docs — it’s a faster reference than tabbing over to the user guide mid-task.
In practice, that habit looks like a periodic update-skill pass across whatever skills your project depends on, plus an occasional search-skills sweep whenever you pick up a new AWS service. Neither takes more than a minute, and both are easy to script into a weekly CI job so the responsibility doesn’t rest on any one engineer remembering to do it manually.
Why this changes agent behavior in practice
The net effect isn’t that your agent becomes infallible. It’s that the failure mode shifts. Instead of an agent silently hallucinating a plausible-looking but wrong AWS API call, it has a path to check: query the MCP Server for the current resource state, pull the relevant skill for the service in question, and reason from something closer to ground truth. You still review the code. You still own the architecture decisions. But the starting draft is built on this week’s AWS, not last year’s blog post — and that’s a meaningfully better place to start from.
If you’re running agents against production AWS accounts, the skills-plus-MCP model in the Agent Toolkit for AWS is worth adopting even if you’re not fully sold on agentic coding yet — the marginal cost is one CLI command and a few seconds, and the upside compounds every time a service team ships an update. Full command reference lives in the Agent Toolkit for AWS User Guide, and the project takes issues on the AWS CLI GitHub repo if you hit something worth reporting.
At Enkompass (enkompass.net), this is our home turf. We’ve shipped production AI-agent tooling on AWS that actually ships code safely, not just demos well. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.