Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ERC-8004 MCP Server Search for fitness agents on ERC-8004"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server for querying ERC-8004 AI agent identities. It queries The Graph subgraph for on-chain data and fetches IPFS metadata for full off-chain details.
Search agents by name with optional protocol filtering (MCP/A2A)
List agents with pagination, sorting, and protocol filtering
Get full agent details including contract state, services, identity, and statistics
Get feedback/reviews with scores, tags, review text, and MCP/A2A context
Get engagement stats with tag analysis and score distribution
Get full metadata including off-chain IPFS attributes (certifications, model info, social links, pricing, etc.)
Related MCP server: agentranking
Tool | Description |
| Search agents by name with optional protocol filter |
| Browse agents with pagination and sorting |
| Get full details for an agent by ID |
| Get all feedback/reviews for an agent |
| Get engagement metrics and score breakdown |
| Get full on-chain + off-chain metadata (IPFS) |
yarn installyarn devyarn dev:httpThe server starts on http://localhost:3100/mcp by default. Set the PORT environment variable to change it.
yarn build
yarn start # stdio
yarn start:http # HTTPAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"erc-8004-agents": {
"command": "npx",
"args": ["tsx", "/path/to/erc-8004-mcp-server/src/index.ts"]
}
}
}Or with the compiled version:
{
"mcpServers": {
"erc-8004-agents": {
"command": "node",
"args": ["/path/to/erc-8004-mcp-server/dist/index.js"]
}
}
}Add to your Cursor MCP settings (.cursor/mcp.json):
{
"mcpServers": {
"erc-8004-agents": {
"command": "npx",
"args": ["tsx", "/path/to/erc-8004-mcp-server/src/index.ts"]
}
}
}Or for the HTTP transport:
{
"mcpServers": {
"erc-8004-agents": {
"url": "http://localhost:3100/mcp"
}
}
}Once connected, you can ask your AI assistant:
"Search for fitness agents on ERC-8004"
"List the most recently created agents with MCP support"
"Get details for agent 11155111:1213"
"Show me all the feedback for Larry the Lobster"
"What are the full metadata attributes for agent 11155111:1213?"
"Show me the stats and score breakdown for this agent"
On-chain data: ERC-8004 Subgraph on Sepolia testnet
Off-chain metadata: IPFS via public gateways (ipfs.io, cloudflare-ipfs.com, dweb.link)
Composite tool that combines identity, reputation, and validation data to produce a holistic trust evaluation for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only. The description adds valuable context that it is a composite tool merging multiple data sources (identity, reputation, validation), which goes beyond what annotations provide. No contradictions.
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 a single, concise sentence that effectively communicates the tool's purpose without unnecessary details. Every word contributes value.
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?
Despite having only one parameter and no output schema, the description fails to specify the output format (e.g., trust score, confidence interval). A composite tool expecting a holistic evaluation should disclose what the agent will receive in return.
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?
Schema coverage is 100% with a clear description for agentId. The tool description does not add extra parameter meaning beyond what the schema already provides, so a baseline score of 3 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's function: it produces a holistic trust evaluation for an agent by combining identity, reputation, and validation data. This distinguishes it from sibling tools like get_agent or get_reputation_summary.
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 implies this is the go-to for a comprehensive trust evaluation, but does not explicitly state when to use this tool versus alternatives like get_reputation_summary or get_validation_status. No exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific ERC-8004 agent by ID, including contract state, services, metadata, statistics, and recent feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by specifying the scope of returned data (contract state, services, etc.). No behavioral traits beyond read-only are mentioned, but annotations cover the main safety profile.
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?
A single sentence that front-loads the purpose and then lists included details. Every word contributes meaning with no redundancy.
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?
For a single-parameter read-only tool with no output schema, the description sufficiently covers what the tool returns by listing categories. Given annotations handle safety, no further context is needed.
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 input schema already describes the single parameter 'agentId' with an example format ('11155111:1213'). The description adds no additional semantic information beyond what the schema provides.
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's purpose: retrieving full details for a specific ERC-8004 agent by ID, listing included categories (contract state, services, metadata, statistics, feedback). This distinguishes it from sibling tools that focus on single aspects.
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?
No explicit when-to-use or when-not-to-use guidance. The description implies usage via agent ID but does not mention alternatives or conditions for using this tool over narrower siblings like erc8004_get_agent_feedback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all feedback and reviews for an ERC-8004 agent, including scores, tags, review text, and MCP/A2A context.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of feedback entries to return (default: 50) | |
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which is consistent. The description adds value by disclosing that the tool returns scores, tags, review text, and MCP/A2A context. However, it does not mention pagination behavior or any potential constraints beyond the schema. No contradictions with annotations.
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 a single concise sentence, with no unnecessary words. It front-loads the main action and output. Efficient and well-structured.
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 the tool's complexity (2 parameters, no output schema), the description provides a good overview of what is returned. However, it lacks details on error conditions, ordering of results, or handling of missing data. The inclusion of 'MCP/A2A context' hints at additional information, but not fully specified. Still, it is largely complete for a retrieval 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?
Schema coverage is 100% with both parameters (agentId, limit) having clear descriptions. The tool description does not add any additional meaning beyond what is in the schema. Baseline score of 3 is appropriate since the schema sufficiently explains the parameters.
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 verb 'Get' and the resource 'feedback and reviews for an ERC-8004 agent', including specific components like scores, tags, review text. This distinguishes it from sibling tools like erc8004_get_agent or erc8004_get_agent_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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., erc8004_get_feedback_details or erc8004_get_reputation_summary). No context about prerequisites, exclusions, or typical use cases is given. The description is self-explanatory but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full on-chain and off-chain metadata for an ERC-8004 agent. Fetches the IPFS registration file and returns all extended attributes.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds useful context about fetching IPFS files and returning extended attributes. No contradictions. It could mention error handling or rate limits, but the current coverage is good.
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?
Two sentences, zero wasted words, front-loaded with the key action. Every sentence serves a purpose.
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 the tool has a single parameter, readOnlyHint annotation, and no output schema, the description is nearly complete. It could mention the return format or data types, but the current text is sufficient for a simple read operation.
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?
Schema coverage for the single parameter agentId is 100%, and the description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter adequately.
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 verb 'Get', the resource 'full on-chain and off-chain metadata for an ERC-8004 agent', and specifies it fetches IPFS registration and extended attributes, distinguishing it from siblings like erc8004_get_agent.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description only implies usage for metadata retrieval, but does not differentiate from similar tools like erc8004_get_agent or erc8004_list_agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get engagement metrics, score breakdown, feedback tag analysis, and score distribution for an ERC-8004 agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds context about the specific data returned (engagement metrics, scores, etc.), which is consistent. No contradictions, and the read-only nature is clear.
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 a single sentence that conveys all necessary information without any redundant or extraneous text.
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 the single parameter, full schema coverage, readOnlyHint annotation, and the description listing the output components, the description provides sufficient context for an agent to use the tool correctly.
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?
Schema coverage is 100% with a single parameter agentId that includes an example in its description. The tool description does not add additional meaning beyond the schema, so it meets baseline.
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 verb 'Get' and the resource 'engagement metrics, score breakdown, feedback tag analysis, and score distribution for an ERC-8004 agent', distinguishing it from sibling tools like get_agent_feedback or get_reputation_summary.
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 lacks explicit guidance on when to use this tool vs alternatives. Usage is implied by the tool name and description, but no context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed individual feedback records from the Reputation Registry, including signed values and revocation status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of feedback records (default: 50) | |
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') | |
| includeRevoked | No | Include revoked feedback entries (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates the tool is read-only, so the description's claim of 'Get' is consistent. The description adds that the tool includes signed values and revocation status, but other behavioral aspects like pagination limits or error handling are not disclosed. Since annotations carry the main burden, a 3 is appropriate.
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?
A single sentence that is concise, front-loaded with the verb and resource, and contains no extraneous information. Every word adds value.
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?
The description gives a hint about return content (signed values, revocation status) but does not specify the structure or all fields. With no output schema, the description should be more complete to set expectations. It is adequate but not thorough.
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?
Schema description coverage is 100% with clear parameter descriptions. The tool description adds no additional parameter-level meaning beyond stating the return includes signed values and revocation status, which applies to the result, not parameter choices. Baseline 3 is correct.
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 action ('Get'), the resource ('detailed individual feedback records'), and additional details ('signed values and revocation status'). It effectively distinguishes from siblings like erc8004_get_agent_feedback, which likely returns aggregated or different feedback data.
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?
No guidance on when to use this tool versus alternatives like erc8004_get_agent_feedback or erc8004_get_reputation_summary. Without explicit differentiation, an agent may choose the wrong tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the aggregated reputation summary for an ERC-8004 agent from the Reputation Registry.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates safety. The description adds minimal behavioral context beyond the annotation, only specifying the tool reads reputation data. No additional traits (e.g., performance, auth needs) are disclosed.
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 a single, efficient sentence with no fluff. It is front-loaded with the action and resource, making it easy to parse quickly.
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?
For a simple read-only tool with one parameter, the description sufficiently conveys the core function. It does not describe the return format or what the summary contains, but given no output schema, this is a minor gap. The tool remains fully usable.
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 input schema already provides 100% coverage with a description for agentId. The tool description does not add meaning beyond restating that the agent is from ERC-8004, which is already clear from the context. Baseline score of 3 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 action ('Get'), the resource ('aggregated reputation summary'), and the scope ('for an ERC-8004 agent from the Reputation Registry'). It uniquely identifies the tool's purpose among siblings like erc8004_get_agent or erc8004_get_agent_feedback.
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 implies usage context (retrieving aggregated reputation) but does not provide explicit guidance on when to use this tool versus alternatives (e.g., erc8004_get_agent_stats or erc8004_get_agent_metadata). No when-not-to-use or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the validation status of an ERC-8004 agent from the Validation Registry (zkML, TEE attestation, or stake-secured re-execution).
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying the types of validation (zkML, TEE, stake-secured). However, it does not disclose potential behaviors like error handling, response format, or prerequisites. Adequate but not rich.
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?
Single sentence, 20 words, no redundancy. Essential information is front-loaded. Every word contributes to understanding the tool's purpose.
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?
For a simple read-only tool with one parameter, the description provides the necessary context (validation registry and types). However, without an output schema, it could benefit from mentioning what the response contains (e.g., boolean, status enum) or common error scenarios.
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?
Schema description coverage is 100% for the single parameter agentId. The description does not add any extra meaning beyond the schema's description. Baseline 3 applies as the schema already documents the parameter clearly.
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 what the tool does: 'Check the validation status of an ERC-8004 agent from the Validation Registry'. It specifies the resource and the context (zkML, TEE, stake-secured). This distinguishes it from sibling tools like get_agent or get_agent_stats, which serve different purposes.
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?
No guidance on when to use this tool vs alternatives. The description does not mention when to prefer this over, e.g., get_agent for validation details or evaluate_agent_trust for trust assessment. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse ERC-8004 registered AI agents with pagination and sorting. Supports protocol and chain filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based, default: 1) | |
| chain | No | Filter by chain ID (e.g., '1' for mainnet, '137' for Polygon) | |
| sortBy | No | Field to sort by (default: createdAt) | createdAt |
| pageSize | No | Number of agents per page (default: 20, max: 100) | |
| protocol | No | Filter by protocol support: 'mcp' or 'a2a' | |
| sortDirection | No | Sort direction (default: desc) | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description does not need to restate that. The description adds context about supported filtering (protocol, chain) and pagination behavior, which is consistent with the annotations. There is no contradiction.
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 concise, consisting of two sentences with no redundant information. Every part is useful and front-loaded with the core purpose.
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?
For a list tool with 6 parameters, no output schema, and clear annotations, the description adequately states the purpose and key features. It could be slightly improved by hinting at the response structure (e.g., an array of agents), but it is largely complete given the complexity.
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?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema provides for each parameter. It merely summarizes the filtering feature.
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 uses a specific verb 'Browse' and clearly identifies the resource as 'ERC-8004 registered AI agents'. It also lists key features (pagination, sorting, protocol/chain filtering) that distinguish it from siblings like erc8004_search_agents, which is implied to have different querying capabilities.
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 implies usage by stating the tool's capabilities but does not explicitly guide when to use this tool versus alternatives like erc8004_search_agents or erc8004_get_agent. No when-to-use or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse the agent's registration file and return typed service endpoints (MCP, A2A, ENS, DID).
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent's subgraph entity ID (e.g., '11155111:1213') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description adds the output types (service endpoints). However, no disclosure of behavior for missing/malformed registration files or other edge cases. Added value is modest beyond annotations.
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?
Single sentence with no waste, front-loaded with the core action and output. Efficient and clear.
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 the simplicity (1 param, no output schema, readOnlyHint annotation), the description is fairly complete. It covers what it does and what it returns. Could mention error handling or output format, but adequate.
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?
Schema descriptions cover 100% of the single parameter agentId. The tool description does not add extra meaning beyond the schema's example format. Baseline 3 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?
Description clearly states the action (parse/return), resource (agent's registration file), and output (typed service endpoints like MCP, A2A, ENS, DID). It distinguishes from sibling tools like erc8004_get_agent which returns general agent metadata.
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?
Implied by name and description for resolving agent service endpoints, but no explicit guidance on when to use vs alternatives like erc8004_get_agent or erc8004_get_agent_metadata. Lacks when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for ERC-8004 registered AI agents by name. Supports optional protocol and chain filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Filter by chain ID (e.g., '1' for mainnet, '137' for Polygon) | |
| limit | No | Maximum number of results to return (default: 20) | |
| query | Yes | Search query to match against agent names (case-insensitive) | |
| protocol | No | Filter by protocol support: 'mcp' or 'a2a' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds that it searches by name and supports filtering, which is sufficient for a read-only search tool. No additional behavioral details are needed.
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?
A single sentence that is perfectly concise and front-loaded. No unnecessary words, every part adds value.
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 output schema, the description is sufficient for a search tool: it specifies input parameters and purpose. It does not detail return format, but that is implicitly understood. Adequate for the context.
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?
Schema coverage is 100%, and each parameter has a clear description. The tool description adds little beyond what the schema already provides, just noting the optional filters. Thus, it meets the baseline without adding extra value.
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?
Clearly states it searches for ERC-8004 AI agents by name, with optional protocol and chain filtering. This differentiates it from siblings like erc8004_list_agents (lists all) and erc8004_get_agent (gets by ID).
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?
While it doesn't explicitly contrast with siblings, the description implies usage for name-based search. The name and description make it obvious when to use this tool (search by name) versus listing all or getting specific agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0erc8004_evaluate_agent_trusterc8004_get_agenterc8004_get_agent_feedbackerc8004_get_agent_metadataerc8004_get_agent_statserc8004_get_feedback_detailserc8004_get_reputation_summaryerc8004_get_validation_statuserc8004_list_agentserc8004_resolve_agent_serviceserc8004_search_agentsEach tool targets a distinct aspect of ERC-8004 agents: search, list, get details, feedback, stats, metadata, reputation, validation, services, and composite trust. No two tools have overlapping functionality.
All tools follow the pattern 'erc8004_verb_noun', with verbs like search, list, get, resolve, evaluate. Minor inconsistency: some use 'agent' singular (get_agent) while others use 'agents' plural (search_agents), but overall consistent.
11 tools is well-scoped for a registry information server. Each tool covers a necessary query function without redundancy, balancing breadth and depth.
The tool set comprehensively covers read operations for ERC-8004 agents: search, detail, feedback, stats, metadata, reputation, validation, services, and composite trust. No obvious gaps for querying agent information.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
On-chain ERC-8004 agent registry. Search, register, and check reputation across 16 chains.
Agent reputation registry: check, register, and endorse AI agents
Discover, search, invoke, and rate A2A (Agent-to-Agent) protocol agents.
Read-only gateway for durable agent identity, consent, recognized work, and signed receipts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wpank/erc-8004-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
