← Learn

Agent Registry vs MCP Registry for MCP Servers

The Spawn agent registry and MCP registry comparison cover

For MCP clients and aggregators, publish server metadata in the MCP Registry. For public agent identity, publish the same service as an ERC-8004 agent with an agentURI, service declarations, feedback paths, and validation hooks.

In brief: MCP Registry entries describe servers, while ERC-8004 records register agents. Use both when a callable MCP server should also be discoverable as a public agent, and verify runtime behavior separately because neither registry proves the endpoint is live, safe, payable, or useful.

Next action: run the checker for a known ERC-8004 record, or browse agents that declare MCP to compare public records ordered by score. If you are deciding how MCP server metadata is published and consumed, continue to the MCP Registry guide.

Direct answer

The practical question is not "ERC-8004 or the MCP Registry?" It is "which discovery record should a caller inspect first, and what still has to be verified before the server is trusted?"

Official registry docs describe a centralized metadata repository for publicly accessible MCP servers. That repository stores standardized server.json metadata, supports namespace management through DNS verification, and exposes a REST API for clients and aggregators to discover servers.

ERC-8004 is a draft ERC for trustless agents. Its motivation says MCP and A2A cover communication, while agent discovery and trust need separate mechanisms. Its registration file can include service entries, including an MCP endpoint with a version such as 2025-06-18.

Use both when the same project is an MCP server and a public agent. MCP-native metadata describes how to locate and install or connect to the server. ERC-8004 gives the service an agent record that indexers can resolve by chain, registry, and agentId.

Agent Registry vs MCP Registry comparison

QuestionMCP RegistryERC-8004 agent registry
Primary jobPublish metadata for publicly accessible MCP serversRegister public agents and their registration files
Main recordserver.json with name, package or remote location, version, and discovery metadataERC-721-style agent record whose agentURI resolves to an agent registration file
Namespace modelReverse DNS-style names tied to verified GitHub accounts or domainsChain namespace, chain ID, identity registry address, and agentId
Runtime protocolMCP server metadata points to stdio or Streamable HTTP connection detailsRegistration file may advertise MCP, A2A, OASF, web, ENS, DID, email, or wallet endpoints
Trust signal it can carryNamespace authentication and standardized server metadataIdentity, reputation feedback, validation responses, and optional endpoint-domain verification
What it does not proveUptime, tool-call success, safety, payment settlement, or that the code will stay unchangedEndpoint liveness, MCP tool-call success, safety, payment settlement, or that every declared service works
Best next checkFetch registry metadata, inspect package or remote URL, initialize MCP, list tools, and call one safe toolResolve agentURI, parse services, verify endpoint domain when relevant, initialize MCP, list tools, and call one safe tool

Here, "registry" carries two meanings: MCP server metadata on one side, blockchain agent registration on the other. Treat both as discovery layers and run runtime checks separately.

What the MCP Registry gives an MCP server

MCP's introduction defines the protocol as an open standard for connecting AI applications to external systems such as data sources, tools, and workflows. The server concepts docs split capabilities into schema-defined tool operations, structured resources, and reusable prompt templates.

An MCP server needs more than a URL. A client or host needs to know how to locate it, how to install or connect to it, what transport it uses, and what capabilities it exposes. The official registry handles the metadata side of that job.

For public discovery, the registry docs describe server.json as the standardized format. It can include a unique server name, repository information, package or remote server location, execution instructions, version, and discovery data such as a description or capabilities.

The registry's trust boundary is also explicit. Namespace authentication ties names such as io.github.username/server or com.example/server to verified GitHub accounts or domains. Security scanning is delegated to package registries and downstream aggregators. The registry focuses on namespace authentication and metadata hosting, not runtime certification.

What ERC-8004 gives the same service

ERC-8004 gives the service an agent identity record. The Identity Registry uses an ERC-721-style record, where tokenId is called agentId and tokenURI is called agentURI. The agentURI must resolve to a registration file.

The registration file can list services. The EIP's example includes this MCP service entry:

{
  "name": "MCP",
  "endpoint": "https://mcp.agent.eth/",
  "version": "2025-06-18"
}

That declaration is useful, but it is still a pointer. A caller should not treat it as proof that the endpoint initializes, returns tools, enforces authorization, or completes calls.

Compared with MCP-native metadata, ERC-8004 adds trust surfaces for agent records. Reputation Registry feedback can record tagged feedback values and optional evidence. Validation Registry responses can record validator outputs from 0 to 100 with optional evidence.

The EIP also describes optional endpoint-domain verification for HTTPS endpoints. Those mechanisms can help an indexer build context. However, they still need review and aggregation rules.

The EIP says payments are orthogonal to ERC-8004, so a service that charges for calls needs a separate payment-specific check.

How to publish an MCP server as an ERC-8004 agent

Start by publishing the MCP server through the normal MCP path. The TypeScript quickstart moves in this order: add verification information to the package, publish the package, install mcp-publisher, create server.json, authenticate, publish, and verify the result through the registry API.

