Agent Toolkit for AWS Gives Coding Agents Live Docs and Guardrails

Brooke Jamieson presents Agent Toolkit for AWS as a response to a specific failure mode in coding agents: the agent may be capable, but still unreliable on AWS workflows because services, APIs, and recommended procedures change faster than model training data. In her examples, an agent might skip a required IAM permission or call an API that changed six months earlier.

The demo target is narrow and operational: deploy a Python 3.12 Lambda function behind an API Gateway HTTP API in us-east-1, return "hello" on GET /, name the resources hello-demo, and use the AWS MCP server and skills.

The final visible output shows a terminal response of hello% and a deployment summary listing resources in us-east-1: an IAM role named hello-demo-role, a Lambda function named hello-demo running Python 3.12, an HTTP API named hello-demo, and an endpoint at https://35cs6koh28.execute-api.us-east-1.amazonaws.com/. The route is scoped to GET / only, with proxy integration and payload format v2.

Jamieson’s larger point is not just speed. Each AWS API call ran through the MCP server on her IAM credentials, and each call landed in CloudTrail. If a policy had restricted agent-initiated requests, she says those restrictions would have applied to every step.

The displayed CloudTrail example shows the kind of record AWS expects teams to inspect: an "eventName" of "CallTool", an "eventType" of "AwsMcpEvent", an "eventSource" of "aws-mcp.us-east-1.api.aws", a call_aws method carrying an AWS CLI command such as aws iam create-role --role-name hello-demo-lambda-role ..., and a userIdentity attached to an IAM role ARN.

Agent Toolkit for AWS has four parts: the AWS MCP server, Agent Skills, plugins or MCP configuration, and rules files. Together, they give a coding agent current AWS documentation, a controlled path for API calls, task-specific runbooks, and project-level instructions for how AWS work should be handled inside a repository.

The AWS MCP server is the path to current documentation and authenticated API calls. Jamieson contrasts that with relying on an agent’s training data alone: the server searches the actual AWS docs in real time and lets the agent make calls using the developer’s IAM credentials.

Agent Skills are the procedural layer. A skill is a Markdown runbook for a specific AWS task, written by someone who has run the workflow and found where agents get stuck. Jamieson says skills are compact: a few thousand tokens, rather than the tens of thousands that could come from pasting a full documentation page into context. The agent discovers skills through the MCP server, loads the one it needs, follows it during the task, and drops it when the task is done.

Rules files are project-level configuration. They tell the agent how to behave in a repository — for example, to use the MCP server for API calls or search for a skill before starting an AWS task. The toolkit itself is free; users pay for the AWS resources the agent creates.

Brooke Jamieson uses the Lambda plus API Gateway workflow to show why AWS is packaging skills rather than relying only on documentation search. The relevant skill includes the add-permission step that grants API Gateway permission to invoke the Lambda function. Agents working from training data alone consistently miss that step, she says. Without it, the API and function may both exist, but they cannot talk to each other.

In the demo, the agent first searched for relevant skills and documentation through the MCP server, found a skill named connecting-lambda-to-api-gateway, and loaded it. The agent then noticed that the skill was written for REST APIs, while the requested deployment used an HTTP API. Jamieson describes HTTP API as newer, simpler, and cheaper, and says the agent adapted the skill rather than following it mechanically.

From there, the agent created the Lambda function code locally, zipped it, created the IAM execution role with the basic execution policy, waited for IAM propagation, uploaded the zip, and created the Lambda function. It then created the HTTP API with the Lambda integration wired in.

Because the skill included add-permission, the agent ran that step, giving API Gateway permission to invoke the function. The agent also noticed that the API had been created with a catch-all route and scoped it down to GET /, matching the original request. For Jamieson, that combination is the distinction: the agent adapted the runbook where judgment was needed, but did not skip the procedural step that commonly breaks the deployment.

For teams, Brooke Jamieson points to IAM condition keys for agent-initiated actions. Her example is that a developer’s own role may have write access, while the agent can be restricted to read-only access through the MCP server. That gives platform teams a way to let developers use agents for searching docs and loading skills without immediately granting those agents broad write capability.

The MCP server currently runs in two regions: us-east-1 and eu-central-1. That is where the server lives, but the agent can operate on resources in any AWS region.

Jamieson also gives two quotas worth planning around. The service allows 27 concurrent connections per account per region, which she describes as a hard cap, and three sustained requests per second. For one person, she says, that is fine. For larger teams, she recommends watching CloudWatch usage metrics because the 27-connection limit can arrive sooner than expected.

Her recommendation for teams is to begin with read-only access. Let developers get used to agents searching documentation and loading skills before enabling write operations through the MCP server. It is easier to loosen the policy later than to move in the opposite direction.

For Claude Code and Codex, Brooke Jamieson says a plugin bundles the MCP server configuration and a set of skills into one install. The displayed commands for Claude Code are /plugin marketplace add aws/agent-toolkit-for-aws and /plugin install aws-core@aws-agent-toolkit-for-aws; for Codex, the displayed command is codex plugin marketplace add aws/agent-toolkit-for-aws.

For Cursor, Kiro, Windsurf, Cline, Claude Desktop, Claude Code, or any other MCP-compatible client, users add the AWS MCP server directly to the MCP configuration file. The displayed configuration uses uvx, mcp-proxy-for-aws@latest, the AWS MCP endpoint at https://aws-mcp.us-east-1.api.aws/mcp, and region metadata setting AWS_REGION=us-east-1.

Either way, users need AWS credentials configured locally. The agent authenticates with the user’s existing IAM identity, and AWS login or aws configure sso both work.