Agent Zero — ERC-8004 Agent Intelligence
Server Details
Free read-only ERC-8004 agent-intel tools: coverage, leaderboards, agent vetting, payment graph
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 4 of 4 tools scored.
Each tool serves a distinct purpose: agent-specific summary, network-wide coverage stats, capability leaderboards, and payment graph preview. No overlap or ambiguity.
All tool names follow the consistent verb_noun pattern get_<noun> in snake_case, making them predictable and easy to understand.
Four tools is slightly below the typical well-scoped range, but each tool provides essential functionality for the server's purpose of querying agent intelligence data.
The tool set covers core needs: individual agent vetting, market sizing, top agents, and network graph. Minor gaps like filtering or search are acceptable given the stated free tier limitations.
Available Tools
4 toolsget_agent_summaryAInspect
Objective, counts-only signals for one ERC-8004 agent.
Args:
chain: one of "base", "ethereum", "bnb".
agent_id: the numeric ERC-8004 agent id.
Returns reachability, TLS validity, x402 support, payments-received (boolean only),
MCP tool count, OpenAPI method count, well-known presence, owner-named (boolean), and
a neutral status label (Live & monetized / Live, no payments / Stub or unreachable).
No owner identity string and no payment amounts — those are paid. Returns an `error`
field if the agent is not indexed. Use this to vet a counterparty agent before
transacting.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| agent_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the returned fields (reachability, TLS validity, etc.) and explicitly states what is not returned (owner identity, payment amounts). It also mentions an error field, adding beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence, Args, Returns, and usage note. It is concise and front-loaded, though not extremely terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two simple parameters and no output schema or annotations, the description is remarkably complete: it enumerates all return fields with types, defines parameter values, explains error behavior, and sets expectations for what is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds significant value over the schema: it specifies allowed values for 'chain' ('base', 'ethereum', 'bnb') and explains that 'agent_id' is a numeric ERC-8004 ID. Since schema coverage is 0%, this is crucial guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Objective, counts-only signals for one ERC-8004 agent' with a specific verb and resource. It is distinct from sibling tools like get_coverage_stats, but no explicit differentiation is given, scoring a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description ends with 'Use this to vet a counterparty agent before transacting,' providing a clear usage context. It does not specify when not to use alternatives, so it scores a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coverage_statsAInspect
Live coverage of the ERC-8004 agent economy across Base, Ethereum and BNB Chain.
Returns counts only: how many agents are indexed, how many expose a live MCP server /
OpenAPI / well-known card, total MCP tools and OpenAPI methods observed, contracts
verified, EOAs and owners identified, plus a per-chain breakdown. No names, addresses,
or handles. Use this to size the market and see where capability density is growing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns counts only (no names/addresses) and is 'live coverage,' but does not mention data freshness, update frequency, or any rate limits. Adequate but leaves minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, followed by specifics and use case. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is fairly complete: it explains the returned categories and the use case. It could be more structured (e.g., list format) but is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty). The description adds value by detailing what the output contains, which compensates for the lack of output schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live coverage counts for the ERC-8004 agent economy across Base, Ethereum, and BNB Chain, differentiating itself from siblings like get_agent_summary (likely more granular) by emphasizing aggregate counts and market sizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use this to size the market and see where capability density is growing,' providing clear context for when to use. It does not directly contrast with siblings or mention when not to use, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_leaderboardsAInspect
Top ERC-8004 agents by live capability, plus the most recently indexed.
Three ranked lists — top by live MCP tool count, top by OpenAPI method count, and
most-recently indexed — each with agent_id, chain, public name, a shareable detail
URL, and the relevant count. Names and counts only: no owner wallets, handles, or
endpoint URLs. Use this to find the most capable / most active agents to integrate or
watch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It details what each list contains, the fields returned, and explicitly states what is excluded (no owner wallets, handles, endpoint URLs). This gives clear behavioral expectations to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loaded with the main purpose, and uses a clear bullet-style list. It is efficient with no extraneous sentences, though could be slightly more concise by merging some lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately explains the return format (three lists, fields including agent_id, chain, name, URL, count). It covers what is included and excluded, but could mention if any pagination or limit exists. Overall sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially 100%. The description adds no parameter information, but per guidelines, with 0 parameters the baseline is 4. The description focuses on output, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns top ERC-8004 agents by live capability and most recently indexed, with three ranked lists. It specifies exact content (agent_id, chain, public name, shareable URL, count) and distinguishes from siblings by focusing on leaderboards rather than individual summaries or stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to find the most capable/active agents to integrate or watch, providing clear positive guidance. It does not explicitly state when not to use it or mention alternatives, but the sibling tools list provides context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!