If you’re like me, sometimes you get so excited to try something new that you don’t read the docs all the way through before you start using it. Last week, the Agent Toolkit for AWS had just been released, I had the README open, and two minutes later I was asking my agent to design a serverless backend in my Kiro IDE.

But the agent didn’t touch any of the tools I had just configured. It answered from training data and gave me a reasonable API Gateway + Lambda + DynamoDB architecture, but never reached for the MCP documentation search or the aws-core skills I had installed. I had to prompt it to use the MCP server and skills before it gave them a go.

I had skipped one important file in my rush to try out this new toolkit, and it turned out to be the file that made my agent predictably reach for these tools.

The Agent Toolkit for AWS was released on May 6. It works with Claude Code, Codex, Kiro, and any agent that supports MCP, and it has three layers:

1. The MCP Server gives your agent access to 300+ AWS APIs through a single endpoint, plus sandboxed Python execution and real-time doc search (no AWS credentials needed to search docs).
2. Skills are packaged domain expertise, including architecture decision tables, service comparison matrices, deployment workflows, and troubleshooting guides (20+ available today).
3. A rules file tells the agent to use layers 1 and 2 before answering from memory.

I had layers 1 and 2 set up but skipped layer 3, so the agent had all the tools but none of the instructions for using them.

Setup takes two minutes — follow the README’s quick start for your agent (Kiro, Claude Code, Codex, or other MCP-compatible agents).

The file I skipped

There’s a rules file in the toolkit repo’s rules/ directory that I missed when setting it up. The README’s quick start section doesn’t mention it, and I was already typing prompts by the time I could have noticed. But there’s a difference between “can discover skills” and “will proactively load them before answering.” The rules file bridges that gap. It’s 17 lines and tells the agent to:

• Prefer the AWS MCP Server for all AWS interactions
• Before starting a task, check whether a relevant AWS skill is available
• Load the skill with retrieve_skill and prefer its guidance over general knowledge
• When uncertain about API parameters, permissions, or limits, verify against documentation rather than guessing

For more information on where to put the rules file for different agents, check out the docs here.

“There’s a difference between ‘can discover skills’ and ‘will proactively load them before answering.’ The rules file bridges that gap.”

Before I added this file, the agent had passive access to skills, but after I dropped it in, skill loading became the agent’s first move on any AWS question, and it started pulling architecture decision tables before writing code.

For a simple CRUD app like the one I was building, the AWS MCP skills refined the implementation rather than redirected it. The LLMs have gotten so good that their general knowledge already gets you to the right architecture much of the time (in my case, API Gateway + Lambda + DynamoDB + Cognito). 

Where the skills added value was in specificity and confidence. Here’s what I got before and after:

The skills would be even more useful than general LLM knowledge for more complex architectures involving event processing or multi-pattern designs, where the pattern-selection flowcharts and service-comparison tables would change the agent’s choices rather than validate them.

What this taught me about coding agents and skills

Giving a coding agent access to tools is not the same as telling it when to use them. Skills are designed to be loaded on demand, which means something has to tell the agent when to demand them. 

“Giving a coding agent access to tools is not the same as telling it when to use them.”

Without a rule, the agent treats skills like reference books on a shelf: available if it decides to look for them, but not part of its default workflow. The rules file is what changes “available on request” into “check this before you start.”

Guardrails

If you’re wondering, “Is it safe to let an agent call AWS APIs?” that’s a great question to ask. The good news is that you can scope down what the agent is allowed to do separately from your own permissions, so even if your IAM role can create and delete resources, you can restrict the agent to read-only. 

Every request the agent makes through the MCP server gets logged, so you can trace which agent action caused it. And the skills have been tested as full end-to-end workflows before shipping, so when your agent follows a skill’s steps, those steps are verified to produce the expected result.

YOUTUBE.COM/THENEWSTACK

Tech moves fast, don't miss an episode. Subscribe to our YouTube channel to stream all our podcasts, interviews, demos, and more.

Created with Sketch.