The Day AWS Took MCP to GA — Whose Hands Has the Standard Left?

What does it mean for AWS to ship a protocol invented by Anthropic to GA? The moment a standard slips out of its creator’s hands, does it grow stronger, or does it hollow out? And whose IAM policy breaks first in the seam?

Opening — What 102 LGTMs Are Telling Us

On May 6, 2026, AWS announced on its official blog that its Model Context Protocol (MCP) server had moved to general availability (GA). Three days later, on May 9, a Japanese AWS community engineer who goes by Syoitu posted a summary on Qiita titled “AWS MCPサーバー超進化してGAしたらしい” (Looks like the AWS MCP server super-evolved and went GA). Within 24 hours of publication, the post had collected 102 LGTMs. On Japanese Qiita, hitting 100 LGTMs is something that happens only a handful of times a year. Across all categories in the same week, fewer than five posts earned more.

What that number is telling us is not popularity in the abstract. It is the fact that the Japanese engineering community had been waiting for this announcement. AWS had already, since mid-2025, been publishing more than 30 individual MCP servers in preview form through the awslabs/mcp repository. DynamoDB, EKS, Lambda, Bedrock Knowledge Bases, CloudFormation, the Aurora family, Neptune, Redshift, Q Business — each was a separate package, a separate install, a separate auth flow. The new GA release aws-mcp that Syoitu’s post documents collapses those 30-plus servers behind a single managed endpoint (https://aws-mcp.us-east-1.api.aws/mcp) and consolidates authentication onto IAM SigV4. In other words, GA does not mean “you may now use it.” It is closer to a notice that says “there is no longer any other way you should be using it.”

What makes this announcement different from GitHub’s six-day outage a week earlier is that this is not a broken old order but a new order hardening into place. When Anthropic launched MCP on November 25, 2024, the protocol looked like a specification that mattered only inside one company’s one client (Claude Desktop). A year and a half later, OpenAI has integrated an MCP host into ChatGPT, Microsoft treats MCP as a first-class citizen in Visual Studio Code and Copilot Studio, and Google has stacked the Gemini tool-call backend on top of an MCP-compatible layer. Then on May 6, the last missing piece of this current — AWS — joined as a managed endpoint. Within the next year, a “cloud console that does not support MCP” will almost certainly cease to exist as a meaningful category.

The question therefore reduces naturally to one. Once Anthropic no longer controls this standard, what does the standard become? And whose IAM policy breaks first in the meantime?

Section 1 — What the AWS MCP Server Actually Does

Before anything else, let us nail down what the GA AWS MCP server actually exposes. Abstract marketing copy obscures the substance.

The new managed server exposes seven core tools behind a single endpoint (https://aws-mcp.us-east-1.api.aws/mcp). These tools fall into two families. One is the resource-manipulation family. The other is the knowledge family.

The centerpiece of the resource-manipulation family is call_aws. This single tool exposes roughly 15,000 AWS API operations as callable functions. An agent invokes ec2:DescribeInstances, s3:PutObject, iam:CreateRole, and bedrock:InvokeModel all as argument shapes to the same tool. The second tool, run_script, executes Python/boto3 scripts inside a network-isolated sandbox and inherits the caller’s IAM permissions intact. Multi-step automations that do not collapse to a single API call — pagination, conditional branching, result filtering — can be completed by the agent in one shot. The third tool, suggest_aws_commands, converts natural language to AWS CLI commands.

The knowledge family consists of search_documentation (cross-reference of official docs), retrieve_skill (retrieval of best-practice SOPs maintained directly by AWS service teams), and list_regions and get_regional_availability for region metadata. The interesting one is retrieve_skill. The “skills” retrieved here are recommended procedures authored and kept current by each AWS service team itself, and they nudge the model to reference these SOPs in preference to the year-old information sitting inside its training data. Accuracy of model responses gets contracted out to the RAG side rather than secured at training time.

The authentication flow is where the decisive difference lives. The previous awslabs/mcp preview servers each ran as a local process and read credentials from ~/.aws/credentials or environment variables. The new GA version is a managed remote endpoint, yet it never issues a token directly. Instead, a local proxy called mcp-proxy-for-aws sits between the client (Claude Code, Cursor, VS Code) and the remote endpoint, applying an IAM SigV4 signature to every request itself. No OAuth, no separate API key, no token-rotation schedule. The user simply runs aws sso login --profile MyAdminProfile once to refresh the SSO session.

The registration command shown in Syoitu’s post is this:

aws sso login --profile MyAdminProfile

claude mcp add-json aws-mcp --scope user '{
  "command": "uvx",
  "args": [
    "mcp-proxy-for-aws@latest",
    "https://aws-mcp.us-east-1.api.aws/mcp",
    "--metadata", "AWS_REGION=ap-northeast-1"
  ],
  "env": {
    "AWS_PROFILE": "MyAdminProfile",
    "AWS_REGION": "ap-northeast-1"
  }
}'

What happens on the client side after this short registration line is the following. Every MCP tool call is delivered via stdio to mcp-proxy-for-aws, which forwards the request as a SigV4-signed HTTPS request to the managed endpoint. The response returns to the client unchanged. Tokens never sit in client memory for so much as a second; credentials remain inside the ~/.aws/sso/cache that the SDK was already managing. This is the substance of the “zero credential exposure” AWS boasts about.

So much for the facts. But a short comment from a Japanese engineer on the same post cuts deeper. “Aren’t they basically just wrapping the AWS CLI in natural language (結局AWS CLIを自然言語でラップしただけでは?).” Half right. call_aws is, at heart, a thin wrapper over boto3 calls. But half wrong too. The real change is not the number of tools but who is calling them.

Section 2 — Eighteen Months of the MCP Standard: From One Company’s Spec to an Internet Standard

Anthropic announced MCP on November 25, 2024. Reread the launch materials from that day and MCP positioned itself from the start as “a USB-C port for AI applications.” The standard’s author signaled its intent not to confine it to its own products. Whether that intent actually translates into reality, however, is decided not by the adoption curve of the standard but by the transition curve of its governance.

Start with adoption. For the first six months after launch, MCP was perceived as a specification meant only for Claude Desktop. The signal of change arrived in May 2025, when OpenAI announced that ChatGPT’s tool-call interface would be redesigned to be MCP-compatible. In September of the same year, Microsoft integrated an MCP client as a first-class citizen in Visual Studio Code 1.93. In December 2025, Google announced that the function-call backend for the Gemini API would sit atop an MCP-compatible layer. At that point, two of the three major cloud providers (AWS, Azure, GCP) had declared client-side adoption, while on the server side awslabs/mcp had already released some 30 preview servers. And on May 6, 2026, AWS joined as a managed GA.

Looked at purely through the adoption curve, the pattern is precisely analogous to OpenAPI’s becoming the de facto standard for RESTful APIs between 2016 and 2018. A specification announced by one company (Swagger Inc., later SmartBear) was transferred to the OpenAPI Initiative under the Linux Foundation, and immediately after the handover, AWS, Microsoft, Google, and IBM adopted OpenAPI all at once as the first-class input format for their API gateways, completing OpenAPI’s transition from “a spec pushed by one company” to “a format the industry assumes by default.” MCP’s May 6 corresponds to the OpenAPI 3.0 GA point on that transition curve.

But the governance curve looks different. The MCP specification is still managed inside the modelcontextprotocol/specification repository, and the maintainer roster of that repository is dominated by Anthropic employees. Specification changes are proposed as RFC-style PRs, but merge authority sits with Anthropic. AWS builds clients and servers but does not directly influence specification changes. Tucked into the AWS GA announcement, however, is one line: “AWS will actively participate in the future evolution of MCP.” That single line signals that the balance of governance pressure over future MCP changes is beginning to shift.

What is interesting here is that the MCP standard has not yet been entrusted to a formal standards body like the IETF or ISO. This is unlike OpenAPI’s transfer to the Linux Foundation. Anthropic calls MCP an “open protocol,” but that openness merely means the specification document is public; it does not guarantee decentralized governance. If AWS, Microsoft, and Google fail to land the extensions they need inside the specification, they will eventually build their own compatibility layers and trigger a de facto fork. In the early 2010s, certain IDPs built proprietary extensions around the OAuth 2.0 specification and broke interoperability with SAML — a clear precedent.

A Hacker News comment hit exactly this point. “AWS shipping MCP GA means ‘AWS MCP Extensions’ lands in 6 months. If they don’t get merged upstream, MCP de facto forks.” There is logic to this pessimism. The managed endpoint is itself a natural conduit for extensions outside the specification. If AWS adds custom metadata fields tied to its IAM to the managed endpoint and those fields are not present in the standard specification, clients are nonetheless already depending on those fields to function.

There are two ways a standard’s author loses control. One is to actively cede governance (the OpenAPI path). The other is for de facto users to harden their own extensions in the territory outside the specification (the SAML path). MCP is now at the fork between these two paths. AWS’s GA could become a force pushing that fork toward OpenAPI, or it could become a force pulling it toward SAML. Which governance change Anthropic announces over the next six months is decisive.

One more fact is easily overlooked. The biggest reason MCP’s adoption curve accelerated is not the technical superiority of the specification but the structural pressure of the coding-agent ecosystem. As we saw in GitHub’s six-day fissure the week prior, the explosive growth of coding agents created a 30x load that shook GitHub infrastructure. Behind that explosion is an explosion in the number of tools agents must call. AWS, GitHub, Slack, Linear, Notion, Datadog — the number of external systems a single agent must handle rapidly reached two digits, and writing a separate SDK adapter for each system is no longer sustainable. MCP was the simplest answer to this adaptive pressure, which is why adoption raced. MCP’s victory was built not on the specification’s elegance but on the market’s desperate need for uniformity across the agent ecosystem.

Section 3 — The Next Bill From Security and Governance

The longest section of the GA announcement is devoted to authentication and authorization. AWS introduced two new IAM context keys: aws:ViaAWSMCPService and aws:CalledViaAWSMCP. The former indicates that the call passed through the managed MCP endpoint; the latter indicates that the call originated from an AWS MCP tool. Drop these two keys into the Condition of an IAM policy and an operator can write a policy like “deny RDS backup deletion when reached via the MCP path” in a handful of lines. In theory, at least.

The problem is that the IAM model itself was not designed for coding-agent call patterns. Traditional IAM assumes three kinds of principal — person, service, role — and assumes each acts with a consistent intent within a session. A coding agent maps cleanly to none of these three. The agent acts under delegation from a person, but the scope of that delegation is given in natural language. The agent is a service, but its behavior pattern is not a defined RPC but the model’s improvisational judgment. The agent can take on a role, but it might move freely between several roles within a single session.

This mismatch shows up as concrete failure modes. The simplest scenario is permission escalation. Suppose a user asks the agent: “Clean up the EC2 instances in the staging environment.” The managed MCP server performs the SigV4 signing with the user’s SSO session token. If the user’s IAM permissions include ec2:*, the agent can terminate not just staging but production instances too. A human operator would notice immediately on the console that they clicked into the wrong environment, but an agent acts on its own interpretation of the natural language request. The mitigation AWS documents recommends is “use a read-focused custom IAM role” rather than admin credentials. But that recommendation runs into a contradiction quickly. For the agent to be useful, it ultimately needs write permissions.

The second scenario is the flow of secrets. The managed endpoint never receives user credentials directly, but the responses to the AWS APIs the agent calls can themselves contain secrets. The response to secretsmanager:GetSecretValue, for instance, contains the plaintext secret. That this response returns to the client by way of the managed MCP endpoint means the secret transits AWS managed infrastructure, however briefly. AWS states explicitly that “responses are not stored,” but “not stored” is not the same as “not logged anywhere.” CloudTrail records the call, and metadata persists in the managed service’s operational logs. Whether that metadata becomes an entry point for some future breach is unmapped territory.

The third scenario is the absence of an audit log inside MCP itself. The current MCP specification has no standardized audit log format that records who received the result of a tool call and for what purpose. AWS records the call side via CloudTrail, but the causal chain — how the model interpreted that response, what subsequent calls it triggered — lives only inside the model-side client. Claude Code’s session logs, Cursor’s session cache, VS Code’s extension logs — each client has a different format, a different retention period, a different access control. When an incident happens, the operations team’s job of reconstructing the causal chain by joining the call-side CloudTrail with the response-side client logs is, in practice, almost impossible.

What AWS promised at GA — IAM SigV4 integration, the new condition keys, CloudTrail recording — addresses only the first of these three scenarios, and only partially. The second and third remain open. This is one more variable that will decide whether MCP follows the OpenAPI path or the SAML path. If the three security axes — authentication, authorization, audit — are not standardized at the specification level, each cloud vendor has no choice but to fill the gap with its own extensions, and the moment they do, a de facto fork begins.

One final point. Once the pattern of coding agents calling cloud APIs directly hardens, the work of operations teams shifts from “auditing human behavior” to “auditing agent interpretation.” This is not a mere change in tooling but a change in the job. SREs are already shifting from “people who define SLOs” to “people who approve the SLO changes the agent proposed,” and security engineers are likely to shift from “people who write policies” to “people who, when an agent attempts a policy violation, decide whether it was an intended violation or a misinterpretation.” AWS’s MCP GA is the accelerator on this job shift.

Conclusion — What Remains Where the Standard Has Departed

Return to the opening question. What does it mean for AWS to ship a protocol that Anthropic invented to GA? The moment a standard slips out of its creator’s hands, does it grow stronger or hollow out?

The answer is both. AWS’s GA has effectively cemented MCP as the cloud standard. With two of the three majors now offering managed channels, the remaining one (Google) following the same path is a matter of time. In this sense, MCP has completed its transition from one company’s specification to the industry’s default. At the same time, that transition occurred without an accompanying decentralization of governance. AWS can naturally add specification-external extensions through its managed endpoint, and unless those extensions backflow into the standard, a de facto fork begins the moment the first user of that extension updates their client.

What 102 LGTMs tell us is that the Japanese engineering community has already grasped both sides of this intuitively. They had the experience of installing all 30 preview servers from awslabs/mcp and managing each auth flow separately, and they welcomed the GA precisely because a single managed endpoint solves that pain. At the same time, another part of the same community left the skeptical comment, “Aren’t they just wrapping the AWS CLI in natural language?” These two reactions are not contradictions but two faces of the same fact. The managed endpoint reduces operational burden, but reducing it means moving part of that burden under AWS’s control.

Three things to watch over the next six months. First, what form Anthropic chooses for decentralizing MCP governance. If an industry consortium forms under the Linux Foundation, the OpenAPI path hardens; if those steps lag, the SAML path draws closer. Second, what specification-external extensions AWS adds to its managed endpoint. If those extensions backflow into a standard RFC, no fork happens; otherwise, the first crack in client compatibility begins. Third, the form in which a security incident first detonates. Permission escalation, secret leakage, audit-chain rupture — the moment any one of these lands on a headline, the MCP security model will come under pressure for a specification-level redesign.

Two things remain where a standard has departed. One is the infrastructure built on top of it. The other is the new jobs that infrastructure produces. The AWS operator before May 6 audited “who called the AWS API.” The AWS operator after May 6 begins auditing “from what natural-language request the agent that called the AWS API derived that call.” This change in the object of audit reshapes our work at a level far deeper than the question of who controls the standard.

So the final question becomes this. The IAM policy you operate — was it designed for people, or is it ready to be redesigned for agents?

Sources: