An agent registry catalogs which agents, tools, and MCP servers an organization has approved to exist and run. An MCP registry is narrower: it catalogs which MCP servers exist and how a client connects to them. AWS Agent Registry, the official MCP Registry, Smithery, and Docker MCP Catalog sit at different points in that stack, and AWS’s own product now treats MCP servers as one record type it catalogs alongside agents and skills. That collapses a category question most vendors treat as abstract into something you can point to. Registration and reachability are also not the same claim, and the distinction between them is where most of the confusion behind this exact query lives.
- An agent registry answers “does this exist and is it approved,” across agents, tools, skills, and servers.
- An MCP registry answers a narrower question: “which MCP servers can a client find, and how does it connect.”
- AWS Agent Registry (general availability August 31, 2026) validates registered MCP servers against the MCP schema, but its own MCP endpoint only ever queries the catalog, never the registered servers’ actual tools.
- Neither layer checks whether what a reachable, approved server returns is the business’s current, accurate answer.
| Dimension | Agent registry | MCP registry |
|---|---|---|
| What it is | Approved agents, tools, skills, and often MCP servers | MCP servers, and how a client connects to them |
| What it catalogs | Identity, ownership, version, approval status | Server metadata, capabilities, package host pointers |
| Who owns approval | Governance or platform team, via approval workflow | Self-reported (official registry) or curator-vetted (marketplaces) |
| Key question it answers | May this agent or tool run here? | Does this server exist, and how to reach it? |
| Protocol dependency | None required; can incorporate MCP as one record type | Built around the MCP specification |
| Governance mechanism | Draft, pending approval, approved, deprecated | None (self-reported) to container vetting (curated) |
| Best-known example | AWS Agent Registry | Official MCP Registry, Smithery, Docker MCP Catalog |
Agent registry vs. MCP registry: what’s the difference?
Permalink to “Agent registry vs. MCP registry: what’s the difference?”An agent registry is the broader catalog: a governed record of which agents, tools, skills, and servers an organization has approved, tracking who owns each one and what version is live, the same territory what is an AI agent registry covers in full. An MCP registry is scoped to one job inside that broader picture: cataloging MCP servers specifically, so a client that speaks the Model Context Protocol can find one and know how to connect.
That split has a history. The official MCP Registry launched in preview on September 8, 2025, backed by Anthropic, GitHub, PulseMCP, and Microsoft, to solve a protocol-specific problem: MCP servers were multiplying faster than anyone could track where they lived or how to reach them. Agent registries arrived later and wider in scope. AWS Agent Registry moved from preview in April 2026 to general availability on August 31, 2026, built to catalog an entire agent estate, not just its MCP connections, a scope what is AWS Agent Registry covers in depth.
The confusion behind this query is understandable, because one product now does both jobs. AWS Agent Registry treats MCP servers as a first-class record type alongside agents and skills, so from inside that single interface, an “agent registry” and an “MCP registry” can look identical. They aren’t interchangeable terms, and neither is a model registry, which tracks a different artifact (trained models) through a different lifecycle entirely. Agent registries, model registries, and MCP registries are three distinct governance surfaces, each scoped to a different artifact, and which one a team reaches for changes what gets asked. It never changes whether the answer returned across an approved connection is accurate.
What is an agent registry?
Permalink to “What is an agent registry?”Scale is the reason an agent registry exists. As the number of agents, tools, skills, and servers an organization runs climbs past what any team can track by memory, something has to hold identity, ownership, version, and approval status in one governed place. That problem is growing fast. According to Gartner (April 2026), the average global Fortune 500 enterprise will run more than 150,000 agents by 2028, up from fewer than 15 in 2025, and only 13% of organizations believe they have proper agent governance in place today. Gartner names a centralized agent inventory as the second of six steps for managing that sprawl, and containing agent sprawl is the exact job an agent registry does.
AWS Agent Registry is the concrete instance worth studying. Per AWS’s own documentation, it supports flexible resource types (agents, MCP servers, skills, and self-defined custom resources), runs a governance plane that tracks records through draft, pending-approval, approved, and deprecated states, and exposes only approved records through a separate discovery plane. Hybrid semantic and keyword search, an identity model for every registered resource, and CloudTrail audit logging round out the picture.
Core components of an agent registry
Permalink to “Core components of an agent registry”An agent registry typically includes:
- Identity and ownership: who created a resource and who is accountable for it
- Approval workflow: a lifecycle that gates what becomes discoverable, often integrated with an organization’s existing review pipeline via event notifications
- Version and deprecation tracking: which revision is current, and how a resource gets retired
- Discovery interface: search, browsing, and (in AWS’s case) a native MCP endpoint that lets an MCP client query the catalog itself
- Audit trail: a record of who registered, approved, or deprecated what, and when, feeding the same observability practices teams already run for agent behavior
None of these controls, on their own, say anything about whether the resource being tracked still does what its description claims once it’s live.
What is an MCP registry?
Permalink to “What is an MCP registry?”An MCP registry is a catalog scoped to one protocol: it lists which MCP servers exist, what they claim to do, and where a client can find them, without necessarily saying anything about the rest of an organization’s agent estate.
The official MCP Registry is the reference implementation. Per the Model Context Protocol project’s own announcement, it stores self-reported server metadata and pointers to where the code actually lives (npm, PyPI, NuGet, Docker Hub), never the package itself, and positions itself as the upstream source that opinionated, client-specific subregistries can build on top of rather than duplicate. That framing matters: the registry is metadata plumbing, not a marketplace, and it says nothing about whether a listed server is architected well or the right choice versus a plain API call for a given job.
Marketplaces sit a layer above it. Kong describes an MCP registry as the discovery layer that answers “what tools exist and where,” distinct from a gateway that enforces whether a given call is authorized. Smithery and Docker MCP Catalog both consume registry-style data and add a human-facing shopping experience on top, with Docker’s specifically packaging servers as vetted container images to sidestep the trust problem of running an arbitrary published package directly, the same trust problem that shows up whenever a server is meant to deliver governed business context rather than a generic utility.
Core components of an MCP registry
Permalink to “Core components of an MCP registry”An MCP registry typically includes:
- Server metadata: name, description, and the capabilities a server claims to expose
- Package or host pointer: where the actual server code lives, not the code itself
- Connection details: what a client needs to establish an MCP session
- Vetting layer (where curated): container packaging, security scanning, or manual review before a listing is trusted
An MCP server itself is not the same thing as an agent skill, even though both packages get distributed in adjacent catalogs. Agent skills versus MCP draws that line: a skill packages instructions an agent loads, an MCP server exposes tools and data an agent calls, and an agent skills registry governs the former the way an MCP registry governs the latter. Either way, the registry stops at the artifact’s identity and shape. It does not tell a client whether the server’s tools return the business’s current, approved answer once a connection is live.
Agent registry vs. MCP registry: head-to-head comparison
Permalink to “Agent registry vs. MCP registry: head-to-head comparison”The sharpest divergence between the two shows up inside AWS Agent Registry itself, because it is simultaneously an agent registry and a place where MCP servers get registered as one record type among several.
| Dimension | Agent registry | MCP registry |
|---|---|---|
| Primary function | Governs approved agents, tools, and servers | Catalogs MCP servers and how to reach them |
| What gets registered | Agents, MCP servers, skills, custom resource types | MCP servers specifically |
| Registration methods | Sync from a URL, or manual authoring | Self-reported metadata submission |
| Schema validation | MCP/A2A schemas validated at publish (AWS) | Format-level checks only, no behavior test |
| Approval lifecycle | Draft, pending approval, approved, deprecated | Ranges from none to marketplace curation |
| Discovery mechanism | Hybrid search, plus a native MCP endpoint | Registry API and marketplace search |
| Runtime role | Not in the call path; a directory to read | Not in the call path; points client to server |
| Ownership scope | Agent estate: agents, tools, skills, servers | MCP servers only |
| What neither one checks | Whether returned data is accurate or current | Same |
Example: registering an internal MCP server. A platform team points AWS Agent Registry’s record synchronization feature at their internal MCP server’s URL. Per AWS’s documentation, the registry fetches the server’s name, description, and tool metadata automatically and validates the definitions against the MCP protocol schema. A curator approves the record. It now shows up when someone runs search_discoverable_registry_records against the registry’s own MCP endpoint. That endpoint, per AWS’s registry-mcp-endpoint documentation, exposes exactly three tools: searching, listing, and batch-retrieving records. None of them invoke the registered server’s actual capabilities. To use the server for real, a developer’s MCP client still opens a direct connection to that server’s own URL, the same server that could just as easily sit in front of Salesforce or any other enterprise system. The registry answered “does this exist and is it approved.” A separate connection answered “can I use it right now.”
Schema validation is real governance, and it is worth taking seriously rather than dismissing. It confirms a registered MCP server is shaped correctly: its tool definitions parse, its capabilities are declared in a form other clients can read. It does not confirm that what those tools return reflects a business’s current, approved definitions of the underlying data, the same gap does an agent registry need a context layer names directly.
If your MCP server is registered, is it reachable?
Permalink to “If your MCP server is registered, is it reachable?”No, not automatically. Registration and reachability are two separate events, and AWS Agent Registry’s own architecture makes the point concrete: its MCP endpoint only exposes tools for searching, listing, and retrieving catalog records, never for invoking a registered server’s own tools.
Registration confirms three things: the server exists, its shape validates against the MCP schema, and it has cleared an approval workflow. It does not confirm the server is online right now, that access control policy permits the requesting client to reach it, or that the data it returns is current.
The common mistake is treating “it’s in the registry” as equivalent to “my agent can use it today.” A registered record can sit behind a firewall the requesting agent cannot cross, an expired credential, or a server that’s been taken down for maintenance, all while the registry entry itself still reads “approved.” Registered and reachable are answers to different questions, and conflating them is exactly the gap that stalls a rollout after the governance checkbox has already been ticked.
How do agent registries and MCP registries work together?
Permalink to “How do agent registries and MCP registries work together?”They are not competitors. An agent registry can incorporate an MCP registry’s job as one of its record types, which is precisely what AWS Agent Registry does, and a team can run both a broad agent registry and a narrower, protocol-specific one without redundancy.
Registering an MCP server inside a broader agent registry
Permalink to “Registering an MCP server inside a broader agent registry”AWS’s own design treats MCP servers, agents, and skills as siblings under one governance model: same approval lifecycle, same audit trail, same discovery interface. A server first gets vetted through an MCP-specific process (schema validation, tool-metadata capture) and then inherits the broader registry’s identity, ownership, and version tracking, the same layered pattern governed context for agent skills describes for skill packages sitting inside a wider enterprise skills governance model.
When a team needs both, separately
Permalink to “When a team needs both, separately”A single-purpose MCP deployment, a small team publishing one internal server, may only need the official MCP Registry or a curated marketplace like Smithery or Docker MCP Catalog. An enterprise standardizing governance across multi-agent systems needs the broader layer AWS Agent Registry, or an equivalent, provides, with MCP-specific registration as one input into it.
That broader layer rarely stays singular for long. A team running AWS Bedrock agents alongside other platforms, whether compared directly against LangGraph-built agents or run alongside them, does not get one registry across its whole estate; it gets AWS Agent Registry, plus whatever Google or Microsoft ship as an equivalent, plus the MCP-specific registries layered underneath each one. How to govern AI agents across multiple clouds walks through what that looks like in practice, and agent sprawl covers why the count keeps climbing even as more registries ship to contain it. The number of registries a team runs is a platform-count problem. Whether the content flowing through any one of them is accurate is a different problem, and no registry, agent-scoped or MCP-scoped, is built to answer it.
Why the registered-vs-reachable question is the wrong one to stop at
Permalink to “Why the registered-vs-reachable question is the wrong one to stop at”Agent registries and MCP registries both answer a version of the same question at different scopes: does this exist, and may it run or connect. AWS Agent Registry’s schema validation is genuine progress on that question. It is not progress on a different one: whether what a registered, reachable server actually returns reflects the business’s current, approved definitions of the data underneath it.
That second question is a context question, not a registry question, and it does not change no matter which registry approved the connection or which cloud it runs on. The context layer for AI agents is built to travel underneath whichever agent registry or MCP registry a platform team standardizes on, so the meaning an agent receives, what a metric means, who owns it, whether it’s still current, stays constant across AWS Agent Registry today and whatever a second cloud’s equivalent looks like tomorrow. That’s the argument an enterprise context layer makes in full, and it is why implementing one matters more than picking a single registry vendor. In practice, it is delivered through Atlan’s own MCP server once a connection is registered and reachable, keeping context architecture and agent memory consistent no matter which registry did the approving.
FAQs about agent registry vs. MCP registry
Permalink to “FAQs about agent registry vs. MCP registry”1. What is the difference between an agent registry and an MCP registry?
Permalink to “1. What is the difference between an agent registry and an MCP registry?”An agent registry catalogs which agents, tools, skills, and servers an organization has approved to exist and run. An MCP registry is scoped more narrowly to MCP servers specifically: what exists, and how a client connects to one. AWS Agent Registry does both at once by treating MCP servers as one of the record types it governs.
2. What is the official MCP Registry?
Permalink to “2. What is the official MCP Registry?”The official MCP Registry launched in preview on September 8, 2025, backed by Anthropic, GitHub, PulseMCP, and Microsoft. It stores self-reported server metadata and pointers to where a server’s code is hosted, positioning itself as the upstream source that client-specific marketplaces can build on rather than duplicate.
3. Does AWS Agent Registry support MCP servers?
Permalink to “3. Does AWS Agent Registry support MCP servers?”Yes. AWS Agent Registry validates registered MCP server definitions against the MCP protocol schema before publishing them, and supports registering a server either by synchronizing its metadata from a live URL or by authoring the record manually.
4. If my MCP server is registered, is it automatically reachable?
Permalink to “4. If my MCP server is registered, is it automatically reachable?”No. Registration confirms the server exists, is well-formed, and has been approved. It does not confirm the server is currently online, that network or authentication policy allows a given client to reach it, or that its data is accurate. A registered server can still be unreachable.
5. What is the difference between an MCP registry and an MCP gateway?
Permalink to “5. What is the difference between an MCP registry and an MCP gateway?”An MCP registry is a discovery layer that answers what servers exist and how to find them. An MCP gateway is an enforcement layer that sits in the call path, deciding whether a specific request is authorized to reach a specific tool. A registry helps you find a server; a gateway decides if you may use it.
6. Do I need both an agent registry and an MCP registry?
Permalink to “6. Do I need both an agent registry and an MCP registry?”Often, yes, though not always as two separate products. A small team publishing one MCP server may only need the official MCP Registry or a marketplace. An enterprise governing agents, tools, skills, and servers together typically needs a broader agent registry, like AWS Agent Registry, that incorporates MCP-specific registration as one input.
7. Is an MCP server the same thing as an AI agent?
Permalink to “7. Is an MCP server the same thing as an AI agent?”No. An MCP server exposes tools, data, or prompts that an agent can call over the Model Context Protocol; it is not itself an autonomous agent. An agent registry typically catalogs both, but as distinct resource types with different governance needs.
Sources
Permalink to “Sources”- AWS Agent Registry reaches general availability, August 31, 2026 (Unite.AI)
- AWS Launches Agent Registry in Preview to Govern AI Agent Sprawl, April 2026 (InfoQ)
- AWS Agent Registry key capabilities (AWS official documentation)
- Using the Registry MCP endpoint (AWS official documentation)
- Introducing the MCP Registry, September 8, 2025 (Model Context Protocol blog)
- Official MCP Registry
- What is an MCP Registry? (Kong)
- Publish Once or Fragment Forever? About the State of MCP Registries (Friedrichs-IT)
- Gartner Identifies Six Steps to Manage AI Agent Sprawl, April 28, 2026
