ERC-8004 vs MCP: What Each Standard Does for AI Agents
ERC-8004 and MCP solve separate jobs. A registered ERC-8004 agent gets an onchain identity, a metadata pointer, public feedback, and validation hooks. An MCP server gives AI clients a way to list and call tools, read resources, and fetch prompts. Put them together when a public agent needs both trust context and a callable endpoint.
In brief: ERC-8004 handles discovery and trust context through identity, metadata, feedback, and validation registries. MCP handles tool and context transport through tools, resources, prompts, and protocol messages. A useful directory keeps registration, metadata resolution, declared services, and verified behavior as separate states.
Direct answer
The wrong question is "which one wins?" The useful split is "where does the caller learn who this agent is, and where does the caller execute a capability?"
ERC-8004 is a draft Ethereum ERC for registering trustless agents. Its motivation section says MCP and A2A cover communication, while discovery and trust remain outside those protocols. In response, the ERC defines identity, reputation, and validation registries.
Model Context Protocol connects AI applications to external systems. Its docs define hosts, clients, servers, capability negotiation, and server features such as resources, prompts, and tools.
A builder can publish an MCP endpoint inside an ERC-8004 registration file. Registry data gives indexers a durable place to discover the agent. MCP-capable clients can then call the endpoint when their product supports the server's transport, auth model, and tool schema.
Comparison
| Question | ERC-8004 | MCP |
|---|---|---|
| Main job | Public agent discovery and trust | Tool and context transport for AI clients |
| Primary object | Onchain agent plus agentURI | MCP server endpoint or package |
| First thing to verify | agentURI resolves and service declarations are real | initialize works and tools/list returns usable schemas |
| What it can show | Owner, registration file, feedback, validation evidence | Callable functions, readable context, prompt templates |
| What it cannot guarantee | Advertised endpoints are live or safe | Server ownership, public reputation, or onchain history |
| Best fit | Public agents that need durable discovery | Services that AI apps need to call during a task |
What ERC-8004 covers
ERC-8004 proposes blockchain registries so agents can be discovered across organizations without a prior trust relationship. Payment, messaging, and runtime execution stay outside the ERC. For the broader registry overview, see ERC-8004 Explained.
Identity Registry uses an ERC-721 style record and assigns each agent an agentId. The token URI is called agentURI; clients fetch it to read the agent registration file.
Reputation Registry lets clients post feedback against an agent with values, tags, optional evidence URIs, and hashes. Validation Registry lets validators respond with a 0-100 result and optional evidence.
The limit matters: a registry can tie a registration file to an onchain agent, but it cannot prove that listed capabilities are functional or non-malicious. A directory still has to probe endpoints, inspect metadata, and separate claims from observed behavior.
What MCP covers
MCP standardizes the connection between an AI application and external systems. MCP tools are callable functions such as query_wallet, search_docs, create_invoice, or run_backtest. MCP resources are readable data such as files, schemas, URLs, or API responses. MCP prompts are reusable templates for common model interactions.
The current flow starts with initialization and capability negotiation. A client can then list tools, read resources, fetch prompts, and call tools with structured arguments.
Security sits mostly in the host and product code around MCP. Hosts need consent screens, authorization policy, logging, sandboxing, and recovery paths because the protocol cannot decide whether a given call is safe for a user.
How they combine
The simplest combined design has five steps:
- Build a service that performs a narrow job for a specific caller.
- Wrap safe callable operations as MCP tools with strict input schemas.
- Publish a registration file that lists the MCP endpoint under
services. - Register that file in ERC-8004 and keep the metadata URI reachable.
- Let indexers resolve the record, probe the endpoint, and display live evidence beside the declaration.
An ERC-8004 registration file can include a service entry:
{
"name": "MCP",
"endpoint": "https://agent.example.com/mcp",
"version": "2025-06-18"
}
That JSON entry only says where a client should try MCP. A buyer agent or directory should still initialize the endpoint, request tools/list, inspect each schema, and complete a safe call before treating the service as usable.
Failure modes
Registration alone is not proof that execution works. A token can point to a dead URL, an unpinned IPFS file, a localhost endpoint, or an MCP server that lists tools and fails every call.
An MCP package is not an accountable agent by default. A server URL, npm package, or Docker image can be useful, but it does not automatically carry ownership history, onchain feedback, or validation records.
Declared support is weaker than verified support. "Metadata says MCP" means a service entry exists. "Verified MCP" should mean the endpoint initialized, returned tools, exposed useful schemas, and completed at least one safe call.
The Spawn position
A useful directory grading model keeps four states visible on every relevant agent page:
- Registered: an ERC-8004 identity exists on a specific chain.
- Resolved: the metadata URI was fetched and parsed.
- Declared: the metadata lists MCP, A2A, OASF, web, x402, or another service.
- Verified: a live check observed usable behavior at the endpoint.
That sequence prevents a common mistake in agent directories: collapsing a registry record, a metadata claim, and a working call path into one badge. Builders need the split because each step fails in different ways and requires a different fix.
The Spawn uses that split across pages such as agent check, grading, and protocol-specific guides like MCP vs A2A and Best Practices for Registering Onchain AI Agents.
FAQ
Can an ERC-8004 agent expose MCP?
Yes. The registration metadata can include a service entry for an MCP endpoint. The metadata only declares where to try the endpoint; the caller or indexer still has to initialize MCP, list tools, inspect schemas, and run a safe call.
Does MCP prove who owns an agent?
No. MCP describes a server's callable capabilities. It does not provide onchain ownership history, public feedback, or validation records by itself. ERC-8004 is useful when that public trust context matters.
What should a directory verify?
A directory should verify the registry record, metadata fetch, declared service entries, and observed endpoint behavior separately. A single "MCP supported" badge hides too much failure surface.