AWS just moved agent skills into the cloud developer toolchain.

On August 26, AWS published Agent Toolkit for AWS, a new AWS CLI flow that installs AWS-maintained skills into coding agents. The same setup can also configure access to the AWS MCP Server.

That is a real change for cloud work. General model knowledge gets old fast around S3, Lambda, IAM, CDK, Bedrock, and the hundreds of service defaults that change underneath them. AWS is now packaging some of that moving knowledge as instructions an agent can load before it starts editing code.

What AWS released

The toolkit is installed through the AWS Command Line Interface. Developers need AWS CLI version 2.35.0 or newer, then run:

aws configure agent-toolkit

The wizard detects supported AI coding agents on the local machine, including Kiro, Claude Code, Codex, Cursor, and other supported agents. For each selected agent, it installs a default set of AWS skills and can configure a connection to the AWS MCP Server.

AWS describes the skills as curated Markdown files maintained by AWS service teams. They tell an agent how AWS services work, which APIs to prefer, and which security patterns to follow. Developers can manage them from the CLI: list installed skills, search the catalog, add new ones, update existing ones, or remove the ones that do not fit a project.

For CI systems and dev containers, AWS also supports:

aws configure agent-toolkit --yes

That option matters because agent setup cannot stay trapped on one developer’s laptop forever. If a team expects consistent output, the agent context has to be reproducible too.

Why this matters for skills

Agent skills started with a plain idea: package task-specific instructions so an AI agent can do repeatable work with fewer bad guesses. AgentNDX has covered that pattern in what are agent skills and in the skills vs. MCP servers comparison.

AWS taking this route is not just another docs update. The company is publishing instructions for agents to use directly, not only pages for humans to read.

A few things stand out.

First, the skills come from the service provider. If an AWS service team changes its recommendation for a service, the agent can pick that up through an updated skill instead of relying on stale model memory.

Second, the toolkit is agent-neutral. AWS is not betting on one coding agent. It supports Kiro, Claude Code, Codex, Cursor, and more through the same AWS CLI path. That matches how teams actually work now: mixed editors, mixed agents, one cloud platform.

Third, the toolkit pairs skills with MCP. Skills tell the agent what to do and how to reason about AWS. The Model Context Protocol connection gives the agent a structured way to inspect resources, search docs, and call AWS APIs using existing IAM credentials.

Skills and MCP are better together

This release is a clean example of the split between instruction and capability.

A skill is instruction. It can tell an agent that a serverless document processing app should use S3 for objects, S3 Vectors for semantic search, and IAM policies scoped to the minimum required actions. It can also warn the agent away from older patterns.

An MCP server is capability. It gives the agent tools for looking up resources, reading service metadata, or calling APIs through a defined protocol.

Put them together and the agent has better judgment and better hands. The skill shapes the plan. The MCP server gives the agent a safer way to act on that plan.

Expect cloud vendors to copy this pattern. A raw MCP server without guidance can expose a lot of tools while still leaving the agent to guess which one applies. A skill without tools can improve code generation, but it cannot inspect live context. The pair is what makes the workflow practical.

The platform signal

AWS is not alone. Microsoft has already shipped built-in .NET and Azure agent skills in Visual Studio, which we covered in Visual Studio Adds Built-In Agent Skills. Gradle is also moving toward official skills for build-system guidance.

The pattern is clear now: platform teams are starting to treat agents as users.

That changes the competitive checklist for developer tools. In the past, a platform needed readable docs, SDKs, examples, and maybe a CLI. Now it also needs agent-ready instructions and protocol access. Developers are going to ask agents to use these platforms either way. The only question is whether the agent works from maintained guidance or from half-remembered training data.

For AgentNDX, this is exactly the kind of movement the directory exists to track. Developers are no longer choosing only libraries and APIs. They are choosing the agent-facing layer around those libraries and APIs: skills, MCP servers, toolkits, registries, and install paths.

What developers should do now

If your team builds on AWS and uses a coding agent, start simple: upgrade the AWS CLI, run the toolkit setup, and inspect the skills that were installed.

Do not treat them as magic. Read them the same way you would read a generated migration or a third-party GitHub Action.

Then add skills based on the project. AWS gives an example of searching for a vectors skill before building with Amazon S3 Vectors. That is the right mental model: install the baseline set, then add service-specific guidance when the project moves into newer or more specialized AWS services.

For teams, decide where this setup belongs. A solo developer can use the interactive wizard. A platform team should think about dev containers, CI images, or onboarding scripts so the same agent context exists across machines.

FAQ

Q: Is Agent Toolkit for AWS an MCP server? A: No. It is a toolkit that installs AWS skills and can configure the AWS MCP Server. The skills provide guidance. The MCP Server provides structured access to AWS APIs and documentation.

Q: Which coding agents does it support? A: AWS lists Kiro, Claude Code, Codex, Cursor, and other popular AI coding agents as supported. The AWS CLI setup detects supported agents installed on the machine.

Q: Why not just let the model use AWS documentation? A: General documentation is written for humans and may not be loaded into the agent session. Skills package current, task-specific AWS guidance where the agent can use it during coding. That reduces stale assumptions and makes service-team recommendations easier to apply.

Q: Does this replace human AWS review? A: No. It improves the agent’s starting point, but cloud changes still need review for cost, IAM scope, data handling, and production risk. Treat the toolkit as better context, not approval to ship unchecked infrastructure.