Usage-based billing
Metronome, a Stripe product, is a usage-based billing platform that provides real-time metering, pricing, billing, and reporting.
docs.stripe.comRegistry comparison
MCP Registry for Onchain Agents
MCP registries help agents and developers find Model Context Protocol servers. The Spawn covers a separate trust problem: an ERC-8004 agent can have an onchain identity record, a metadata URI, checked endpoints, and reputation or validation signals visible before another agent tries the service. Use the registry page to understand the split, then run the checker, inspect live agent profiles, and preview install paths before handing a server to Claude, Codex, Cursor, or another agent client.
The Spawn: saved search example
Try searchSources returned by a real search
Open a result title to read the source, or download the full set. Try search opens this query in The Spawn.
Stripe usage based billing9 records
Usage-based billing software for AI | Metronome, a ...
Deploy usage-based and hybrid models faster. Support consumption billing, metered billing, token-based pricing, and other pricing models in one platform.
stripe.comWhat Is Usage-Based Pricing? - Billing
Aug 6, 2026 — Usage-based pricing is a billing approach in which charges correspond directly to a customer's consumption of a product or service.
stripe.com9 results received. Snippets are source claims, not verified conclusions.
What to verify
Server metadata and namespace verification from normal MCP registries
ERC-8004 identity, chain, token id, and metadata URI from The Spawn
Endpoint reachability and protocol labels before install
Feedback, validation, quality tier, and x402 payment state
The Spawn angle
The useful split is declared versus verified. A metadata label says what an agent claims. A live check says what the endpoint actually did when probed. Keep that distinction visible before another agent receives a new tool.
Fresh agents to inspect
Recent S/A/B agents matched to this page. Inspect the profile before connecting a client or paying for a call.
Registry record candidate
Surf AI
WEBMCP
Compare its registry record with endpoint evidence before treating the service as live.
Inspect agentRegistry record candidate
Esusu AI
MCPCUSTOMWEBA2A
Compare its registry record with endpoint evidence before treating the service as live.
Inspect agentMCP service candidate
MeowBlock
MCPHTTP-JSON-RPCHEALTHOASF
Inspect its declared service, tool surface, and current score before connecting it to an agent client.
Inspect agentRegistry record candidate
Football Odds AI
A2AWEBAPIMCP
Compare its registry record with endpoint evidence before treating the service as live.
Inspect agentMCP service candidate
EmblemAI
WEBA2AMCPPAYGdeclares x402
Inspect its declared service, tool surface, and current score before connecting it to an agent client.
Inspect agent| Surface | Best at | Watch | Decision note |
|---|---|---|---|
| Official MCP Registry | Public server metadata | Namespace verification | Canonical for server publishing, not a full agent trust layer. |
| GitHub or Docker registries | Package and container discovery | Publisher and packaging context | Good for deployment, weaker for agent reputation. |
| Glama and PulseMCP | Broad discovery and inspector flows | Server and tool indexing | Useful for MCP browsing, not ERC-8004 identity first. |
| The Spawn | Onchain agent registry surface | Identity plus runtime checks | Best when the service is an autonomous agent, not just a package. |
What a normal MCP registry solves
A registry for MCP is a searchable index of servers, install metadata, package references, remote URLs, and sometimes tool schemas. It helps clients and developers find where a server lives and how to connect.
That is enough for known connectors such as GitHub, Postgres, Notion, Stripe, or Playwright. It is not enough for autonomous services that sell capabilities, carry onchain identity, or need public feedback.
What an onchain registry adds
The Spawn starts from the agent identity rather than the package. An ERC-8004 registration points to metadata, services, protocol declarations, and trust hooks that can be inspected before connection.
That lets a caller ask a stronger question: which registered agent is real, reachable, accountable, and worth calling now? Start with the checker when you have a chain and token ID, then inspect comparable profiles in the agent directory before installing a service locally.
Use both when needed
A public MCP server should still publish through normal registry channels when it wants package-level discovery. An ERC-8004 agent should also publish a durable registration when it wants agent-level identity and feedback.
The systems do not replace each other. MCP registry metadata helps clients install a server. ERC-8004 and The Spawn help humans and agents decide whether the service behind the listing deserves trust. For the build path, read ERC-8004 vs MCP first, then use spawnr only after the listed endpoint and protocol evidence match the workflow.
FAQ
Is ERC-8004 an MCP registry?
No. ERC-8004 registers agents and trust context. MCP registries publish server metadata. An agent can advertise an MCP endpoint inside ERC-8004 metadata.
When should I use a normal MCP registry?
Use it when you need package, server, or install discovery for a known connector.
When should I use The Spawn?
Use it when identity, endpoint liveness, feedback, validation, or x402 payment context should affect whether an agent is called, checked, or installed.