Agent Toolkit for AWS: What the Official MCP Servers and Skills Actually Install

The gap between an agent that writes AWS code and one that can act on AWS

A coding agent can produce a CDK stack or a Lambda handler without any special tooling. What it cannot do by default is confirm that the service name it invented exists, read current AWS documentation, or call an API to check the state of a resource it just described. The Agent Toolkit for AWS is AWS's attempt to close that gap. The README frames the goal as giving agents "the tools, knowledge, and guardrails they need to work with AWS services." The audience is narrow and specific: developers who already use Claude Code, Codex, Cursor, Kiro or fx as their primary coding interface and want AWS context inside that interface rather than in a separate browser tab. It is not a library you import into an application. Nothing in the README suggests you call it from your own Python code, despite the repository being primarily Python. The unit of adoption is a developer's editor or terminal, not a service.

Plugins, skills and an MCP server are three different things

The README describes two layers that are easy to conflate. The first is the AWS MCP Server, reached over HTTP at https://aws-mcp.us-east-1.api.aws/mcp and proxied locally through mcp-proxy-for-aws-cli. It provides runtime AWS API access, sandboxed script execution, and real-time documentation search. The second is skills: directories containing a SKILL.md file and optionally a references/ subdirectory that the agent reads from the local filesystem when a task matches. Kiro and fx both document these as independent. Skills do not require the MCP server, and the MCP server does not serve locally installed skills. Plugins are the packaging layer that bundles both for marketplaces. The aws-core plugin covers service selection, CDK and CloudFormation, serverless, containers, storage, observability, billing, SDK usage and deployment. aws-agents covers Bedrock and AgentCore. aws-data-analytics covers S3 Tables, Glue and Athena. aws-agents-for-devsecops covers incident investigation, code review, UAT for release readiness, vulnerability scanning and penetration testing. That is a wide surface, and the README does not describe how the skills are selected at runtime beyond saying agents activate them on demand when a task matches.

Installing per agent: the commands differ more than the docs suggest

Claude Code installs from the official Anthropic marketplace, which the README says is added by default: /plugin install aws-core@claude-plugins-official, with aws-agents, aws-data-analytics and aws-agents-for-devsecops following the same pattern. The devsecops plugin additionally needs /plugin marketplace add aws/agent-toolkit-for-aws, /reload-plugins, and a setup step at /aws-agents-for-devsecops:setup. Codex takes a different path: codex plugin marketplace add aws/agent-toolkit-for-aws, then /plugins inside the session. Cursor is configured through the GUI at Settings, Plugins, Team Marketplaces, Import from Repo, pointing at the repository, after which Cursor indexes .cursor-plugin/marketplace.json. Kiro and fx both require manual MCP configuration. Kiro uses .kiro/settings/mcp.json with an mcpServers key, a command of uvx and args beginning with mcp-proxy-for-aws-cli@latest. fx stores servers in ~/.fx/mcp.json and uses a different shape: an mcp key, a type field, and a single command array. Skills install with npx skills add aws/agent-toolkit-for-aws/skills, plus -a fx for fx and -g for a global install. The AWS CLI path is the odd one out: aws configure agent-toolkit, with no further detail in the README beyond a link to the user guide. Note the version pinning: the MCP proxy is referenced as mcp-proxy-for-aws-cli@latest, so every install resolves to whatever is current.

The prerequisites, and what breaks without them

uv is required. The README states this for Kiro and fx, and since both invoke uvx to launch the proxy, the same applies anywhere uvx is the launcher. AWS credentials are a softer requirement. The README is explicit that an account with credentials configured locally is needed for API calls and script execution but not for documentation search or skill discovery. That split is worth reading carefully, because it means a developer can install the skills, get guidance on CDK patterns, and still have every API call fail silently or loudly depending on how the agent handles the error. The README does not describe that failure mode. The sandboxed script execution feature is named but not specified: there is no description of what sandbox is used, what the isolation boundary is, or which IAM permissions the proxy assumes. For a tool that can execute scripts against a live AWS account, that is the largest documentation gap in the material.

No releases, and what that means for pinning

The repository has no releases retrieved, and the README does not mention a versioning scheme for skills or plugins. Combined with the @latest reference on the MCP proxy, this means there is no documented way to freeze the toolkit at a known state. Skills live as files in a repository that changes on main. A team that needs a reproducible agent environment, where the instructions an agent follows on Monday are the same on Friday, has no documented mechanism here. The Apache-2.0 licence is permissive and places no copyleft obligation on your own code, but it also provides no warranty, and the README does not discuss support terms or an SLA. For an AWS-supported project, that distinction matters: official does not automatically mean covered by a support plan. Confirm separately whether your AWS support agreement extends to this toolkit before treating it as production infrastructure.

Where a general MCP server or a hand-written prompt does better

The alternative most teams will weigh is a general-purpose MCP server that exposes AWS API calls through a single generic tool, paired with prompts the team writes itself. The difference is in where the knowledge sits. This toolkit pushes service-specific guidance into skill files that ship with the repository and are updated by AWS, so the agent reads curated instructions for, say, S3 Tables or Athena rather than reasoning from a generic API surface. The generic server keeps the tool count low and the behaviour predictable, at the cost of the agent knowing less about service selection and deployment patterns. The second alternative is doing nothing beyond the agent's built-in knowledge, which works until the agent invents a parameter name. The third is a purpose-built internal wrapper around the AWS SDK, which gives you full control over which calls are permitted and logged but requires you to maintain it. The toolkit's advantage is that the maintenance sits with AWS. Its disadvantage is that the same fact makes the surface move without notice.

Who should install this, and what to check before you do

Install it if your team already lives in one of the five supported agents, wants AWS documentation search without leaving the session, and is comfortable with skills arriving from a moving main branch. The aws-core plugin is the reasonable starting point the README itself recommends. Do not install it if you need a pinned tool surface for compliance reasons, if you cannot guarantee uv on developer machines, or if you are not prepared to reason about what sandboxed script execution means for your account. Before rolling it out, check three things: that uvx resolves on each machine, that your configured credentials are scoped to what you are willing to let an agent execute against, and whether the AWS support plan you hold covers this toolkit. The README's own troubleshooting note, that a Plugin not found error means running /plugin marketplace update claude-plugins-official, is a small signal about how much of the setup depends on marketplace state outside your control.

Editorial conclusion

Adopt it if your team already drives Claude Code, Codex, Cursor, Kiro or fx and wants AWS API access plus local skill files rather than a bespoke tool wrapper. Skip it if you need a pinned, auditable tool surface today, since the README ships no releases and no versioning policy for the skills. Before rollout, verify the uv prerequisite on every developer machine and confirm whether your AWS credentials grant the sandboxed script execution the MCP server advertises.

Official sources

1. aws/agent-toolkit-for-aws on GitHub
2. Issues
3. License: Apache-2.0
4. README