ChainFETCH MCP Server

Official

by chainfetch

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
The tools are organized by resource type (address, block, NFT, smart contract, token, transaction) and action (get_info, get_summary, search), which provides clear distinctions. However, the three search methods (JSON, LLM, semantic) for each resource create some potential confusion about which search tool to use for a given query, as their purposes overlap significantly despite different interfaces.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout: get_<resource>_info, get_<resource>_summary, search_<resource>_json, search_<resource>_llm, search_<resource>_semantic. The naming is systematic and predictable across all 26 tools, making it easy to understand the pattern and locate specific tools.
Tool Count2/5
With 26 tools, the count feels excessive for a blockchain data server. While the domain is broad, having three nearly identical search methods (JSON, LLM, semantic) for each of five resource types creates significant redundancy. A more streamlined approach with fewer overlapping tools would improve coherence without losing functionality.
Completeness5/5
The tool set provides comprehensive coverage for blockchain data exploration. Each major resource type (address, block, smart contract, token, transaction) has both detailed information retrieval and AI-generated summaries, plus multiple search approaches. The inclusion of NFT instance information adds additional domain coverage, creating a complete surface for blockchain data analysis.
Average 2.8/5 across 26 of 26 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description fails to mention that this is a read-only search operation, doesn't specify return format (though 'JSON' in name hints at it), doesn't mention rate limits, authentication requirements, or pagination behavior. The '50+ parameters' claim is factually incorrect given the schema shows only 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (one sentence), the description is under-specified and misleading rather than efficiently informative. The single sentence doesn't earn its place since it provides incorrect information about parameter count and fails to convey essential purpose. This is under-specification masquerading as conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is completely inadequate. It fails to explain what the tool returns, how results are structured, whether it's paginated, or any behavioral constraints. The misleading parameter count claim further undermines completeness. This leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 7 parameters. The description adds no meaningful parameter information beyond the misleading '50+ parameters' claim. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'JSON search for smart contracts with 50+ parameters' is tautological - it restates the tool name 'search_smart_contracts_json' and adds a misleading parameter count claim. It doesn't specify what action is performed (e.g., 'search and return smart contracts matching criteria') or distinguish it from sibling tools like search_smart_contracts_llm or search_smart_contracts_semantic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 search_smart_contracts_llm or search_smart_contracts_semantic. The description provides no context about appropriate use cases, prerequisites, or exclusions. The misleading '50+ parameters' claim could actually misguide usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description fails to disclose any behavioral traits such as read/write nature, rate limits, authentication needs, or what the search returns (e.g., JSON structure, pagination details). The mention of '120+ parameters' is misleading as the input schema only lists 10 parameters, creating confusion rather than transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is not front-loaded with useful information. It wastes space on the misleading '120+ parameters' claim instead of stating the tool's purpose clearly. While concise in length, it lacks effective structure and fails to convey essential details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It does not explain the search behavior, return format, or how parameters interact (e.g., filtering logic). The inaccuracy about parameter count further undermines completeness, leaving significant gaps for the agent to understand tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds no meaningful semantic information beyond what's in the schema. The mention of '120+ parameters' is inaccurate and does not compensate for or clarify the actual parameters. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'JSON search for blocks with 120+ parameters' is vague and tautological. It restates the tool name ('search_blocks_json') without specifying the action verb or resource clearly. While 'search' is implied, it doesn't distinguish this tool from sibling search tools like 'search_blocks_llm' or 'search_blocks_semantic' beyond the 'JSON' format mention, which is insufficient for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. Given the many sibling tools (e.g., 'search_blocks_llm', 'search_blocks_semantic', 'get_block_info'), the lack of usage guidelines leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what the output format is. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose. However, given the lack of detail and sibling context, it could be argued it's under-specified rather than concise, but it meets the criteria for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 required parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'NFT instance information' entails, how it differs from general token info, or what the return values might be. With no output schema and minimal behavioral context, this is inadequate for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (token and instance_id) documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get NFT instance information' clearly states the action (get) and resource (NFT instance information), which is adequate. However, it doesn't distinguish this tool from its many siblings (like get_token_info, get_smart_contract_info, etc.) by specifying what makes NFT instance information unique. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools (e.g., get_token_info, search_tokens_json), there's no indication of context, prerequisites, or exclusions. This leaves the agent to infer usage based on the tool name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'LLM-powered' and 'AI to select optimal parameters', which hints at AI-based processing, but doesn't disclose critical behavioral traits such as rate limits, authentication needs, error handling, or what 'optimal parameters' entails. This leaves significant gaps for an AI agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information ('LLM-powered token search'). It avoids redundancy and waste, though it could be slightly more structured by separating purpose from method. Overall, it's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (AI-powered search with no output schema and no annotations), the description is incomplete. It lacks details on output format, error cases, performance expectations, and how it differs behaviorally from sibling tools. Without annotations or output schema, the description should provide more context to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, providing a clear description ('Natural language query for token search'). The description adds minimal value beyond the schema by implying the query is processed with AI, but doesn't elaborate on format, examples, or constraints. With high schema coverage, the baseline is 3, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'LLM-powered token search' which indicates the verb (search) and resource (tokens), but it's vague about what 'token search' means in this context (e.g., searching token metadata, transactions, holders). It distinguishes from siblings by mentioning 'LLM-powered' and 'AI to select optimal parameters', but doesn't clearly differentiate from other token search tools like 'search_tokens_json' or 'search_tokens_semantic' beyond the AI aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'LLM-powered' and 'AI to select optimal parameters', which implies usage for natural language queries, but doesn't specify scenarios, prerequisites, or exclusions compared to other token search tools like 'search_tokens_json' or 'search_tokens_semantic'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but discloses minimal behavioral traits. It mentions the output is 'AI-generated', which adds some context about the nature of the summary, but lacks details on permissions, rate limits, response format, or potential errors. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the summary contains, how it's formatted, or any limitations (e.g., token types supported). For a tool with no structured output documentation, this leaves significant gaps for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 100% coverage for the single parameter 'token_address'. The schema's description already explains it as 'The token address hash to get summary for', so the tool description provides no additional parameter context, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves an AI-generated summary for a token, which is a clear purpose but lacks specificity. It doesn't distinguish from sibling tools like 'get_token_info' or 'get_address_summary', leaving ambiguity about what makes this summary unique or how it differs from other summary tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools available (e.g., get_token_info, search_tokens_llm), the description offers no context, prerequisites, or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'AI-generated summary' which hints at potential latency or non-deterministic output, but doesn't disclose behavioral traits like rate limits, authentication needs, or what the summary includes (e.g., format, length). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the AI-generated summary contains, its format, or any limitations. For a tool that likely returns complex, unstructured data, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the 'address_hash' parameter. The description adds no additional meaning beyond implying it's for a 'specific address', which aligns with the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('AI-generated summary for a specific address'), making the purpose understandable. It distinguishes from siblings like 'get_address_info' by specifying 'summary' rather than 'info', though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_address_info' or the various search tools. The description implies usage for a specific address but offers no context about prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't address important behavioral aspects like whether this requires authentication, rate limits, what format the detailed information returns, or potential error conditions for invalid block numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, how it differs from 'get_block_summary', what format the response takes, or any behavioral constraints. Given the complexity implied by sibling tools and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'block' clearly documented as 'The block number to get info for'. The description doesn't add any additional parameter semantics beyond what's already in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific block'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_block_summary' - both appear to retrieve block information but with different detail levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_block_summary' and multiple search tools for blocks, there's no indication of when detailed block information is needed versus summary information or search functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'AI-generated summary' but doesn't explain what that entails (e.g., format, length, potential inaccuracies, rate limits, or authentication needs). This leaves significant gaps in understanding how the tool behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of AI-generated content and lack of annotations or output schema, the description is incomplete. It doesn't address key aspects like output format, potential errors, or how it differs from other block tools, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'block_number' well-documented in the schema. The description doesn't add any meaning beyond this (e.g., format examples like hex or decimal, valid ranges), so it meets the baseline for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('AI-generated summary for a specific block'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_block_info' or 'search_blocks_llm', which might also provide block-related information but with different outputs or methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'get_block_info', 'search_blocks_llm'), there's no indication of when this AI-generated summary is preferred over other block-related queries, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't address important behavioral aspects: whether this requires authentication, rate limits, what format the 'detailed information' returns, error conditions, or whether it's a real-time query versus cached data. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple tool with one parameter and follows good front-loading by immediately stating the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should do more to compensate. For a tool that presumably returns complex smart contract data, the description doesn't indicate what 'detailed information' includes, the response format, or any behavioral constraints. With no structured output documentation and multiple similar sibling tools, this leaves the agent with insufficient context for optimal tool selection and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with the 'address' parameter clearly documented as 'The smart contract address'. The description doesn't add any additional parameter semantics beyond what the schema provides - it doesn't clarify address format requirements, validation rules, or examples. With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific smart contract'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_smart_contract_summary' - both appear to retrieve smart contract information, so the differentiation between 'detailed information' and 'summary' is implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. With multiple sibling tools for smart contracts (get_smart_contract_summary, search_smart_contracts_json/llm/semantic), there's no indication of when 'detailed information' is preferred over a 'summary' or when to use search tools instead. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'AI-generated summary' but doesn't specify what that entails (e.g., content, length, reliability), whether it's read-only, or if there are rate limits or authentication needs. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to grasp quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of smart contract analysis and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the summary includes, how it's generated, or what the output looks like, which are critical for an AI agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'address' well-documented in the schema. The description doesn't add any extra meaning beyond what the schema provides, such as address format examples or constraints, so it meets the baseline for high coverage without compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get AI-generated summary') and resource ('for a specific smart contract'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from its sibling 'get_smart_contract_info' or other summary tools, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_smart_contract_info' or other summary tools in the sibling list. It lacks context about prerequisites, such as whether the address must be verified or what format it expects, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify what constitutes 'detailed information', whether there are rate limits, authentication requirements, or what format the information returns. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. For a tool that presumably returns structured token data, the description doesn't hint at what information is included, whether there are common use cases, or how this differs from the summary version. The context signals show this is a simple single-parameter tool, but the description doesn't provide enough guidance for optimal agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with the single parameter 'token' clearly documented as 'The token address hash'. The description adds no additional parameter semantics beyond what's already in the schema. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and target resource ('about a specific token'), making the purpose immediately understandable. It distinguishes from summary tools like 'get_token_summary' by specifying 'detailed information', but doesn't explicitly contrast with other token-related tools like 'search_tokens_json' or 'get_nft_instance_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools including 'get_token_summary' and various search tools, there's no indication of when detailed token information is preferred over summaries or search results, nor any mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't mention any behavioral traits like rate limits, authentication requirements, error conditions, or what 'detailed information' entails (e.g., format, fields included). This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., fields, structure), how results are returned, or any operational constraints. For a tool with no structured output definition, this leaves the agent with insufficient context to handle the response effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage for the single parameter 'transaction' (described as 'The transaction hash to get info for'). Since schema coverage is high, the baseline is 3, and the description doesn't compensate with additional context like hash format examples or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific transaction'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_transaction_summary' or 'search_transactions_json', leaving ambiguity about when to choose this specific tool over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., get_transaction_summary, search_transactions_json), there's no indication of when this detailed info tool is preferred over summary or search tools, or what distinguishes it from them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool 'Get[s] AI-generated summary', implying a read-only operation that might involve AI processing, but doesn't disclose behavioral traits such as rate limits, authentication needs, response format, or potential errors. This leaves significant gaps for an AI agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that generates AI summaries (implying potential processing nuances) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the summary contains, how it's formatted, or any behavioral aspects like latency or errors, leaving the AI agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'transaction_hash' clearly documented. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'AI-generated summary for a specific transaction', which is specific and actionable. However, it doesn't distinguish itself from sibling tools like 'get_transaction_info' or 'search_transactions_*', leaving some ambiguity about when to use this versus those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_transaction_info' or the various search tools. It mentions 'specific transaction' but doesn't clarify if this is for summarized vs. detailed views or how it differs from other transaction-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'LLM-powered' and 'intelligently select from 150+ parameters', which hints at AI-driven behavior, but lacks critical details: it doesn't specify what the 150+ parameters are, how the LLM interprets queries, potential limitations (e.g., accuracy, latency), or output format. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information: 'LLM-powered address search' and the model used. It avoids redundancy, though it could be slightly more structured by explicitly stating the tool's primary function first (e.g., 'Search addresses using natural language queries via LLaMA 3.2 3B').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with good schema coverage, the description is incomplete. It lacks details on output (e.g., what data is returned, format), behavioral traits (e.g., how the LLM works, error handling), and clear differentiation from siblings. For an LLM-based tool in a complex sibling set, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'query', which is documented as 'Natural language query for address search'. The description adds that it's 'LLM-powered' and uses '150+ parameters', implying the query is processed intelligently, but doesn't provide additional syntax, examples, or constraints beyond what the schema states. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'address search' with 'LLM-powered' capability, specifying it uses 'LLaMA 3.2 3B' to 'intelligently select from 150+ parameters'. This distinguishes it from non-LLM search tools like 'search_addresses_json' and 'search_addresses_semantic', though it doesn't explicitly contrast with those siblings beyond mentioning the LLM approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'LLM-powered' and 'intelligently select from 150+ parameters', which implies it might handle complex or ambiguous queries better than non-LLM tools, but there's no explicit when/when-not advice or named alternatives like 'search_addresses_json' for structured queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the search method. It doesn't disclose behavioral traits like whether this is read-only (implied but not stated), performance characteristics, rate limits, authentication needs, or what the output looks like (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded with the core purpose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what constitutes a 'semantic' match, how results are ranked, what fields are returned, or error conditions. Given the complexity of semantic search and lack of structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., query format examples, limit constraints). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('semantic search') and resource ('Ethereum addresses'), and specifies the method ('AI-powered vector similarity matching'). It distinguishes from non-search siblings but doesn't explicitly differentiate from other search_addresses_* tools like search_addresses_json or search_addresses_llm, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_addresses_json or search_addresses_llm. The description mentions the method but doesn't explain when semantic search is preferable over other search types or direct lookup tools like get_address_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the LLM model and parameter count (120+), but doesn't disclose important behavioral traits like rate limits, authentication requirements, response format, error conditions, or what 'select from 120+ parameters' actually means in practice. The description is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core functionality. It's appropriately sized for a search tool, though it could be slightly more front-loaded by starting with the primary action rather than the implementation detail (LLM-powered).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what kind of results to expect, how results are formatted, whether there's pagination, or what the '120+ parameters' refers to. The agent lacks sufficient context to understand the tool's full behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single 'query' parameter well-described in the schema. The description adds minimal value beyond the schema by mentioning 'natural language query' is used, but doesn't provide additional context about query formatting, examples, or limitations. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'LLM-powered block search' using a specific model (LLaMA 3.2 3B), which is a specific verb+resource combination. It distinguishes from sibling tools by specifying the search method (LLM) and target (blocks), though it doesn't explicitly differentiate from other block search tools like search_blocks_json or search_blocks_semantic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling search tools (json, semantic, llm variants for different resources), there's no indication of when LLM-powered search is preferred over other search methods or what specific advantages it offers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the AI-powered nature and parameter selection capability, but doesn't describe what the search returns, how results are formatted, whether there are rate limits, authentication requirements, or any other operational characteristics. For a search tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality without any wasted words. It's front-loaded with the most important information and every element (LLM-powered, smart contract search, AI parameter selection) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an LLM-powered search tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what kind of results to expect, how they're structured, what the '150+ parameters' actually are, or how this differs operationally from other search methods. For a tool in a crowded namespace with many alternatives, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with the single 'query' parameter well-documented in the schema. The description adds that this is a 'natural language query' and mentions '150+ parameters' the AI can select from, providing some additional context about the query's nature and the search's capabilities beyond the basic schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'LLM-powered smart contract search using AI to select from 150+ parameters', which includes a specific verb ('search'), resource ('smart contracts'), and method ('LLM-powered'). It distinguishes from non-LLM siblings like 'search_smart_contracts_json' and 'search_smart_contracts_semantic', but doesn't explicitly differentiate from other LLM search tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this LLM-powered search over JSON or semantic search methods for smart contracts, nor does it specify any prerequisites or contextual factors that would make this the preferred choice among the many sibling search tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions 'AI-powered vector similarity matching' which hints at the search methodology, but doesn't describe what the tool returns, performance characteristics, limitations, or any side effects. For a search tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what results look like, how semantic matching works in practice, or any limitations. Given the complexity implied by 'AI-powered vector similarity' and lack of structured documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (query and limit with default). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('semantic search') and resource ('smart contracts'), and mentions the method ('AI-powered vector similarity matching'). It distinguishes from non-search siblings but doesn't explicitly differentiate from other smart contract search tools (json, llm variants).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_smart_contracts_json or search_smart_contracts_llm. It doesn't mention use cases, prerequisites, or when semantic search is preferable to other search methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'comprehensive search parameters' but doesn't describe what the tool actually returns (format, structure, fields), whether it's paginated beyond the limit/offset parameters, rate limits, authentication requirements, or error conditions. This leaves significant behavioral gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality. While it could be more front-loaded with critical information, there's no wasted verbiage or redundancy. Every word serves a purpose in conveying the tool's basic nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 8 parameters and no output schema, the description is insufficient. It doesn't explain what format the JSON results take, what fields are returned, how results are ordered, or what happens when no matches are found. With no annotations and no output schema, users have no visibility into the tool's behavior beyond the input parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'comprehensive search parameters' which aligns with the 8 parameters in the schema, but adds no specific semantic information beyond what's already documented in the schema (which has 100% coverage). The baseline of 3 is appropriate since the schema does the heavy lifting, though the description doesn't compensate with additional context about parameter interactions or search logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'JSON search for tokens' with 'comprehensive search parameters', which specifies the verb (search), resource (tokens), and format (JSON). However, it doesn't explicitly differentiate from sibling tools like search_tokens_llm or search_tokens_semantic, which appear to be alternative search methods for the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for searching tokens (search_tokens_llm, search_tokens_semantic), there's no indication of when JSON search is preferred over LLM or semantic search approaches, nor any mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search method but doesn't cover critical aspects like whether this is a read-only operation, performance characteristics, rate limits, authentication needs, or what the output looks like. For a search tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the essential information without unnecessary words. It's appropriately sized for a search tool and front-loads the key information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of semantic search and the lack of both annotations and output schema, the description is insufficient. It doesn't explain what 'tokens' refers to in this context, what format results are returned in, how similarity is measured, or any limitations of the semantic search approach. For a tool with no structured behavioral information, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (query and limit). The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('semantic search') and resource ('tokens'), and specifies the method ('AI-powered vector similarity matching'), which distinguishes it from non-semantic search tools. However, it doesn't explicitly differentiate from sibling tools like search_tokens_json or search_tokens_llm, which likely use different search methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_tokens_json or search_tokens_llm. It mentions the search method but doesn't explain when semantic search is preferable over other approaches, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'JSON search' and '254+ carefully curated parameters', which hints at a structured, parameter-rich search, but doesn't disclose critical behavioral traits like whether this is a read-only operation, performance characteristics, rate limits, authentication needs, or what the output format looks like. For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It could be slightly improved by front-loading more critical information, but it's appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the return format (only mentions 'JSON search' vaguely), doesn't clarify the relationship between the 11 shown parameters and the '254+ curated parameters', and provides no behavioral context. For a search tool with rich parameters, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds minimal value by mentioning '254+ carefully curated parameters' (implying many more than the 11 shown), but doesn't provide specifics about those additional parameters or how to access them. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'JSON search for transactions' with a specific scope of '254+ carefully curated parameters', which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its siblings (search_transactions_llm, search_transactions_semantic) beyond the 'JSON' format mention, which is why it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_transactions_llm or search_transactions_semantic. It mentions '254+ carefully curated parameters' which might imply this is for detailed filtering, but this is not explicit usage guidance. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the LLM model and parameter count but doesn't describe what the search returns, how results are formatted, whether there are rate limits, authentication requirements, or any constraints on the natural language query. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information (LLM-powered transaction search) and includes relevant details (model, parameter count) without unnecessary words. Every element earns its place by clarifying the tool's unique approach.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an LLM-powered search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns, how to interpret results, or any limitations (e.g., accuracy, speed). For a tool that likely processes complex queries, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'query' documented as 'Natural language query for transaction search'. The description adds context by mentioning '254 parameters' (likely referring to searchable fields) and the LLM model, which provides some additional meaning beyond the schema. However, it doesn't elaborate on query syntax or examples, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'LLM-powered transaction search' using a specific model (LLaMA 3.2 3B), which provides a specific verb ('search') and resource ('transactions'). It distinguishes itself from siblings like 'search_transactions_json' and 'search_transactions_semantic' by specifying the LLM-powered approach, though it doesn't explicitly contrast with all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions '254 parameters' but doesn't explain if this is an advantage over other search methods or when LLM-powered search is preferable to JSON or semantic approaches. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the search method without disclosing behavioral traits. It doesn't mention performance characteristics, rate limits, authentication needs, result format, or whether it's read-only (though implied). For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without waste. It's appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a search tool. It doesn't explain what the results look like, how similarity is measured, or any limitations. With rich sibling tools and complex search functionality, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (query and limit). The description adds no additional parameter semantics beyond what's in the schema, such as query format examples or limit constraints. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('semantic search') and resource ('transactions'), and specifies the method ('AI-powered vector similarity matching'), which distinguishes it from simple keyword search. However, it doesn't explicitly differentiate from sibling tools like search_transactions_json or search_transactions_llm, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_transactions_json or search_transactions_llm. It mentions the method but doesn't explain when semantic search is preferable to other search types, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'detailed information' but doesn't specify what that includes (e.g., balance, transaction history, contract interactions), nor does it cover aspects like rate limits, authentication needs, or error handling, leaving significant gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing essential information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on return values, error cases, or behavioral traits, which are needed for full contextual understanding, especially with no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'address' documented as 'The address hash to get info for'. The description adds no additional meaning beyond this, such as format requirements (e.g., checksum, prefix) or examples, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific Ethereum address'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_address_summary' or 'get_address_info' alternatives, which would require specifying what 'detailed information' entails compared to a summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'get_address_summary' and various search tools, it lacks explicit when-to-use or when-not-to-use instructions, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions '150+ parameters for comprehensive filtering' which hints at complexity, but fails to describe critical behaviors such as pagination mechanics (implied by offset/limit in schema but not explained), rate limits, authentication requirements, or what the search returns. For a search tool with many parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information (JSON search, addresses, 150+ parameters). It avoids redundancy but could be slightly more structured by explicitly mentioning the tool's output or context. Overall, it's appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by '150+ parameters' and the lack of annotations and output schema, the description is incomplete. It doesn't explain the return format, error handling, or how to interpret results, which are crucial for a search tool. The schema covers the 9 listed parameters well, but the description fails to address the broader context needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds minimal value beyond the schema by mentioning '150+ parameters for comprehensive filtering', which suggests broader parameter availability than shown in the schema but doesn't clarify semantics for the undocumented parameters. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'JSON search for addresses' with 'comprehensive filtering', which specifies the verb (search), resource (addresses), and scope (JSON format, 150+ parameters). It distinguishes from siblings like get_address_info by emphasizing search functionality, though it doesn't explicitly contrast with search_addresses_llm or search_addresses_semantic beyond the JSON format mention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comprehensive filtering via JSON, suggesting it's appropriate when detailed parameter control is needed. However, it lacks explicit guidance on when to choose this tool over alternatives like search_addresses_llm or search_addresses_semantic, and doesn't mention prerequisites or exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'AI-powered vector similarity matching', which hints at the underlying technology, but fails to disclose critical behavioral traits such as performance characteristics (e.g., speed, accuracy), rate limits, authentication needs, or what the output looks like (since there's no output schema). This leaves significant gaps for an agent to understand how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information ('Semantic search for blocks') and adds necessary detail ('using AI-powered vector similarity matching') without any wasted words. It's appropriately sized for the tool's complexity and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a semantic search tool with no annotations and no output schema, the description is insufficient. It lacks details on output format, error handling, performance expectations, or how results are ranked/returned. While it covers the basic purpose, it doesn't provide enough context for an agent to fully understand the tool's operation and limitations in this server environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'query' and 'limit' parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain query formatting, semantic nuances, or limit implications). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('semantic search') and resource ('blocks'), and specifies the method ('AI-powered vector similarity matching'). It distinguishes from non-semantic search siblings like 'search_blocks_json' and 'search_blocks_llm' by highlighting the semantic/vector approach. However, it doesn't explicitly contrast with all sibling tools like the various 'get_' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for semantic/vector-based searches on blocks, suggesting it should be chosen over non-semantic alternatives like 'search_blocks_json' or 'search_blocks_llm'. However, it lacks explicit guidance on when to prefer this tool versus other block-related tools (e.g., 'get_block_info' for direct lookup) or when not to use it, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![chainfetch-mcp-server MCP server](https://glama.ai/mcp/servers/chainfetch/chainfetch-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/chainfetch/chainfetch-mcp-server)

Score Badge

Copy to your README.md:

[![chainfetch-mcp-server MCP server](https://glama.ai/mcp/servers/chainfetch/chainfetch-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/chainfetch/chainfetch-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chainfetch/chainfetch-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server