AWS Labs Adds Transform and RUM MCP Servers, Expanding MCP From Tool Access Into Operational Control Planes

AWS Labs’ latest MCP release is a useful snapshot of where the Model Context Protocol is actually going. The first wave was “let the model call a tool.” This wave is different: give coding assistants structured access to observability, migration workflows, human-in-the-loop tasks, artifacts, connectors, and agent registries. That is no longer plugin hygiene. That is an operational control plane with a JSON-RPC-shaped front door.

The release adds CloudWatch RUM analytics to the Application Signals MCP server and introduces a new aws-transform-mcp-server for managing AWS Transform lifecycle work from AI coding assistants such as Kiro, Claude Code, Cursor, and Cline. GitHub API publication was May 9, 2026, and the repository already has roughly 9,015 stars, 1,513 forks, and 522 open issues. The adoption signal is clear enough: teams want cloud-shaped tools inside their agent workflows. The harder question is whether they are ready to govern those tools like production APIs.

Read-only still reads production reality

The RUM addition comes through PR #3092 and exposes CloudWatch RUM analytics via a single rum MCP tool with 23 actions. AWS says the actions are read-only, consistent with the rest of the Application Signals server. That is the right starting posture, but “read-only” is not the same as “low-risk.” Observability systems often contain the most compact map of how an application behaves in the real world.

The action list makes that obvious. Discovery calls include check_data_access, list_monitors, get_monitor, list_tags, and get_policy. Analytics actions include query, health, errors, performance, sessions, session_detail, page_views, timeseries, locations, http_requests, resources, page_flows, crashes, app_launches, and analyze. The server also integrates with CloudWatch Logs Insights, CloudWatch Metrics, X-Ray, and Application Signals SLO health status.

That is valuable context for an assistant helping debug frontend regressions or correlate user pain with backend traces. It is also sensitive operational data. URLs can expose internal routes. Error traces can include identifiers. Session metadata can reveal usage patterns. Location data may have privacy implications. Internal hostnames, resource names, and SLOs tell a model where the system is fragile. A model does not need write access to create risk if it can read too broadly and then paste the wrong context into a chat, issue, prompt, or generated remediation plan.

The correct governance move is not “avoid observability MCP.” That would leave useful productivity on the floor. The move is scoped identity, least-privilege monitors, redaction, approval for broad exports, and audit logs for every tool invocation. Treat RUM access like giving a human engineer production observability access, because that is functionally what is happening. The interface changed; the responsibility did not.

AWS Transform through MCP is a bigger authority surface

The new AWS Transform MCP server is the more consequential addition. PR #3282 is large: 27 commits, 84 changed files, and 40,238 additions. It adds 25 tools across 14 handlers covering configuration, workspaces, jobs, human-in-the-loop tasks, artifacts, chat, job instructions, connectors and profiles, agent registry, and resource access. It supports dual authentication paths: FES cookie/SSO bearer and TCP SigV4. The PR notes Pyright and Ruff are clean, which is nice; the authority model is the part worth staring at.

AWS Transform is positioned as a service for transformation and migration workflows. Exposing it via MCP means an AI coding assistant can participate directly in modernization lifecycle tasks, not merely answer questions about them. That could be excellent. Migration work is full of repetitive analysis, dependency mapping, job orchestration, artifact review, and status coordination. An assistant that can inspect job state, collect artifacts, and help move human-in-the-loop tasks forward may save real time.

But this is where MCP crosses from convenience into workflow authority. Workspaces, jobs, connectors, HITL task completion, and agent registry operations are not passive documentation lookups. They shape what work happens, which resources are involved, and how humans are pulled into the loop. Even if the highest-risk steps remain gated, the assistant can still steer the process, create momentum, and generate artifacts that humans may approve under time pressure. That is useful automation. It is also why change-management policy needs to sit next to the MCP server config, not in a wiki nobody reads.

Classify servers by authority before installing them

The practical lesson for engineering teams is to classify MCP servers by authority class before registering them in coding assistants. Documentation and search servers are one class. Read-only observability is another. Workflow orchestration, migration systems, cloud resources, deployment tools, and anything that can advance a job are higher classes. Do not install all of them globally because a demo video looked good.

Give each project the smallest set of tools it needs. Bind those tools to identities that can be audited. Separate read scopes from workflow-advancing scopes. Require explicit approval for tools that create jobs, mutate configuration, complete HITL tasks, register agents, or expose artifacts outside the intended workspace. Log prompts and tool calls enough to reconstruct who or what asked for a sensitive operation. If your assistant supports per-workspace or per-repo MCP configuration, use it. A frontend bugfix session does not need a migration control plane by default.

This release is not a warning against AWS Labs MCP servers. It is evidence that MCP is succeeding. The protocol is becoming the connective tissue between coding assistants and the real systems engineers operate. That is exactly when the security model needs to become boring, explicit, and enforceable. The industry keeps trying to make agents feel like helpful coworkers. Fine. Then give them access like coworkers: least privilege, role-specific tools, review gates, and logs that survive the incident review.

AWS’s release shows MCP growing up from helper tools to operational control planes. LGTM — but only if teams stop treating MCP registration like installing a VS Code theme. This is infrastructure now.

Sources: AWS Labs MCP release, PR #3282, PR #3092, AWS Transform