Then create the ERC-8004 agent record around the same public service:

  1. Give the MCP server a stable public identity: repository, package or remote URL, version, and owner namespace.
  2. Publish or update the MCP Registry server.json so clients and aggregators can discover the server.
  3. Test the MCP runtime through the transport your server actually supports.
  4. Create an ERC-8004 registration file with a concrete name, description, image, services[], x402Support, active, and registrations[].
  5. Add an MCP service entry with the public endpoint and protocol version.
  6. Host the registration file at a durable https://, ipfs://, or data: URI.
  7. Register the agentURI on the chosen ERC-8004 Identity Registry.
  8. When the MCP endpoint is on a different HTTPS domain, consider the EIP's optional endpoint-domain verification file.
  9. Run a fresh external verification pass before promoting the agent.

Do not copy the MCP Registry record blindly into the ERC-8004 file. One record serves MCP clients looking for server metadata; the other serves indexers looking for agent metadata. They should agree on the endpoint, version, repository, and description, but they serve different readers.

Publishing checklist

StepPass condition
MCP server identityServer name, repository, package or remote URL, and version are stable enough for clients to inspect
Server metadataserver.json describes the server location, package or remote endpoint, transport, and installation or connection details
Registry namespaceGitHub, DNS, or another supported namespace method matches the publisher claim
Runtime transportServer supports the declared transport: stdio or Streamable HTTP under the 2025-06-18 specification
ERC-8004 registration fileRequired fields from the EIP structure are present, including type, name, description, image, services, x402Support, active, and registrations
MCP service entryservices[] includes name: "MCP", a public endpoint, and the protocol version the server expects
Metadata durabilityagentURI resolves from infrastructure that will not disappear after launch
Domain alignmentEndpoint-domain verification is used when the endpoint domain needs separate proof under the EIP's optional flow
Product next actionThe public record is ready for inspection through The Spawn checker and live examples in Agents

Verification checklist

Verification starts after publishing because both registries can be correct while the runtime is broken.

For the MCP Registry record:

  • Fetch the server metadata from the registry API or an aggregator that uses it.
  • Match the namespace against the repository, package, domain, or remote server claim.
  • Inspect the package or remote server location named by server.json.
  • Compare the declared transport with the actual server behavior.

For the MCP runtime:

  • With stdio, confirm the launch command emits only valid MCP messages on stdout.
  • With Streamable HTTP, confirm the endpoint supports the expected POST and GET behavior.
  • Initialize the server with the intended protocol version.
  • Request tools/list, resources/list, or prompts/list as appropriate.
  • Call one safe read-only tool or read one safe resource.
  • Record auth errors, content type, timeout behavior, and response shape.

For the ERC-8004 record:

  • Start by resolving the onchain agentURI.
  • Parse the registration file without guessing missing fields.
  • Check that the registrations[] entry points back to the chain, registry, and agentId you inspected.
  • Compare the MCP service endpoint with the endpoint checked above.
  • Read any reputation or validation evidence separately from runtime checks.
  • Paid services need a separate payment-specific verification flow before anyone claims payment readiness.

The public The Spawn path is: run the checker, inspect the current agent directory, read the agent registration checklist, then use spawnr only after the record and endpoint look worth installing. For broader context, compare ERC-8004 explained, MCP vs A2A, and the 500K onchain agent snapshot.

Common mistakes

Treating registry presence as liveness proof

A registry result can describe a server that is currently down, and an ERC-8004 registration can point to an MCP endpoint that no longer answers. Liveness requires a current runtime check.

Treating MCP metadata as agent trust

MCP metadata helps a host discover and connect to a server. It does not create an onchain agent record, reputation trail, validation trail, or payment proof.

Treating ERC-8004 as a replacement for the MCP Registry

ERC-8004 does not replace the MCP Registry. It adds a public agent record around services that may include MCP, while clients and aggregators still benefit from MCP-native metadata.

Declaring paid support without payment evidence

Neither registry proves that a paid call settled. If the service is paid, verify the payment challenge, signed retry, settlement result, and final resource delivery before making payment claims.

Source and method

On July 17, 2026, I rechecked the standards pages listed below and the public action routes linked in this guide:

The recommendations above separate sourced protocol facts from product actions. Public The Spawn links are next actions for inspection, not evidence that a registry entry is live, safe, paid, or owner-verified.

FAQ

Which registry should come first?

Publish and test the MCP server first, then register the agent once the endpoint, metadata, and version are stable. If you already have an ERC-8004 record, update the registration file after the MCP Registry metadata and runtime checks are clean.

Can registry metadata prove safety?

Registry metadata alone is not a safety review. The official registry provides namespace authentication and standardized metadata, while its docs describe security scanning as work handled by underlying package registries and downstream aggregators. Safety still depends on code review, auth, permissions, transport hardening, and runtime testing.

Can ERC-8004 prove endpoint liveness?

An ERC-8004 record can advertise an MCP endpoint in the registration file, but a caller still has to initialize the server, list tools or resources, and run a safe call before treating the endpoint as usable.

Can one MCP server be an ERC-8004 agent?

An ERC-8004 registration file can include an MCP service entry with an endpoint and version. That lets an indexer discover the agent record and then verify the MCP endpoint separately.

Is ERC-8004 an MCP Registry replacement?

Use the MCP Registry as the native metadata repository for public MCP servers. Use ERC-8004 as an agent registration standard that can point to MCP as one service surface. Builders can use both without making either one replace the other.

After publishing

Run The Spawn checker against the public agent record, inspect the result in Agents, and use spawnr only after the registry data and endpoint behavior match what you intended to publish.