On September 25 AWS announced that AWS End User Messaging and Amazon SES now publish AI agent skills for the AWS MCP Server. The skills cover SMS, RCS, WhatsApp, and SES email, and they work with Claude Code, Codex, Cursor, and Kiro. You can ask your agent to verify a sending identity and send a first production email, or to build a branded RCS agent, and it follows validated steps instead of guessing from training data.
I have been watching this space since the MCP Skills extension went final two weeks ago (skills over MCP is final). AWS shipping skills for its own MCP server is the biggest vendor signal yet that instructions-as-files is becoming a real distribution format. Five details in how they built it are worth copying.
One install, two independent parts
In Claude Code, Codex, and Cursor, the aws-core plugin bundles the AWS MCP Server configuration and a curated set of skills in a single install:
/plugin install aws-core@claude-plugins-official
For Kiro and other agents, you add the server to your MCP configuration file, then add the skill for the channel you want. There is also a wizard if you have the AWS CLI at 2.35.0 or later:
aws configure agent-toolkit
The detail worth copying is in the Agent Toolkit README. It says the toolkit has two independent parts: the AWS MCP Server for runtime API access, and local skills for task-specific guidance. Skills do not require the MCP server, and the MCP server does not serve the installed skills. They complement each other, but neither depends on the other.
That is a deliberate architecture choice, and it is the opposite of what the MCP Skills extension standardizes. AWS distributes the two halves together but keeps the runtime contract empty. The server speaks protocols; the skills are just files your agent reads.
What a skill actually teaches: order of operations
The SES skills are not API wrappers. The MCP server already covers API access, more than 300 services through one authenticated endpoint. The skills encode the sequences that trip people up:
- Use the SES V2 API, not the deprecated V1 client.
- Verify the sending identity before sending anything.
- Create a configuration set before going to production.
- Check sandbox status and use simulator addresses for testing.
- For inbound email, create the traffic policy and rule set before the ingress point, and wait for ACTIVE status before touching DNS.
That list is the clearest definition of what a skill is that I have seen from a major vendor. A tool gives the agent capability. A skill gives the agent the order things must happen in, and the mistakes to avoid. The underlying repo (amazon-ses/skills on GitHub, Apache-2.0) ships two skills this way, aws-ses for sending and aws-mail-manager for inbound, with executable examples in Python, Node.js, and Java.
File copy versus protocol
Installing the skills is still file copy:
npx skills add amazon-ses/skills --skill aws-ses
That command lands SKILL.md files on your disk. Nothing in the MCP conversation tells the agent they exist. Discovery is a convention: the harness scans a skills directory, and the skill activates when your request looks relevant.
The MCP Skills extension (SEP-2640, final September 13) would change the distribution side. A server that implements it answers skills/list and skills/get, so an agent connected to the server discovers its instructions through the same connection it already uses for tools. Every file in the manifest carries a sha256 digest, so a changed reference file shows up as a verification failure instead of silently drifting.
AWS has not wired that up. The skills ride along in the plugin, and the server serves APIs. If you run your own MCP server and publish skills in a repo, you are in exactly the position AWS was in before this announcement, running both halves in two places.
The catch: files on disk go stale
Here is the part nobody puts in the announcement. Skills are files, files age, and an aged skill is worse than no skill, because the agent trusts it.
Two concrete signs from the AWS repo itself. It was created in May, and the getting-started blog post is from June. The skills already have months of life on them, and the SES API surface keeps moving. The repo also carries both an AGENTS.md and a CLAUDE.md at its root, two instruction files that must be kept saying the same thing forever. Anyone who maintains agent configs knows how that story ends.
This is the same problem Claude Code started attacking this week with /doctor prompt-audit, which flags instruction files written for older models (what the config linter changes). Vendor skills need the same treatment. When you install a skill, you inherit its staleness schedule, and unlike a server you can hotfix, a file you never look at again just sits there being wrong.
What to check before installing someone's skill
I would run the same checks on any third-party skill, AWS included:
- License and provenance. Apache-2.0 in a public repo you can read is the baseline.
- What lands on disk. Read the SKILL.md before your agent does. It is instructions your agent will treat as authoritative.
- Load behavior. Skills load on demand, so figure out what requests trigger it. You are trusting the packaging, not just the content.
- Pin something. A commit SHA or a release tag, so you know what changed when behavior changes. Per-file digests, the mechanism SEP-2640 mandates, are the protocol-grade version of this habit.
The token cost question deserves the same skepticism. Nine MCP servers cost me 41k tokens before the first prompt in my earlier measurement. Skills are cheaper by design because they load only when relevant, but "on demand" is doing real work in that sentence. Measure your own baseline before and after.
Why this matters for your own configs
The pattern AWS validated is the one I sell kits for: pinned, versioned instruction files that travel with the repo and teach the agent the order of operations. If you want the full version, AgentConfig Studio ships twelve validator-tested kits that work this way, or you can start from the free Next.js sample and write your own.
The short version of the lesson: capability lives in servers, knowledge lives in files, and the two should be distributable together without depending on each other. AWS just did that at the scale of the largest cloud. Copy the separation, add the version pinning they left out, and audit the files on the same schedule you audit any other dependency.
The announcement is on the AWS What's New feed: AWS End User Messaging and Amazon SES now offer AI agent skills for the AWS MCP Server.
Top comments (0)