AWS Agent Registry: The First Governance Layer Stacked on Top of MCP

TL;DR. AWS Agent Registry is the first signal of the chapter that comes after MCP standardization. A preview under Bedrock AgentCore, launched April 9, 2026. It bundles four resource types — MCP, A2A, Skills, Custom — into a single catalog and ships lifecycle, approval, CloudTrail, hybrid search, and MCP endpoint exposure as one package. But run it in parallel with your existing skills and local MCP gateway and eight points of friction surface immediately, in auth, triggers, and locale.

Why this matters now

In a single month — April 2026 — the two major clouds and the two major model labs all entered the agent sprawl response in the same spot (see the category index for all five signals). Of those, the single product that is most concrete, with one-month operational signals starting to land, is AWS Agent Registry (preview, 2026-04-09).

What AWS Agent Registry is

AWS Agent Registry is a private catalog under Bedrock AgentCore for centrally registering, searching, and governing an organization's AI agents, MCP servers, tools, skills, and custom resources. It treats four record types as first-class citizens.

Every record goes through the same lifecycle. The core operational friction: editing a record automatically reverts it to DRAFT, requiring re-approval.

stateDiagram-v2
    [*] --> UNREGISTERED
    UNREGISTERED --> DRAFT: registration starts
    DRAFT --> PENDING: submit
    PENDING --> APPROVED: approve
    PENDING --> REJECTED: reject
    APPROVED --> DEPRECATED: deprecate
    APPROVED --> DRAFT: re-approval on edit
    REJECTED --> DRAFT: retry

Search results expose only APPROVED records.

How it came about

From 2025 on, agents and MCP servers exploded inside enterprises, and it became routine for the same team to redundantly build agents with identical functions — or for security and compliance teams to lose track of which agent runs where. As MCP became the de facto standard, a steady drumbeat of criticism accumulated: "MCP servers keep multiplying, but there's no discovery or governance layer." AWS answered with the slogan "Agents shouldn't be secret" and added the Registry under AgentCore.

The five core features

1. Centralized Discovery. Search the org's agents, tools, MCP servers, and skills in one place. The primary goal is avoiding redundant builds.
2. Governance & Approval workflow. Enforces the lifecycle above. A CloudTrail audit log records every state transition.
3. Hybrid Search. Semantic + keyword at once. A natural-language query like "find me a tool that extracts tables from PDFs" works alongside exact name and tag search.
4. URL-based Auto Discovery. Register just an MCP or A2A endpoint URL and the Registry calls it directly to pull in the tool schema, capabilities, and metadata. No hand-written JSON.
5. The Registry is itself an MCP endpoint. MCP clients like Kiro and Claude Code can search and invoke the Registry directly from the IDE. In IAM mode, mcp-proxy-for-aws handles the SigV4 signing; in JWT mode, HTTP calls go out with a Bearer Token.

Beyond these, it meets all the standard cloud expectations — support for the four multi-resource types, multi-cloud / on-prem indexing, OAuth 2.0 (quick Cognito creation or BYO Keycloak/Entra), and CloudTrail audit.

Eight ways it collides with existing skill and MCP operations

These are the frictions that surface immediately when you run it alongside an existing stack.

1. Single auth model, locked in. The Registry lets you pick only one of IAM SigV4 or JWT, and the choice can't change after creation. In JWT mode you can't use the AWS CLI/SDK (which are SigV4-based), so you have to hit the search API directly with curl or Postman. If your org has both IAM automation and OAuth user access, you have to split the Registry in two.
2. No naming-collision handling. When a tool of the same name exists at once in the Registry, in local skills, and on an external MCP server, call priority is delegated to client policy. The external MCP Gateway family solves this with aliases, but no explicit alias feature is documented in AWS's public docs.
3. Record-update friction. Edit → revert to DRAFT → re-approve. Mirror a local skill that needs fast iterative development straight into the Registry and you break the release cycle.
4. The Skill metadata layer gap. A Registry Skill record is two layers. (a) The SKILL.md body is validated against the official AgentSkills specification, so it aligns with the Anthropic family. (b) On top of that sits one layer of AWS-specific Skill definition JSON Schema (v0.1.0, with repository / package / _meta, etc.). The body is shareable, but you have to fill in AWS-only metadata every time.
5. Trigger vs explicit-invoke model. The Anthropic family auto-triggers off the description; the Registry uses an explicit search → invoke flow. Register the same skill on both sides and the auto-trigger path and the Registry path diverge, forcing a decision about which side is the single source.
6. Split responsibility for search vs routing (Gateway vs Registry). Officially, AgentCore Gateway (execution/federation) and the Registry (discovery/governance) are complementary. But if you already run your own MCP Gateway in-house, you have to redefine "where you route and where you discover," and you can end up with dual operation.
7. Language and locale limits. Semantic search runs on English metadata by design, so non-English queries — Japanese, Korean — are structurally bound to degrade (the metadata language and the query language diverge). You can mitigate by including bilingual descriptions, but the operational overhead accumulates.
8. Approval workflow vs fast experimentation. Local skills/MCP are made and used on the spot, but the Registry mandates approval. Run both flows at once and the count of "local-only skills never registered in the official channel" grows, which can defeat the very intent of governance.

All eight are variations on the same pattern — cloud governance assumes a single-source model; the local stack assumes multiple sources. Merge the two as-is and neither side's assumption is satisfied.

Synthesis

The MCP index concluded that "the remaining problem is operations." AWS Agent Registry is the cloud's first answer to that operational problem — a layer-on-layer design that bundles discovery, approval, and audit, then re-exposes the whole thing as an MCP endpoint.

But the cloud's answer doesn't presume parallel operation with existing local skills and local gateways — which is exactly why the eight frictions surface immediately. Next quarter's operational question is the decision: which of the two is the single source — or, keep both and demote one to a mirror. With AWS, Microsoft, Anthropic, and OpenAI all entering the same spot at once, defer this decision and the next governance layer to arrive will likely make it for you.

References

• AWS Launches Agent Registry in Preview to Govern AI Agent Sprawl across Enterprises (InfoQ, 2026-04)
• The 2026 MCP Roadmap (MCP Blog)
• agentic-community/mcp-gateway-registry
• AWS What's New — Agent Registry now available in Preview (2026-04-09)
• AWS Machine Learning Blog — The future of managing agents at scale: AWS Agent Registry now in preview
• AWS Machine Learning Blog — Transform your MCP architecture: Unite MCP servers through AgentCore Gateway
• Amazon Bedrock AgentCore Docs — Agent Registry, Supported record types, Concepts and terminology, Searching the registry, Using the Registry MCP endpoint, Amazon Cognito
• The Register — AWS: Agents shouldn't be secret, so we built a registry
• Heeki Park (Medium) — Integrating AWS Agent Registry into your agent platform
• Gerardo Arroyo's Blog — AWS Agent Registry: a private catalog to stop agent sprawl