AWS AI Agent Toolkit MCP Skills: The Official Way to Let Coding Agents Build on AWS

The AWS AI agent toolkit MCP skills package is the first time AWS itself has shipped a supported, coherent way for coding agents to work on its cloud. Instead of pasting IAM keys into a chat window and hoping the agent guesses the right service, you install a plugin, connect a managed MCP server, and give the agent curated skills for the job at hand. The repository behind it, aws/agent-toolkit-for-aws, carries 3,354 stars and 421 forks on GitHub, is licensed Apache 2.0, and is marked generally available. This guide explains what it actually contains, how to install it for Claude Code, Codex, Cursor, Devin, Kiro and fx, and — most importantly for any business — the guardrails to put in place before an agent touches a production account.

What AWS AI Agent Toolkit MCP Skills Actually Give Your Agent

Three pieces, and the distinction between them matters because teams keep installing one and expecting the other two to do the work. First, the AWS MCP Server: a managed server that gives an agent access to AWS through the Model Context Protocol. It covers more than 300 AWS services through a single authenticated endpoint, offers sandboxed Python script execution for multi-step operations, and lets the agent search current AWS documentation without authentication. Second, agent skills: curated packages of instructions and reference material for specific AWS tasks, loaded on demand, so the agent retrieves only the skill relevant to the current task rather than carrying the whole of AWS documentation in context. Third, plugins: bundles that combine the MCP server configuration and the skills into a single install for a coding agent. Plugins are currently available for Claude Code, Codex, Cursor and Devin; other agents configure the MCP server directly and install skills from the repository. Rules files are the fourth, quieter piece: project-level configuration that tells an agent to use the MCP server, discover skills, and search documentation before acting, instead of improvising.

What It Can Do: The Five Plugins

• aws-core — start here. Service selection, CDK and CloudFormation, serverless, containers, storage, observability, billing, SDK usage and deployment.
• aws-agents — building AI agents on AWS with Amazon Bedrock and AgentCore.
• aws-data-analytics — data lake, analytics and ETL workflows with S3 Tables, AWS Glue and Athena.
• aws-agents-for-devsecops — investigate incidents, review code, run user-acceptance testing for release readiness, scan code for vulnerabilities and run penetration tests with the AWS DevOps Agent and AWS Security Agent.
• aws-startup-advisor — an AWS Startups Solutions Architect inside your coding assistant: the smallest architecture for your stage, credits and team, scaffolding, migration from Azure, Google Cloud or Heroku, moving model calls to Bedrock, incident investigation, and AWS Activate credits eligibility.

That plugin list is the real product strategy. AWS is not shipping one generic “cloud agent”. It is shipping opinionated workflows for the jobs teams actually hand to agents, each with skills that have been evaluated end to end. If your team only ever does one kind of AWS work, you only need one specialist plugin on top of aws-core — and that restraint is a feature, not a limitation.

How It Works in Practice

An agent’s workflow with the toolkit looks different from the old copy-paste pattern in three ways. First, documentation is retrieved at runtime, so the agent works from current service capabilities rather than whatever its training data remembered. Second, multi-step work can run as sandboxed Python scripts through the MCP server instead of a long chain of chat turns, each of which can drift. Third, every request is observable: CloudWatch metrics and CloudTrail audit logging cover MCP server activity, so agent actions show up in the same audit trail as human ones.

The enterprise control that matters most is IAM. The toolkit supports IAM condition keys that distinguish agent actions from human actions. In plain terms, you can write a policy that allows only read-only actions through the MCP server even when the underlying IAM role could write. That single capability turns “let the agent look at our AWS account” from a gamble into a policy decision. This is also why AWS positions the toolkit as the successor to the AWS Labs MCP servers, skills and plugins released through 2025. Those still work and still accept contributions, and the best of them will migrate over time. The toolkit adds the agent-versus-human IAM distinction, the CloudWatch and CloudTrail observability, and the evaluated skills. If you are starting fresh, start with the toolkit, not with a scattered set of AWS Labs servers.

Installation: One Command per Agent

• AWS CLI: run aws configure agent-toolkit, then follow the AWS CLI integration guide in the official user guide.
• Claude Code: run /plugin install aws-core@claude-plugins-official (update the marketplace index first if you get “Plugin not found”); add aws-agents and aws-data-analytics the same way, and install aws-agents-for-devsecops and aws-startup-advisor from this repository’s marketplace.
• Codex: run codex plugin marketplace add aws/agent-toolkit-for-aws, then browse plugins in the app.
• Cursor: add the repository as a team marketplace from Settings, Plugins, Team Marketplaces, Import from Repo, then install aws-core first.
• Devin: run devin plugins install aws/agent-toolkit-for-aws#plugins/aws-core (after devin auth login), or add it from the web app under Customize, Plugins, Add plugin, From repository.
• Kiro and fx: add the AWS MCP Server (via uvx mcp-proxy-for-aws-cli@latest pointing at the managed endpoint, with your region as metadata), then run npx skills add aws/agent-toolkit-for-aws/skills. Note the two parts are independent: skills do not require the MCP server, and the MCP server does not serve locally installed skills. You need uv installed, and an AWS account with credentials configured locally for API calls and script execution — documentation search and skill discovery do not need credentials.

Why It Is Trending Now

Three forces converged. Coding agents moved from novelty to daily tooling, so the question changed from “can an agent write code” to “can an agent safely operate the cloud that code runs on”. Agent skills became a distribution format in their own right, with teams installing skill packs the way they once installed libraries. And AWS, which had scattered its agent tooling across AWS Labs, consolidated it into one supported, generally available home. The repository was created in April 2026 and was still being updated on 30 October 2026, which is a useful signal: this is a living project, not a launch-week demo. For agencies and product teams, the practical consequence is that “our agent knows AWS” is now a checkable claim — you can point at a plugin, a skill and an audit log — rather than a vibe. Browse the full set of tools we track in our AI Tools Directory.

From Our Experience: The Guardrails Before the First Real Task

We build AI integration and automation for clients, and the pattern that keeps projects safe is boring on purpose. Start read-only. Give the agent an IAM role whose MCP-server actions are read-only, even if the human role behind it can write, and watch a week of CloudTrail logs before you widen anything. Keep production out of the first project entirely: let the agent work in a sandbox account, deploy to staging, and earn production access with a reviewed pull request, not a chat prompt. Treat skills as code review: read the SKILL.md file you install, because a skill is instructions your agent will follow, and an unreviewed skill is an unreviewed dependency. Budget for the learning curve: the toolkit removes the “which service” guessing, but it does not remove the need for someone who understands IAM, networking and cost to review what the agent proposes.

The most expensive failure we see is not a wrong service choice; it is an agent that provisions generously, leaves resources running, and nobody notices until the bill arrives. Set billing alerts on the sandbox account on day one, and make teardown part of the task definition, not an afterthought. When not to use it: if your team has no AWS account hygiene at all — shared root credentials, no tagging, no billing alerts — fix that first. An agent multiplies whatever process already exists, good or bad. And if the task is a one-off deployment you will never repeat, the setup cost may exceed the saving; the toolkit pays back on repeated AWS work, not on a single static site.

Getting Started in Six Steps

1. Create or pick a sandbox AWS account, separate from production, with billing alerts enabled.
2. Install aws-core in the coding agent your team already uses; do not introduce a new agent and a new toolkit in the same week.
3. Configure the AWS MCP Server with least-privilege credentials and, where possible, agent-only read-only conditions.
4. Run a read-only task first: ask the agent to inventory a service you already run and compare its findings with the console.
5. Add one specialist plugin for your next real job — aws-data-analytics for a pipeline, aws-agents for a Bedrock project — and review its skill files.
6. Review CloudTrail and CloudWatch output for agent activity, then decide, deliberately, what write access to grant next.

Frequently Asked Questions

Is the Agent Toolkit for AWS free?

The repository is open source under Apache 2.0, so the plugins, skills and rules files cost nothing to install. You still pay normal AWS usage charges for whatever the agent provisions, and for the model calls your coding agent makes. The cost to watch is provisioned infrastructure, not the toolkit.

Does it replace the AWS CLI or the AWS console?

No. The AWS CLI remains the way to configure the toolkit from a terminal, and the console remains where humans review and approve. The toolkit gives agents a structured, auditable way to use the same underlying AWS APIs, with documentation search built in.

Which plugin should a team install first?

aws-core, without debate. It covers service selection, infrastructure as code, serverless, containers, storage, observability, billing and deployment — the groundwork every other plugin assumes. Add a specialist plugin only when you have a concrete job for it.

Can an agent make changes to my production AWS account through it?

Only if the IAM policy you give it allows that. That is the point of the agent-versus-human IAM condition keys: you can restrict MCP-server actions to read-only even for a role that could otherwise write. Keep production write access out until a human-reviewed workflow has earned it.

What happens to the older AWS Labs MCP servers?

They continue to work and accept contributions, and AWS says the best of them will transition into the toolkit over time. New projects should start with the toolkit, and existing AWS Labs setups can migrate plugin by plugin rather than in one jump.

If your team is already letting coding agents near AWS — formally or informally — the toolkit is the moment to make that official, observable and least-privilege. Start with aws-core in a sandbox account, read the skill you install, and let the audit log, not optimism, decide when the agent earns wider access. If you want help setting that up — sandbox accounts, IAM policies for agents, and a first Bedrock or serverless workload built properly — talk to MTD Technologies; we have spent nine years shipping this kind of infrastructure for clients, and the agent era has not changed the rule that the boring guardrails are what make the exciting work safe.