RFC: aws-transform plugin

[youtuyy]

Is this related to an existing feature request or issue?

Related MCP server contribution: awslabs/mcp#2811 (RFC: AWS Transform MCP Server), landed via awslabs/mcp#3282 as src/aws-transform-mcp-server/. This RFC proposes the companion plugin that brings AWS Transform's domain expertise to coding agents and composes with that MCP.

Summary

Add an aws-transform plugin for migration architects, modernization leads, and partner consultants — users who arrive with a workload to migrate rather than an AWS API to call. AWS Transform is AWS's AI-powered code and workload modernization service, and the plugin wraps it into a focused, persona-scoped tool surface (assess, plan, transform, validate) backed by the awslabs.aws-transform-mcp-server (published to PyPI, maintained by the AWS Transform service team).

AWS Transform launched a Kiro Power on 2026-04-30 bundling its MCP and skills. This RFC and the accompanying PR deliver the equivalent experience to users of Claude Code, Cursor, Codex, and other agents that install from awslabs/agent-plugins, targeting a 2026-05-14 launch alongside the broader AWS Transform anniversary release.

Use case

The plugin serves three concrete persona use cases:

• Migration architects planning and executing workload moves to AWS:
  • .NET Framework → .NET 8/10 on Linux (project file migration, API replacements, runtime compatibility)
  • Mainframe COBOL → Java (program decomposition, dependency analysis, assessment)
  • VMware → EC2 (discovery via connector, landing zone setup, network migration, server rehost via MGN, containerization to ECS/EKS)
  • SQL Server / Oracle / MySQL → Amazon Aurora (schema conversion, data migration planning)
• Modernization leads driving in-place code upgrades:
  • Java 8/11/17 → 17/21
  • Python 2 → 3
  • Node.js version bumps
  • AWS SDK v2 → v3 migrations
• Partner consultants running user-defined transformations across customer fleets — single-repo local execution for fast iteration, or many-repo remote execution for scale.

The plugin can grow within the migration-and-modernization persona over time by absorbing related tooling (for example, DMS, MGN, Migration Hub, Application Discovery Service) under one installable rather than splintering into per-service plugins.

Proposal

Structure

plugins/aws-transform/
├── .claude-plugin/
│   └── plugin.json
├── .codex-plugin/
│   └── plugin.json
├── .mcp.json
├── README.md
├── skills/
│   └── aws-transform/
│       ├── SKILL.md
│       └── references/
│           ├── auth.md
│           ├── tools.md
│           ├── workflow.md
│           ├── custom.md
│           ├── custom-cli-reference.md
│           ├── custom-multi-transformation.md
│           ├── custom-remote-execution.md
│           ├── custom-repo-analysis.md
│           ├── custom-results-synthesis.md
│           ├── custom-single-transformation.md
│           ├── custom-troubleshooting.md
│           ├── dotnet.md
│           ├── mainframe.md
│           ├── sql.md
│           ├── vmware.md
│           ├── vmware-containerization.md
│           ├── vmware-landing-zone.md
│           ├── vmware-network.md
│           └── vmware-server.md
└── test-prompts.json

The SKILL.md dispatches only the relevant reference file(s) per request — dotnet.md for a .NET migration, the vmware*.md subtree for a VMware migration, the custom*.md subtree for user-defined transformations, etc. — to keep context compact.

MCP dependency

.mcp.json references the published PyPI package:

{
  "mcpServers": {
    "aws-transform-mcp": {
      "command": "uvx",
      "args": ["awslabs.aws-transform-mcp-server@latest"]
    }
  }
}

The MCP server handles the full authentication surface AWS Transform customers use today — IAM Identity Center (IdC), external Identity Providers (IdP) via OAuth 2.0 bearer tokens, and AWS Credentials (SigV4) — and manages token issuance and refresh at runtime.

Marketplace registration

Entries added to both .claude-plugin/marketplace.json (category migration) and .agents/plugins/marketplace.json (category Migration), plus an entry in the README.md plugins table.

User experience

Before: a user with, e.g., a .NET 4.x codebase has no agent-native path to AWS Transform. They install the MCP separately and need to know which tools to call in which order.

After: the plugin provides workflow guidance that routes through assess → plan → transform → validate, with just-in-time authentication, surfaced through natural prompts like "migrate this .NET app to AWS", "upgrade this Java codebase", or "move these VMware VMs to EC2".

Out of scope

• Bundling or packaging the MCP server itself. The MCP lives in awslabs/mcp and is installed via uvx.
• Authoring new transformation definitions as the default workflow. Supported via custom-td-creation guidance but remains a specialist flow.
• Generic code modernization outside AWS Transform's scope.
• Infrastructure provisioning or CI/CD tooling outside the transformation domain.

Potential challenges

• Large reference surface. ~19 reference files across multiple workloads; mitigated by workload-scoped dispatch in SKILL.md.
• Authentication diversity. AWS Transform supports IdC/IdP/OAuth bearer tokens in addition to SigV4; the plugin delegates auth handling to the MCP, which ships with all three paths.
• Remote-mode infrastructure. Custom remote-mode transformations provision a CDK stack; documented in custom-remote-execution.md with explicit cost and teardown guidance.
• Parity with the service. AWS Transform adds new workload agents over time; the plugin will need coordinated updates, driven from the same internal source of truth as the Kiro Power.

Dependencies and Integrations

• Depends on awslabs.aws-transform-mcp-server (PyPI, maintained in awslabs/mcp).
• Consumes the AWS Transform CLI (atx) for local-mode custom transformations.
• For remote custom transformations, provisions a CDK stack documented in the custom-remote-execution reference.
• Authenticates via the MCP's IdC, IdP (OAuth bearer), and SigV4 paths.

Alternative solutions

• Point users to the MCP only. Works but loses workflow, decision-point, and troubleshooting guidance — the MCP describes tools, not usage.
• Keep the plugin in a separate repo. Fragments the AWS agent-plugin catalog; awslabs/agent-plugins is the canonical home.

---

Metadata

• RFC PR: feat(aws-transform): add AWS Transform plugin #164
• Approved by: ''
• Reviewed by: ''

[youtuyy]

PR opened: #164