We’ve all been there. You start a coding agent, ask it to build a serverless API on AWS, and it confidently picks a deprecated Lambda runtime, comes up with an IAM policy that either doesn’t work or gives away too much access, and then spends the next few minutes retrying API calls that changed months ago.
The agent is fast, but if it doesn’t have the right information, it’s still guessing. And when you’re working with AWS infrastructure, those guesses can get expensive.
I ran into this recently while working with the Agent Toolkit for AWS. It gives coding agents access to current AWS documentation, predefined workflows, and controls around how they interact with AWS.
In this post, I’ll explain what the toolkit does, how the different pieces fit together, and how I used it to build a small serverless project in a few minutes.
Why Your Agent Needs a Toolkit
Most coding agents can create the basic structure of an application. The harder part is creating infrastructure that you would actually be comfortable running in AWS.
That means choosing supported services and runtimes, setting permissions correctly, keeping costs under control, and following sensible AWS architecture patterns.
An agent working only from its existing knowledge can easily miss something that changed recently. A service may have introduced a new feature, an API may have changed, or a runtime may have reached the end of its support period.
The Agent Toolkit helps with that in a few important ways:
Knowledge — Curated skills provide step-by-step guidance for common AWS tasks instead of leaving the agent to work everything out from scratch.
Current documentation — The toolkit can retrieve AWS documentation when it needs it, giving the agent access to information that may be newer than its original training data.
Controls — The AWS MCP Server provides IAM-based access controls and monitoring, giving you more visibility into what the agent is doing.
The simple idea is that the agent has access to the information and procedures it needs instead of having to rely entirely on what it already knows.
The Three Main Pieces
The toolkit is made up of several components. These are the three that matter most when you’re actually using it.
The AWS MCP Server
The AWS MCP Server provides a way for an agent to interact with AWS through the Model Context Protocol.
Rather than giving the agent unrestricted access to a local AWS CLI environment, you can have it work through the MCP Server and apply controls around those requests.
Some of the main capabilities include:
Broad AWS coverage: Access to hundreds of AWS services and thousands of API actions.
Isolated execution: Python scripts can run in an isolated environment without access to your local filesystem or network.
Current documentation: AWS documentation and API references can be searched when needed.
Monitoring and access control: Activity can be monitored through CloudWatch, while IAM can be used to control what the agent is allowed to do.
Agent Skills
Skills are collections of instructions, scripts, and reference material for specific AWS tasks.
The useful part is that they can be loaded when they’re needed rather than putting every possible instruction into the agent’s context from the beginning.
They include things such as:
Decision guides for choosing between AWS services.
Procedures for tasks such as deploying serverless applications or setting up pipelines.
Troubleshooting steps for common errors.
Runtime discovery, allowing the agent to find relevant skills when it needs them.
This makes the process more repeatable, particularly for tasks that involve several AWS services or configuration steps.
Rule Files
Rule files let you define project-level instructions for how the agent should work.
For example, you can tell it to use the MCP Server for AWS API calls, look for relevant skills before starting a task, check its work against current documentation, and prefer infrastructure as code over manual CLI commands.
Once those rules are in place, you don’t have to repeat the same instructions every time you start a new session.
Setting It Up
Getting started was straightforward:
aws configure agent-toolkitThis requires AWS CLI 2.35 or later. The command detects supported agents, installs the skills, and configures the MCP Server.
There’s no separate charge for the toolkit itself. You still pay for whatever AWS resources you create and use.
If you’re using a specific coding agent, there are also plugins for Kiro, Claude Code, Cursor, and Codex. Other MCP-compatible agents can connect to the server using their own configuration.
You’ll need uv to run the MCP proxy, along with AWS credentials if you want the agent to make API calls. Documentation searches can be used without AWS credentials.
Building a Serverless API
This is where I found the toolkit most useful.
I wanted to build a simple REST API using Amazon API Gateway and AWS Lambda. The idea was straightforward: put an API endpoint in front of a Lambda function so I could call a URL and get a response.
The architecture itself isn’t complicated, but there are several details that have to be configured correctly. You need the right Lambda runtime, the API Gateway resource and method, the integration, the deployment stage, and the permission that allows API Gateway to invoke the Lambda function.
I gave the agent a simple instruction:
“Create a Lambda function with a current Python runtime and put an API Gateway REST endpoint in front of it, so I can hit a URL and get a response back.”
The agent then worked through the setup.
1. It found the relevant procedure
Instead of immediately trying to build everything from memory, it found the serverless skill through the MCP Server and used the procedure for connecting Lambda and API Gateway.
That gave it a defined workflow to follow rather than leaving every configuration decision up to the model.
2. It selected a supported Lambda runtime
This is one of the easier places for an agent to get things wrong.
AWS Lambda runtimes change over time, and an agent relying on older information can easily choose one that is deprecated or approaching its end of support.
Because the toolkit can check current AWS documentation, the function was created using a supported Python runtime.
3. It created the Lambda function and API
The agent created the Lambda function and then configured the API Gateway REST API.
It created the API resource and method and connected the API to Lambda using the appropriate integration.
4. It configured the Lambda permission
This is one of the configuration details that can be easy to miss.
API Gateway needs permission to invoke the Lambda function. Without the appropriate resource-based policy, the API can be created successfully but fail when you actually call it.
The agent added the required lambda:InvokeFunction permission as part of the setup.
5. It deployed the API
Finally, it created the deployment stage and returned the API’s invoke URL.
I called the endpoint and received the expected response.
That entire process took a few minutes.
Without the toolkit, this type of task can easily turn into a debugging session. You might start with an outdated runtime, miss the Lambda permission, use the wrong API Gateway integration, or spend time figuring out why an API that appears to be configured correctly is returning an error.
The difference here wasn’t that the agent suddenly became capable of building AWS infrastructure. It had access to the current documentation and a defined procedure for the task, which removed a lot of the guesswork.
The Governance Side Matters Too
The part I found particularly useful was the control over what the agent can actually do.
When commands are run through a local terminal, it can be difficult to separate actions performed by an agent from everything else happening through the same credentials.
With the MCP Server, IAM policies can be used to apply controls specifically to actions going through the server.
For example, you can restrict an agent to read-only access in a production environment, even if the underlying IAM role has broader permissions.
CloudWatch and CloudTrail can also provide visibility into requests and activity, giving you a record of what happened and which operations were performed.
That becomes increasingly important as you move from experimenting with an agent to allowing it to work against real AWS environments.
Is It Worth Using?
It depends on how you’re using coding agents with AWS.
A few questions are worth considering:
Are you regularly dealing with outdated AWS APIs or runtimes? Current documentation can help reduce those problems.
Do you need tighter control over what an agent can do? IAM policies and monitoring provide a way to put those controls in place.
Are you building the same types of AWS infrastructure repeatedly? Curated skills can provide repeatable procedures instead of starting from scratch each time.
Are you already using Kiro, Claude Code, Cursor, or Codex? The available plugins make it relatively straightforward to connect the toolkit to those environments.
The Agent Toolkit for AWS doesn’t remove the need to understand AWS or review what an agent is doing. What it does is give the agent better access to current information, documented procedures, and the permissions and monitoring needed to work more safely.
For my serverless example, that meant I could describe the infrastructure I wanted and have the agent handle most of the configuration without spending the rest of the afternoon fixing small AWS integration issues.
That’s a practical improvement, and for anyone already using coding agents to work with AWS infrastructure, it’s worth taking a look at.