awslabs/agent-plugins: AWS skills packaged for Claude Code, Codex and Cursor

What Agent Plugins for AWS actually packages

The problem this repository targets is prompt repetition. Teams using coding agents on AWS tend to paste the same deployment guidance, service limits and architecture rules into every session, which consumes context and produces inconsistent answers between developers. Agent Plugins for AWS turns that guidance into versioned artifacts the agent invokes when it judges them relevant. The README describes a plugin as a container that can hold four kinds of artifacts: agent skills, which it calls structured workflows and best-practice playbooks; MCP servers, which connect the assistant to external services and data at runtime; hooks, which the README describes as automation and guardrails that run on developer actions; and references, documentation and configuration defaults the skill can consult without inflating the prompt. The audience is developers who already use Claude Code, Codex or Cursor and want AWS expertise available inside them. The repository ships nine plugins, including aws-serverless, deploy-on-aws, migration-to-aws, aws-transform and sagemaker-ai.

How a plugin is structured and invoked

The packaging model is the interesting part. A single plugin directory can mix skills, MCP servers, hooks and references, so the agent gets both procedural guidance and live data in one installable unit. Skills carry the step-by-step process; MCP servers supply runtime access to things like live documentation and pricing data; references sit alongside so the skill can look things up rather than carrying everything in context. The README frames the benefit as determinism and reduced context overhead, and says the packaging model lets new artifact types be added later without changing what developers do. The repository layout supports that claim: there are .agents/, .claude-plugin/, plugins/, schemas/ and tools/ at the top level, plus a mise.toml, a dprint.json and pre-commit configuration. The schemas/ directory implies plugin manifests are validated against a schema, though the README does not document the schema fields. That is a gap worth noting: the README explains the concept of each artifact type but does not show the manifest format a contributor would write.

Installing a plugin in Claude Code

The README documents installation for Claude Code through a plugin marketplace. First you register this repository as a marketplace source, then install an individual plugin by name with the @agent-plugins-for-aws suffix. The README gives this example for the marketplace step.

/plugin marketplace add awslabs/agent-plugins

After that command succeeds, the marketplace is registered and you can install a plugin from it. The README lists several install commands, including these.

/plugin install amazon-location-service@agent-plugins-for-aws

/plugin install aws-serverless@agent-plugins-for-aws

The pattern is consistent: the plugin name, an at sign, then the marketplace name. The README also shows aws-amplify and codebase-documentor variants in the same form. The README does not state what output the install command produces or where the plugin files land on disk, so treat the first install as something to inspect rather than assume. It also does not document an uninstall or rollback procedure, which matters if a plugin's hooks begin enforcing standards you did not expect.

Where the coverage is uneven

The plugin table is the clearest signal of maturity. Eight of the nine plugins are marked Available. databases-on-aws is marked Some Services Available, with Aurora DSQL named in parentheses, which means the database guidance does not yet span the full AWS database portfolio the description claims. If you are working with RDS or DynamoDB, check the plugin directory before assuming coverage. There is a second limitation that is structural rather than a bug: the README states the Agent Toolkit for AWS is the successor to the MCP servers, plugins and skills on AWS Labs, and recommends it for teams building production software or building agents for their own customers. It also says the most useful projects here will move into Agent Toolkit over time. That makes this repository a reasonable place to experiment and a questionable place to standardize. The README does not give a migration path or a timeline for when individual plugins move, so an adoption decision here carries an unresolved question about where the plugin will live in a year.

Agent plugins compared with skills alone

The obvious alternative is installing skills without the plugin wrapper. Skills alone give the agent a workflow, but they cannot carry an MCP server connection or a hook that runs on a developer action. The README's own framing is that a plugin is a container for different expertise artifact types. So if you only need deployment checklists, a skill is sufficient and lighter. If you need the agent to pull live pricing data during a cost estimate, or to enforce a validation step automatically, you need the plugin because that is where MCP servers and hooks live. The trade-off runs the other way too: a plugin with hooks executes code on your actions, and the README's own best-practices list tells you to follow least privilege when configuring AWS credentials and to review generated code before deployment. A skill cannot do anything on its own; a plugin can, which is precisely why the credential scope matters.

Licence, maintenance and what to verify first

The repository is Apache-2.0, with a NOTICE file at the top level, which is standard for AWS-published open source. Apache-2.0 permits commercial use and modification, and includes a patent grant; it also requires that you preserve the licence and NOTICE when redistributing. That is a summary of the licence text, not legal advice, and if you are redistributing a modified plugin you should read the LICENSE and NOTICE files directly. The last push to the repository was on 2026-09-14, one day before this writing, so the repository is receiving changes. The only release listed is 1.0.0 from 2026-02-18. The README carries an explicit warning that generative AI can make mistakes and points readers to the AWS Responsible AI Policy, which is worth taking at face value given that these plugins generate infrastructure code. Its best-practices section also asks you to keep plugins updated, run security scanning tools on generated infrastructure code, and treat plugins as accelerators rather than replacements for developer judgment.

Editorial conclusion

Adopt it if you already drive Claude Code, Codex or Cursor against AWS and want deployment, migration or database guidance invoked from the agent instead of pasted into prompts. Do not adopt it if you are starting production work now: the README states the Agent Toolkit for AWS is the successor and recommends it for production software, so new projects should evaluate that path first. Before installing anything, verify which plugins are marked Available versus Some Services Available, and read the plugin's own directory under plugins/ to see whether it ships skills, MCP servers, hooks or references, because the top-level README only lists names and one-line descriptions.

Frequently asked questions

Official sources

1. awslabs/agent-plugins on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases