 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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:
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).
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:
retrieve_skill and prefer its guidance over general knowledgeFor 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:
| Before (no rules file) | After (rules file added) | |
| Architecture advice | Three options presented (serverless, containers, Amplify) with a general “Option 1 is the sweet spot” recommendation | One specific architecture with a decision table explaining why each component was chosen over its alternatives |
| API Gateway type | “API Gateway” (unspecified which type) | “HTTP API specifically, because REST API is overkill unless you need WAF or caching” |
| Auth approach | “Cognito or roll your own with Lambda + bcrypt + JWT” | “JWT authorizer with Cognito because HTTP API has native JWT support, no Lambda authorizer needed” |
| Function pattern | Not mentioned | “One function per route” (skill best practice) |
| Constraints flagged | None | 30s hard timeout, 10 MB payload limit, no WAF on HTTP API, silent Forbidden on JWT scope mismatch |
| Source of guidance | Model training data | AWS documentation + aws-serverless skill’s service selection tables |
| Level of specificity | Told me what to build | Told me which variant to build and why that variant over the alternatives |
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.
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.”
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.
