Moralis MCP Server

Official

by MoralisWeb3

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools are organized into clear categories (EVM and Solana) with distinct purposes within each, such as block data, token analytics, NFT operations, and wallet queries. However, there is significant overlap in functionality, especially between similar tools like evm_getmultipletokenanalytics and evm_gettimeseriestokenanalytics, or multiple NFT-related tools that could cause confusion in selection without careful reading of descriptions.
Naming Consistency5/5
The naming follows a highly consistent pattern throughout, using a clear prefix (evm_ or solana_) followed by a descriptive verb_noun format (e.g., evm_getblock, solana_getportfolio). This consistency makes it easy to predict tool purposes and navigate the large set without ambiguity in naming conventions.
Tool Count2/5
With 94 tools, the count is excessive for a single server, making it overwhelming and difficult for agents to manage effectively. While the tools cover a broad blockchain domain, the sheer volume suggests poor scoping, as many tools could be consolidated or split into more focused servers to improve usability.
Completeness5/5
The tool set provides comprehensive coverage for blockchain data, including blocks, tokens, NFTs, wallets, swaps, and analytics across EVM and Solana chains. It supports full CRUD-like operations for querying, analyzing, and monitoring, with no apparent gaps that would hinder agent workflows in this domain.
Average 3.1/5 across 94 of 94 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 but offers minimal insight. 'Get all snipers' implies a read-only operation but doesn't clarify what 'snipers' entails, potential rate limits, authentication needs, or response format. The description fails to compensate for the lack of annotations, leaving critical behavioral traits undefined.
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 extremely concise ('Get all snipers.'), which is efficient but borders on under-specification. It's front-loaded but lacks substance; every word earns its place, yet more detail is needed for clarity. The brevity is a strength in structure but a weakness in informativeness.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'snipers' are, the tool's purpose, usage context, or expected outputs. For a tool with moderate parameter count and no structured support, this leaves significant gaps in understanding.
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 67%, with two parameters well-described ('network' and 'pairAddress') and one undocumented ('blocksAfterCreation'). The description adds no parameter semantics beyond the schema, not explaining what 'blocksAfterCreation' means or how parameters interact. Given the partial coverage, the baseline score reflects that the schema does some work, but the description doesn't enhance understanding.
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 'Get all snipers' is a tautology that merely restates the tool name without providing meaningful context. It doesn't specify what 'snipers' are in this context (likely automated trading bots or similar), what resource is being accessed, or how this differs from sibling tools like 'evm_getsnipersbypairaddress' or other Solana tools.
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 about when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison to sibling tools (e.g., 'solana_getswapsbypairaddress' or 'evm_getsnipersbypairaddress'), leaving the agent with no information to make an informed 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. It only states the action ('Get the summary') without explaining what 'summary' includes (e.g., count, distribution, top holders), whether it's read-only, performance characteristics, or error handling. For a tool with no annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose, but it includes redundant phrasing ('token token') and lacks efficiency. It could be more concise (e.g., 'Get holder summary for a Solana token') without losing clarity, but it's not overly verbose.
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 vague description, the tool is incomplete for effective use. The description doesn't clarify what 'summary' means, how results are structured, or limitations, making it inadequate for an agent to understand the tool's behavior fully. This is particularly problematic for a data-fetching tool with siblings.
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 clear descriptions for both parameters ('network' and 'address'). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get the summary of holders for a given token') with a clear verb ('Get') and resource ('holders'), but it's vague about what 'summary' entails and doesn't differentiate from sibling tools like 'solana_gethistoricaltokenholders' or 'solana_gettopholders'. The phrasing 'token token' is redundant and slightly confusing.
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. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name and parameters alone. This is a significant gap for a tool with siblings that handle similar data.
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 vaguely mentions 'showcasing their unique attributes' but doesn't specify the output format, whether it returns a list, summary, or detailed breakdown, or any limitations like rate limits or data freshness. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 states the purpose without unnecessary words. It is front-loaded with the main action ('explore') and resource ('distinct traits of NFTs in a contract'). However, it could be slightly more specific to improve clarity without losing 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 of querying NFT traits with no annotations and no output schema, the description is incomplete. It lacks details on what the tool returns, such as the structure of traits data, any pagination or limits, and error handling. For a tool with two parameters and likely rich output, this minimal description does not provide enough context 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?
The schema description coverage is 100%, with clear descriptions for both parameters: 'chain' as 'The chain to query' and 'address' as 'The address of the NFT contract'. The description adds no additional meaning beyond this, such as examples or constraints on the address format. Given the high schema coverage, a baseline score of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose is to 'explore the distinct traits of NFTs in a contract' which is clear but vague. It uses 'explore' rather than a specific verb like 'retrieve' or 'list', and while it mentions 'unique attributes', it doesn't specify what kind of traits or how they are presented. It distinguishes from some siblings like evm_getnftcollectionstats by focusing on traits, but not clearly from evm_getnftbycontracttraits which seems similar.
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 prerequisites, such as needing a valid NFT contract address, or compare it to sibling tools like evm_getnftbycontracttraits or evm_getnftcollectionstats. Without this, an agent might struggle to select the appropriate tool for querying NFT traits.
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 states it's a read operation ('Get'), implying no destructive effects, but fails to mention pagination behavior (cursor and limit parameters), rate limits, authentication requirements, or what the output format looks like. This leaves significant gaps in understanding how the tool behaves.
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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, though it could be slightly more informative without losing 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?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'graduated tokens' are, how results are structured, or provide usage context. This leaves the agent with insufficient information to use the tool effectively beyond basic parameter passing.
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 75%, with three of four parameters having descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as clarifying what 'exchange' refers to or how 'graduated tokens' relate to the parameters. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema does most of the work.
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 the list of graduated tokens by given exchange' clearly states the verb ('Get') and resource ('graduated tokens'), but it's somewhat vague about what 'graduated tokens' means in this context. It doesn't differentiate from sibling tools like 'solana_getnewtokensbyexchange' or 'solana_getbondingtokensbyexchange', leaving ambiguity about the specific type of tokens being retrieved.
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. The description doesn't mention prerequisites, such as what constitutes a valid exchange parameter, or contrast it with similar tools like 'solana_getnewtokensbyexchange' for new tokens or 'solana_getbondingtokensbyexchange' for bonding tokens.
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 'get' (implying read-only) but doesn't disclose behavioral traits like rate limits, authentication needs, pagination behavior (cursor usage), data freshness, or error conditions. The description is too minimal to inform the agent adequately about operational constraints.
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, compact sentence that directly states the tool's function. It's front-loaded with the core purpose, though the grammatical issues slightly reduce clarity. There's no wasted verbiage, making it efficient in length.
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 (7 parameters, historical data query) and lack of annotations and output schema, the description is insufficient. It doesn't explain the return format (e.g., time-series data structure), pagination via 'cursor', or how 'timeFrame' interacts with date ranges. For a historical query tool with no structured output info, 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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying historical data retrieval (hinted by 'overtime'), which aligns with parameters like 'timeFrame', 'fromDate', and 'toDate'. Baseline score of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get token holders overtime for a given tokens' states the purpose (retrieving historical token holders) but is grammatically awkward ('overtime' should be 'over time', 'tokens' is plural where singular might be intended). It distinguishes from siblings like 'solana_gettokenholders' (likely current holders) by implying historical data, but this distinction isn't explicitly stated.
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. For example, it doesn't clarify when to choose this over 'solana_gettokenholders' (presumably for current holders) or 'evm_gethistoricaltokenholders' (for EVM chains). The description alone offers no usage context or prerequisites.
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 only states what the tool does ('Get the token bonding status') without describing what 'bonding status' means, what format the response takes, whether this is a read-only operation, potential rate limits, or error conditions. 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.
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's appropriately sized for a simple query tool, though it could be slightly more informative without sacrificing 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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'token bonding status' means in practical terms, what data structure to expect in response, or how this differs from similar sibling tools. The agent would struggle to understand when and how 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?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds minimal value beyond the schema by mentioning 'network and contract (if relevant)', which loosely maps to the 'network' and 'address' parameters. However, it doesn't clarify what 'contract (if relevant)' means or provide additional context about parameter usage.
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's purpose as 'Get the token bonding status', which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'solana_getbondingtokensbyexchange' or 'solana_getgraduatedtokensbyexchange', leaving ambiguity about what specifically differentiates this tool. The phrase 'for a given network and contract (if relevant)' adds some context but doesn't fully clarify the scope.
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 network and contract parameters but doesn't explain what scenarios require this tool over similar siblings like 'solana_getbondingtokensbyexchange'. There's no mention of prerequisites, limitations, 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 'Gets' which implies a read operation, but doesn't cover critical aspects like rate limits, authentication needs, pagination behavior (hinted by 'cursor' parameter), or what happens if parameters are invalid. This is a significant gap for a tool with 8 parameters and 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, front-loading the core purpose. It's appropriately sized for a tool with a straightforward name, though it could benefit from more detail given the complexity implied by the parameters.
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 (8 parameters, 6 required, no output schema, and no annotations), the description is incomplete. It doesn't explain the return format, error handling, or behavioral traits, leaving the agent with insufficient information to use the tool effectively beyond basic parameter input.
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 semantics beyond the input schema, which has 100% coverage with detailed descriptions for all 8 parameters. The baseline is 3 because the schema does all the heavy lifting, but the description doesn't compensate with any additional context, such as explaining the relationship between parameters like 'address' and 'pair address'.
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 'Gets the candlesticks for a specific pair address' clearly states the verb ('Gets') and resource ('candlesticks'), but it's vague about what 'candlesticks' are (likely financial chart data) and doesn't distinguish from sibling tools like 'solana_getpairstats' or 'evm_getpaircandlesticks', which might serve similar purposes. It's adequate but lacks specificity.
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, such as other candlestick-related tools in the sibling list (e.g., 'evm_getpaircandlesticks'). It only states what it does, without context or exclusions, leaving the agent to infer usage based on the tool 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 states it's a read operation ('Get'), implying it's non-destructive, but doesn't disclose behavioral traits like rate limits, authentication needs, pagination behavior (implied by cursor/limit parameters), or what the output format looks like (no output schema). This leaves significant gaps for a tool with pagination parameters.
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 front-loaded and appropriately sized for the tool's purpose, 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 (4 parameters, pagination via cursor/limit), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values, pagination behavior, or clarify the 'exchange' parameter, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.
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 75%, with three parameters (network, cursor, limit) having descriptions, while 'exchange' lacks one. The description adds no additional meaning beyond the schema, as it doesn't clarify what 'exchange' refers to (e.g., exchange name or identifier) or provide examples. With high schema coverage, the baseline is 3, but the description doesn't compensate for the undocumented 'exchange' parameter.
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 the list of new tokens by given exchange' clearly states the action (get/list) and resource (new tokens), but it's vague about what 'new tokens' means (e.g., recently listed, newly created). It distinguishes from siblings like 'solana_getgraduatedtokensbyexchange' by focusing on 'new' tokens, but lacks specificity on the criteria for 'new'.
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. It doesn't mention prerequisites, such as needing a specific exchange identifier, or compare it to similar tools like 'solana_getgraduatedtokensbyexchange' or 'solana_getbondingtokensbyexchange' for context on token types.
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 states a read operation ('Get'), which implies safety, but doesn't disclose behavioral traits such as rate limits, data freshness, pagination, or response format. 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 sentence that efficiently conveys the core purpose without waste. It's appropriately sized for a no-parameter tool, though it could be slightly more specific (e.g., mentioning data source or limit). Structure is front-loaded but minimal.
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 0 parameters, the description is incomplete. It lacks details on what 'top' means (e.g., number of results, time frame), data source, or return format. For a tool that likely returns a list of cryptocurrencies, 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs.
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 cryptocurrencies by their market cap' clearly states the verb ('Get') and resource ('cryptocurrencies'), but it's somewhat vague about scope and doesn't distinguish from siblings like 'evm_gettoperc20tokensbymarketcap' or 'evm_gettopcryptocurrenciesbytradingvolume'. It specifies the ranking criterion (market cap) but lacks detail about what 'top' means or the data source.
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 siblings like 'evm_gettopcryptocurrenciesbytradingvolume' and 'evm_gettoperc20tokensbymarketcap', the description doesn't clarify if this includes all cryptocurrencies or specific types, or how it differs from other market cap tools. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool retrieves block contents but lacks details on permissions, rate limits, error handling, or response format. For a read operation in a blockchain context, this is a significant gap, as it doesn't explain what 'contents' includes (e.g., transactions, timestamps) or any constraints, making it minimally transparent.
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: 'Get the contents of a block given the block hash.' It is front-loaded with the core action and input, with zero wasted words. This makes it highly concise and well-structured for quick understanding, earning a top score.
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 (blockchain data retrieval), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., JSON structure), error cases, or behavioral traits like rate limits. While the schema covers inputs well, the overall context for safe and effective use is insufficient, especially for a tool with potential nuances in blockchain queries.
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%, meaning the schema already documents all parameters ('chain', 'block_number_or_hash', 'include') with descriptions and enums. The description adds no additional meaning beyond implying the use of a block hash, which is partially covered in the schema. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
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: 'Get the contents of a block given the block hash.' This specifies the verb ('Get'), resource ('contents of a block'), and key input ('block hash'). It distinguishes from siblings like 'evm_getlatestblocknumber' (which gets only the number) and 'evm_gettransactionverbose' (which focuses on transactions). However, it doesn't explicitly differentiate from all siblings, such as those fetching token or NFT data, though the focus on blocks is inherently distinct.
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 prerequisites (e.g., needing a valid block identifier), exclusions (e.g., not for real-time data), or direct alternatives among siblings. For example, it doesn't clarify if 'evm_getlatestblocknumber' should be used first to obtain a block number, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds the 'closest block' but does not explain how 'closest' is determined (e.g., tolerance, algorithm), potential errors (e.g., invalid dates, chain unavailability), or performance aspects like rate limits. For a query tool with no 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: 'Find the closest block to a specific date on a blockchain.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for a simple query tool. Every word earns its place by clearly conveying the tool's 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 tool's complexity (a date-to-block mapping query), lack of annotations, and no output schema, the description is incomplete. It does not explain the return format (e.g., block number, timestamp, confidence), error handling, or how 'closest' is computed. For a tool with no structured behavioral or output data, the description should provide more context to be fully helpful.
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 ('chain' and 'date') well-documented in the schema. The description adds no additional meaning beyond implying the 'date' parameter is used for proximity matching. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not compensate but also does not 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 tool's purpose: 'Find the closest block to a specific date on a blockchain.' It uses specific verbs ('find') and resources ('block', 'date', 'blockchain'), but does not explicitly differentiate from siblings like 'evm_getblock' or 'evm_getlatestblocknumber', which handle block retrieval by number or latest status rather than date proximity.
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 does not mention prerequisites, such as needing a date input, or compare it to siblings like 'evm_getblock' (for block-by-number queries) or 'evm_getlatestblocknumber' (for current block). Without this context, an agent might misuse it when other tools are more appropriate.
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 states the tool fetches data, implying a read-only operation, but does not specify whether it requires authentication, has rate limits, returns paginated results, or details the format of 'detailed DeFi positions'. This leaves significant gaps in understanding the tool's behavior and constraints.
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 redundant information. It is front-loaded and appropriately sized, making it easy to understand quickly with zero waste.
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 DeFi positions and the lack of annotations and output schema, the description is insufficient. It does not explain what 'detailed DeFi positions' include, how data is structured, or any behavioral traits like error handling or data freshness. This leaves the agent with incomplete context for effective tool invocation.
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 clear parameter descriptions and enums, so the baseline score is 3. The description adds minimal value by mentioning 'wallet and protocol', which aligns with the schema but does not provide additional semantic context or usage examples beyond what is already documented in the structured fields.
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 ('Fetch detailed DeFi positions') and specifies the target resources ('for a given wallet and protocol'), making the purpose unambiguous. However, it does not explicitly differentiate from its sibling 'evm_getdefipositionssummary', which might provide a summary instead of detailed positions, leaving room for improvement in sibling distinction.
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, such as 'evm_getdefipositionssummary' or other DeFi-related tools in the sibling list. It lacks explicit context, prerequisites, or exclusions, offering minimal usage direction beyond the basic parameters.
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 what the tool returns (summary of DeFi activity) but lacks behavioral details such as whether it's a read-only operation, any rate limits, authentication requirements, data freshness, or error conditions. For a tool querying financial data with no annotation coverage, this is a significant gap.
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 the core purpose and key outputs. There is zero waste, and every word earns its place by specifying the action, target, and included metrics.
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 DeFi activity summarization, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, data sources, limitations, or how 'active protocols' are determined. For a tool with two parameters and significant sibling overlap, 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%, with clear descriptions for both parameters ('chain' and 'address'). The description adds no additional parameter semantics beyond what the schema provides, such as format details for 'address' or implications of chain selection. 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's purpose: 'Summarize a wallet’s DeFi activity, including total USD value, unclaimed rewards and active protocols.' It specifies the verb ('Summarize'), resource ('wallet’s DeFi activity'), and key outputs. However, it doesn't explicitly differentiate from sibling tools like 'evm_getdefipositionssummary' or 'evm_getwalletnetworth', which might provide overlapping or related data.
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 related to wallet analysis (e.g., 'evm_getdefipositionssummary', 'evm_getwalletnetworth', 'evm_getwalletstats'), there's no indication of context, prerequisites, or exclusions. Usage is implied only by the tool's name and description.
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 what data is returned (name, logo, description, etc.), which is useful, but lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (limit parameter suggests pagination but no details), error conditions, or what 'more' includes. For a fetch tool with no annotation coverage, this is a significant gap.
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 the core purpose ('Fetch entities belonging to a specific category') and adds useful detail about return fields. It avoids redundancy and waste, though it could be slightly more structured (e.g., separating purpose from output details).
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 fetch operation with potential complexity (pagination, data richness), the description is incomplete. It lists return fields but doesn't cover behavioral aspects like safety, performance, or error handling. For a tool that returns 'more' data without an output schema, this leaves too much undefined.
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 both parameters (categoryId and limit). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain categoryId format, source, or valid values, or how limit interacts with pagination. 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's purpose: 'Fetch entities belonging to a specific category' (verb+resource). It distinguishes from siblings like 'evm_getentity' (single entity) and 'evm_searchentities' (search-based), but doesn't explicitly contrast with 'evm_getentitycategories' (which likely lists categories rather than entities within them). The description is specific but could be more precise about 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. It doesn't mention prerequisites (e.g., needing a valid categoryId from another tool), exclusions, or comparisons to siblings like 'evm_searchentities' for broader searches. Usage is implied only by the tool name and description, with no explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns 'on-chain metadata as well as off-chain metadata, floor prices, rarity and more where available,' which adds some context about return content. However, it lacks critical behavioral details such as rate limits, error handling, authentication requirements, or performance characteristics (e.g., response time, pagination). For a read operation with multiple parameters, this is a significant gap.
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 appropriately sized and front-loaded, with the core purpose stated first. Both sentences add value: the first defines the tool's function and input constraints, the second details the return content. There is no wasted text, making it efficient while covering essential aspects.
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 (handling multiple NFTs with various metadata types), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the structure of returned data, error conditions, or limitations beyond the 25-token cap. For a tool with rich potential outputs and no structured output documentation, 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 schema already documents all parameters ('chain', 'requestBody' with 'tokens', 'normalizeMetadata', 'media_items'). The description adds minimal value beyond the schema by mentioning 'array of up to 25 tokens' and the required fields, but doesn't explain parameter interactions or provide additional semantics. This meets the baseline for high schema coverage.
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: 'Get NFT metadata for one or many NFTs.' It specifies the verb ('Get') and resource ('NFT metadata'), and distinguishes it from siblings like 'evm_getnftmetadata' by handling multiple NFTs. However, it doesn't explicitly contrast with 'evm_getwalletnfts' or 'evm_getnftcollectionstats', leaving some ambiguity about 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. It mentions the tool accepts an array of tokens but doesn't compare it to similar tools like 'evm_getnftmetadata' (single NFT) or 'evm_getwalletnfts' (NFTs by wallet). There are no explicit when/when-not instructions or named alternatives, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions 'Find NFTs' and 'attribute-based searches,' which implies a read operation, but it doesn't disclose critical behavioral traits such as pagination behavior (hinted by the 'cursor' parameter), rate limits, authentication requirements, error handling, or what the output looks like (especially since there's no output schema). This leaves significant gaps for a tool with 8 parameters and complex nested objects.
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 highly concise and front-loaded: a single sentence that directly states the tool's purpose and key use case ('perfect for attribute-based searches'). There is no wasted verbiage, repetition, or unnecessary elaboration, making it efficient and easy to parse.
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 (8 parameters, nested objects, no output schema, and no annotations), the description is inadequate. It lacks information on behavioral traits (e.g., pagination, rate limits), output format, error conditions, and how to interpret results. While the schema covers parameters, the description fails to provide the contextual completeness needed for an AI agent to use the tool effectively beyond basic purpose understanding.
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%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond implying trait-based filtering via 'matching specific traits,' which loosely relates to the 'requestBody.traits' parameter. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description provides minimal extra value regarding parameters.
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: 'Find NFTs in a contract matching specific traits, perfect for attribute-based searches.' It specifies the verb ('Find'), resource ('NFTs in a contract'), and scope ('matching specific traits'), which distinguishes it from many sibling tools focused on different NFT operations like metadata, trades, or collections. However, it doesn't explicitly differentiate from similar tools like 'evm_getnfttraitsbycollection' or 'evm_getwalletnfts', which slightly limits 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 minimal usage guidance. It mentions 'perfect for attribute-based searches,' which implies a context but doesn't specify when to use this tool versus alternatives (e.g., vs. 'evm_getnfttraitsbycollection' for trait exploration or 'evm_getwalletnfts' for wallet-based queries). No exclusions, prerequisites, or explicit alternatives are provided, leaving the agent with little 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Refreshes every 30 minutes,' which adds useful context about data update frequency. However, it lacks critical details such as whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, error handling, or pagination behavior (though 'cursor' in the schema hints at pagination). For a tool with no annotations, 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 highly concise and front-loaded: two sentences that directly state the tool's purpose and a key behavioral trait ('Refreshes every 30 minutes'). There is zero waste or redundancy, making it efficient for an agent to parse.
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 (historical data retrieval with multiple parameters), lack of annotations, and no output schema, the description is incomplete. It covers the basic purpose and refresh rate but omits essential context such as output format, error conditions, pagination details (implied by 'cursor' but not explained), and comparison to sibling tools. This leaves significant gaps for an agent 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 documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain 'interval' options or 'address' format). Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra insights.
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: 'Get timeseries historical floor prices for a given NFT collection.' It specifies the verb ('Get'), resource ('historical floor prices'), and scope ('timeseries' for a 'given NFT collection'). However, it doesn't explicitly differentiate from sibling tools like 'evm_getnftfloorpricebycontract' (which likely provides current rather than historical data), so it misses full sibling distinction.
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 minimal usage guidance. It mentions 'Refreshes every 30 minutes,' which hints at data freshness but doesn't specify when to use this tool versus alternatives (e.g., for historical analysis vs. current prices). No explicit when/when-not instructions or named alternatives are provided, leaving the agent with little contextual direction.
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 what data is included (metadata, floor prices, rarity) but doesn't cover important aspects like rate limits, authentication requirements, error handling, response format, or whether this is a read-only operation (though 'fetch' implies read-only). The phrase 'where available' hints at partial responses but isn't specific.
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 purpose and scope. It's appropriately front-loaded with the main action. However, it could be slightly more structured by separating primary function from additional features.
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 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the response structure, error cases, rate limits, or authentication requirements. While it mentions what data is fetched, it doesn't provide enough context for reliable agent usage given the complexity.
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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (like explaining relationships between parameters or providing examples). The baseline of 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 verb ('fetch') and resource ('metadata for a specific NFT'), and specifies what metadata is included (on-chain, off-chain, floor prices, rarity). It distinguishes from some siblings like 'evm_getnftcollectionstats' by focusing on individual NFTs rather than collections, but doesn't explicitly differentiate from 'evm_getmultiplenfts' or 'solana_getnftmetadata'.
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 about when to use this tool versus alternatives like 'evm_getmultiplenfts' for batch operations, 'evm_getnftcollectionstats' for collection-level data, or 'solana_getnftmetadata' for Solana NFTs. The description doesn't mention prerequisites, error conditions, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves NFT trades, implying a read-only operation, but doesn't mention potential side effects, rate limits, authentication requirements, pagination behavior (beyond the 'cursor' parameter in the schema), error handling, or response format. For a tool with 10 parameters and no annotation coverage, this leaves significant gaps in understanding 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 the core purpose ('Get NFT trades for a given contract') and adds a key feature ('with the ability to filter by marketplace'). There is no wasted verbiage, repetition, or unnecessary elaboration, making it highly concise and well-structured for quick comprehension.
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 (10 parameters, no annotations, no output schema), the description is inadequate. It lacks details on behavioral traits (e.g., pagination, rate limits), usage guidelines compared to siblings, and output expectations. While the schema covers parameters, the description fails to provide the necessary context for safe and effective use, especially for a data-fetching tool with multiple filtering options.
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%, meaning all parameters are documented in the input schema itself. The description adds no additional parameter semantics beyond mentioning 'filter by marketplace,' which is already covered by the 'marketplace' parameter in the schema. Since the schema does the heavy lifting, 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 tool's purpose: 'Get NFT trades for a given contract with the ability to filter by marketplace.' It specifies the verb ('Get'), resource ('NFT trades'), and scope ('for a given contract'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'evm_getnfttradesbywallet' or 'evm_getnftcontracttransfers', which handle similar NFT trade data but for different scopes (wallet vs. contract).
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 filtering by marketplace, but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'evm_getnfttradesbywallet' (for wallet-specific trades) or 'evm_getnftcontracttransfers' (for transfers vs. trades). Without this context, users must infer usage from the tool name and parameters 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 of behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't mention any behavioral traits such as rate limits, authentication requirements, pagination behavior (though 'cursor' and 'limit' parameters hint at it), error conditions, or what the output format looks like. This leaves significant gaps for a tool with 9 parameters.
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 communicates the core purpose without any wasted words. It's appropriately sized for a straightforward data retrieval tool 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?
For a tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, pagination behavior, error handling, or provide any examples of typical use cases. The agent would need to rely heavily on the input schema alone, which isn't ideal for effective tool invocation.
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 'wallet address' which aligns with the required 'address' parameter, but adds no additional semantic context beyond what the schema provides. With 100% schema description coverage, the baseline is 3, and the description doesn't compensate by explaining relationships between parameters (e.g., block vs date precedence) or typical usage patterns.
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 ('NFT trades for a specific wallet address'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'evm_getnfttrades' (which appears to get NFT trades generally) or 'evm_getswapsbywalletaddress' (which gets swaps rather than trades), missing an opportunity for precise 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 many sibling tools available (e.g., 'evm_getnfttrades', 'evm_getswapsbywalletaddress', 'evm_getwalletnfts'), there's no indication of what makes this tool unique or when it's the appropriate choice, leaving the agent to infer usage from 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 of behavioral disclosure. It only states what data is retrieved without mentioning critical behaviors like rate limits, authentication needs, pagination details (implied by 'cursor' parameter but not explained), error handling, or data freshness. This is a significant gap for a tool with 8 parameters and 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 that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy to understand at a glance, which earns a high score 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 (8 parameters, 5 required, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output format, error cases, and usage context. While the schema covers parameters well, the description does not address other critical aspects needed for effective tool invocation, making it inadequate for the tool's scope.
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%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying OHLCV data retrieval, which is redundant with the schema's details. According to the rules, baseline is 3 when schema coverage is high (>80%), and the description does not compensate with extra insights.
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 ('Retrieve') and resource ('OHLCV candlestick data for a token pair'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from sibling tools like 'solana_getcandlesticks' or 'evm_gettimeseriestokenanalytics', which might also retrieve time-series data, so it falls short of 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, such as other candlestick-related tools in the sibling list (e.g., 'solana_getcandlesticks' for Solana or 'evm_gettimeseriestokenanalytics' for broader analytics). There is no mention of prerequisites, exclusions, or specific contexts, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that returned wallets include 'detailed information about how much was bought, sold as well as PnL stats and more,' which hints at read-only analytics. However, it lacks critical details: whether this is a real-time or historical query, any rate limits, authentication requirements, error conditions, or the structure of the returned data. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in the first clause. The second sentence adds useful detail about the returned data. There's no wasted verbiage, and both sentences contribute meaningfully to understanding the tool's 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 complexity (identifying 'sniper wallets' with financial analytics), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what qualifies as a 'sniper wallet,' how the data is sourced or calculated, the format of the returned details (e.g., PnL stats), or any limitations. For a tool with no structured behavioral or output documentation, this leaves too many unknowns for effective agent 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 already documents all parameters (chain, address, blocksAfterCreation) with descriptions and constraints. The description adds marginal value by emphasizing the timeframe aspect ('within a specified timeframe (blocksAfterCreation)') but doesn't provide additional semantics beyond what the schema offers. This meets the baseline for high schema coverage.
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: 'Identify sniper wallets that bought a token within a specified timeframe.' It specifies the action (identify), target (sniper wallets), and key constraint (timeframe defined by blocksAfterCreation). However, it doesn't explicitly differentiate from sibling tools like evm_getswapsbypairaddress or solana_getsnipersbypairaddress, which appear to serve similar but potentially distinct purposes.
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 minimal usage guidance. It mentions the timeframe parameter (blocksAfterCreation) but doesn't explain when to use this tool versus alternatives (e.g., evm_getswapsbypairaddress for general swaps or evm_gettopprofitablewalletpertoken for profitability insights). No prerequisites, exclusions, or comparative context are given, leaving the agent with little guidance 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?
With no annotations provided, the description carries full burden but only states what data is fetched without behavioral details. It doesn't disclose pagination behavior (implied by 'cursor' parameter but not explained), rate limits, authentication requirements, error conditions, or response format. For a read operation with 10 parameters, 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 that front-loads the core purpose without unnecessary words. Every element ('Fetch swap transactions', transaction types, token pair focus) contributes directly to understanding the tool's 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?
For a tool with 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the response structure, pagination behavior, error handling, or usage constraints. While the schema documents parameters well, the description fails to provide necessary operational context for effective tool invocation.
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 parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying 'address' refers to a token pair. This meets the baseline for high schema coverage but doesn't provide extra value like explaining parameter interactions or constraints.
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 ('Fetch swap transactions') and resource ('for a specific token pair'), specifying the types of transactions included (buy, sell, add/remove liquidity). It distinguishes from some siblings like 'evm_getswapsbytokenaddress' and 'evm_getswapsbywalletaddress' by focusing on token pairs, but doesn't explicitly differentiate from 'evm_getsnipersbypairaddress' or 'solana_getswapsbypairaddress'.
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. The description doesn't mention prerequisites, constraints, or compare it to similar tools like 'evm_getswapsbytokenaddress' or 'evm_getsnipersbypairaddress', leaving the agent without context for 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving 'all swap transactions' but doesn't clarify if this is paginated (though 'cursor' parameter hints at it), rate limits, authentication needs, or what the output format looks like. For a tool with 10 parameters and no output schema, 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 the core purpose without unnecessary words. It directly states the action and target 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 the tool's complexity (10 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the return format, pagination behavior (implied by 'cursor'), or how parameters like 'transactionTypes' filter results. For a data retrieval tool with many filtering options, 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%, so the schema fully documents all 10 parameters. The description adds no additional parameter semantics beyond implying the 'address' parameter is for an ERC20 token. This meets the baseline for high schema coverage, but doesn't enhance understanding of parameter usage or interactions.
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 ('all swap transactions for a specific ERC20 token'), specifying it retrieves both buy and sell transactions. It distinguishes from obvious siblings like 'evm_getswapsbypairaddress' and 'evm_getswapsbywalletaddress' by focusing on token address, though it doesn't explicitly mention these 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?
No guidance is provided on when to use this tool versus alternatives like 'evm_getswapsbypairaddress' or 'evm_getswapsbywalletaddress'. The description only states what it does without context about prerequisites, typical use cases, or limitations compared to sibling tools.
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 fetching data but fails to describe critical traits like rate limits, authentication needs, error handling, or the format of returned data (e.g., time intervals, units). This leaves significant gaps in understanding 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 directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly and understand 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 complexity of fetching timeseries financial data (volume, liquidity, FDV), no annotations, and no output schema, the description is incomplete. It lacks details on data format, potential limitations, or how results are structured, which is crucial for an agent to effectively use this tool in real-world scenarios.
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, clearly documenting both parameters ('chain' and 'timeframe') with enums and defaults. The description adds no additional semantic context beyond implying blockchain specificity, so it meets the baseline score of 3, as the schema adequately handles parameter 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 action ('Fetch') and the specific data types ('timeseries volume, liquidity and FDV') for a blockchain, which distinguishes it from general data-fetching tools. However, it doesn't explicitly differentiate from similar sibling tools like 'evm_gettimeseriestokenanalytics' or 'evm_gettimeseriesvolumebycategory', which might handle related but different data queries.
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, such as other timeseries or volume-related tools in the sibling list. It lacks context about prerequisites, typical use cases, or comparisons to similar tools like 'evm_getvolumestatsbycategory', leaving the agent without clear usage direction.
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 describes the return data (total holders and aggregated stats) but lacks critical details: it doesn't specify if this is a read-only operation, potential rate limits, authentication needs, data freshness (e.g., real-time vs. cached), or error conditions. For a tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Returns total holders for a given token') and adds necessary details ('as well as aggregated stats...'). There's no wasted verbiage, making it appropriately concise for its informational content.
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 returning aggregated stats and the lack of annotations and output schema, the description is incomplete. It mentions the types of stats (e.g., holder trends, distribution) but doesn't explain the structure, format, or units of the returned data. For a tool with no output schema and no annotations, this leaves the agent with insufficient context to interpret results 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 clear descriptions for both parameters ('chain' and 'tokenAddress'). The description adds no additional parameter semantics beyond what the schema provides, such as format details for 'tokenAddress' or implications of the 'chain' enum choices. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents the parameters without extra help from 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 tool's purpose: 'Returns total holders for a given token, as well as aggregated stats holder supply, holder trends, holder distribution and holder acquisition metrics.' It specifies the verb ('returns') and resource ('token holders'), but doesn't explicitly differentiate from sibling tools like 'evm_gethistoricaltokenholders' or 'solana_gettokenholders', which might offer similar functionality for different contexts or timeframes.
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 sibling tools like 'evm_gethistoricaltokenholders' (which might provide historical data) or 'evm_gettokenowners' (which might list individual owners), nor does it specify prerequisites or contexts for usage, such as requiring a specific token type or chain support.
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 retrieving metadata but doesn't disclose critical traits: whether this is a read-only operation (implied but not stated), rate limits, authentication needs, error handling (e.g., for invalid addresses), pagination (though addresses are limited to 10), or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic retrieval action.
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 the core purpose ('Retrieve metadata...') and lists key metadata fields. There's no wasted verbiage or redundancy. However, it could be slightly more structured by separating core vs. extended metadata, but this is minor. It earns a 4 for being appropriately sized and direct.
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 (ERC20 token metadata retrieval with multiple fields), lack of annotations, and no output schema, the description is incomplete. It lists metadata types but doesn't cover behavioral aspects (e.g., rate limits, errors), response structure, or usage context. For a tool with 2 parameters and rich potential output, more detail is needed to help an agent invoke it correctly without structured output guidance.
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 clear descriptions for both parameters ('The chain to query' and 'The addresses to get metadata for'). The description adds no parameter-specific semantics beyond what the schema provides—it doesn't explain address format (e.g., checksummed), chain selection implications, or the meaning of retrieving metadata for multiple addresses. Since the schema does the heavy lifting, 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 ('Retrieve') and resource ('metadata for an ERC20 token contract'), and lists specific metadata fields (name, symbol, decimals, logo, off-chain metadata, total supply, categories, spam status). It distinguishes from siblings like evm_gettokenholders or evm_gettokenprices by focusing on metadata retrieval rather than holders, pairs, or analytics. However, it doesn't explicitly differentiate from evm_getnftmetadata (which handles NFTs) or solana_gettokenmetadata (which handles Solana tokens), though the ERC20 specification provides some implicit distinction.
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 it over evm_getfilteredtokens (which might include metadata), evm_searchtokens (for discovery), or evm_gettokenscore (for scoring). There are no exclusions, prerequisites, or context about typical use cases (e.g., for token verification or display). The agent must infer usage from the purpose 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 that the tool 'Includes known entities, exchanges and wallet labels,' which adds some behavioral context about enriched data. However, it lacks critical details: it doesn't specify if this is a read-only operation, whether it's paginated (implied by 'limit' and 'cursor' parameters but not stated), rate limits, or authentication needs. The description is insufficient for a tool with 5 parameters and 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 concise and front-loaded with the core purpose in the first sentence. The second sentence adds useful context about included data. There's no wasted verbiage, and it's appropriately sized for the tool's complexity.
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 (5 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral transparency, usage guidelines, and details on output format (e.g., what 'ownership percentages' mean or how results are structured). For a tool that likely returns paginated data with enriched holder information, more context is needed to be fully helpful.
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%, so the schema already documents all parameters thoroughly. The description doesn't add any specific meaning beyond what the schema provides (e.g., it doesn't explain how 'token_address' relates to ERC20 tokens or clarify 'major holders' criteria). With high schema coverage, the baseline is 3, and the description doesn't compensate with additional insights.
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: 'Identify the major holders of an ERC20 token and understand their ownership percentages.' It specifies the resource (ERC20 token holders) and the action (identify major holders with percentages). However, it doesn't explicitly differentiate from sibling tools like 'evm_gettokenholders' or 'evm_gethistoricaltokenholders,' which appear to be related but not clearly distinguished.
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 'Includes known entities, exchanges and wallet labels,' which hints at enriched data, but doesn't specify if this is for current vs. historical holders or how it differs from siblings like 'evm_gettokenholders.' No explicit when/when-not or alternative recommendations are provided.
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 that pairs include 'price, liquidity, volume and more', which hints at return data, but fails to describe critical behaviors such as pagination (implied by 'cursor' parameter but not explained), rate limits, authentication needs, or error handling, leaving 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 front-loads the core purpose and includes key return data. There is no wasted verbiage, making it appropriately sized and easy to parse.
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 4-parameter tool with no annotations and no output schema, the description is insufficient. It lacks details on return format (beyond vague 'and more'), pagination behavior, error cases, and usage context, making it incomplete for effective agent operation.
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 parameters. The description adds no additional meaning beyond the schema, such as explaining token address format or chain selection implications. 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 verb ('List') and resource ('supported trading pairs for a specific ERC20 token'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'evm_getfilteredtokens' or 'solana_gettokenpairs', which might have overlapping functionality, preventing 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. It doesn't mention prerequisites, exclusions, or compare to sibling tools like 'evm_getfilteredtokens' or 'evm_getmultipletokenprices', leaving the agent without context for 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. It mentions retrieving a score with metrics, but doesn't disclose behavioral traits such as rate limits, authentication needs, data freshness, error handling, or whether it's a read-only operation. This is inadequate for a tool with potential complexity in blockchain data retrieval.
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, well-structured sentence that front-loads the core purpose and lists key metrics efficiently. It avoids redundancy and wastes no words, making it easy to parse, though it could be slightly more detailed given the lack of annotations.
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 blockchain token scoring, no annotations, and no output schema, the description is insufficient. It doesn't explain what the 'score' entails, how metrics are calculated, return format, or error cases. This leaves significant gaps for an AI agent to understand and 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%, with clear descriptions for both parameters (chain and tokenAddress). The description adds no additional parameter semantics beyond what the schema provides, such as format details for tokenAddress or chain selection implications. Baseline 3 is appropriate given the schema's completeness.
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 ('Retrieve a score') and resource ('for a specific token'), with specific metrics listed (price, volume, liquidity, etc.). It distinguishes from many siblings (e.g., evm_gettokenmetadata, evm_gettokenprices) by focusing on a comprehensive score, but doesn't explicitly differentiate from evm_getmultipletokenanalytics or evm_gettimeseriestokenanalytics which might overlap in scope.
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 evm_getmultipletokenanalytics for batch processing or evm_gettimeseriestokenanalytics for historical data. The description implies it's for a single token with detailed metrics, but lacks explicit context or prerequisites for selection among similar tools.
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 ordering by block number (newest first), which is a behavioral trait, but lacks details on pagination (implied by 'cursor' parameter), rate limits, authentication needs, or what the return format looks like. For a read operation with 9 parameters, 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 that front-loads the core purpose. There is zero waste, and every word earns its place by specifying the resource, scope, and ordering.
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 (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, pagination behavior, or error conditions. For a tool with rich input options and no structured output, 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 schema fully documents all 9 parameters. The description adds no additional parameter semantics beyond implying block number ordering, which is already covered by the 'order' parameter in the schema. 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.
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 'all ERC20 token transfers for a contract', specifying the ordering by block number. It distinguishes from siblings like evm_getnftcontracttransfers or evm_getswapsbytokenaddress by focusing on ERC20 token transfers specifically, though it doesn't explicitly contrast with 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. The description doesn't mention prerequisites, limitations, or sibling tools that might be better for different scenarios (e.g., evm_gettokenholders for holder data). Usage is implied by the description but not explicitly 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool identifies tokens based on price increases but doesn't describe what 'highest' means (e.g., top N results, threshold-based), whether results are paginated, rate limits, authentication needs, or error handling. For a query 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It uses clear language ('Identify tokens with the highest price increases over a period') and avoids redundancy or fluff, 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 querying token data with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., result format, limits), usage context relative to siblings, and output details. While the schema covers parameters well, the overall context for effective tool invocation is insufficient.
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%, meaning all parameters (chain, min_market_cap, security_score, time_frame) are documented in the schema itself. The description adds no additional parameter semantics beyond implying a focus on price increases, which aligns with the 'time_frame' parameter. 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's purpose: 'Identify tokens with the highest price increases over a period.' It specifies the action (identify), resource (tokens), and key criterion (highest price increases). However, it doesn't explicitly differentiate from sibling tools like 'evm_gettopcryptocurrenciesbypricemovers' or 'evm_gettoploserstokens', which likely serve similar but distinct purposes.
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 sibling tools (e.g., 'evm_gettoploserstokens' for price decreases or 'evm_gettopcryptocurrenciesbymarketcap' for other rankings), prerequisites, or specific use cases beyond the general purpose. This leaves the agent without context for 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. It states the tool lists tokens based on price decreases but lacks details on output format (e.g., list structure, fields returned), pagination, rate limits, authentication requirements, or error handling. For a tool with no annotations, this leaves significant gaps in understanding how it 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 is front-loaded with the core function and avoids redundancy, making it easy to parse quickly. Every part of the sentence contributes essential information, 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 the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, behavioral traits (e.g., sorting order, result limits), and usage context relative to siblings. While the schema covers parameters well, the description does not compensate for missing annotations or output schema, leaving gaps in overall understanding for effective tool invocation.
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 clear parameter definitions (e.g., 'chain' for querying, 'min_market_cap' in USD, 'time_frame' for ordering). The description adds no additional semantic context beyond what the schema provides, such as explaining how parameters interact (e.g., combining 'min_market_cap' with 'security_score') or default behaviors. Given the high schema coverage, a baseline score of 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.
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: 'List tokens with the largest price decreases over a period.' It specifies the verb ('List'), resource ('tokens'), and key criteria ('largest price decreases over a period'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'evm_gettopgainerstokens' (which focuses on price increases) or 'evm_gettopcryptocurrenciesbymarketcap' (which uses market cap), though the distinction is implied by the name and description.
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 does not mention sibling tools like 'evm_gettopgainerstokens' for price increases or 'evm_gettopcryptocurrenciesbymarketcap' for market cap ranking, nor does it specify prerequisites or contextual cues for selection. Usage is implied by the name and description but not explicitly 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 states the tool lists wallets based on profitability but fails to explain how profitability is calculated, what data is returned (e.g., format, fields like profit amount or wallet addresses), or any limitations (e.g., rate limits, data freshness). 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 is front-loaded and appropriately sized, 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 analyzing wallet profitability, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, calculation methodology, or potential constraints, leaving the agent with incomplete information to effectively use the tool in 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 input schema already documents all parameters (address, days, chain) with descriptions and enums. The description adds no additional semantic context beyond implying the 'address' is for an ERC20 token and 'days' relates to profitability calculation timeframe, which is already covered in the schema. This meets the baseline for high schema coverage.
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 ('List') and the target ('most profitable wallets that have traded a specific ERC20 token'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'evm_getwalletprofitability' or 'evm_getswapsbytokenaddress', which might provide related but different functionality, preventing 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, such as sibling tools for profitability or token trading analysis. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the purpose 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 of behavioral disclosure. It mentions retrieving unique owners but doesn't specify if this is a read-only operation, whether it requires authentication, any rate limits, pagination behavior beyond the cursor parameter, or what the output format looks like. This leaves significant gaps in understanding how the tool behaves.
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 front-loaded and appropriately sized for its content, 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 querying NFT owners across multiple chains, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits, output format, error handling, and usage context, making it incomplete for an agent to reliably invoke this tool without additional assumptions.
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 parameters thoroughly. The description adds no additional meaning about parameters beyond implying the 'address' is for an NFT contract, which is somewhat redundant with the schema. The baseline score of 3 reflects adequate parameter documentation primarily from the schema.
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') and resource ('unique wallet addresses owning NFTs from a contract'), making the purpose understandable. However, it doesn't explicitly differentiate from similar sibling tools like 'evm_gettokenholders' or 'evm_gethistoricaltokenholders', which might also retrieve wallet information related to tokens or NFTs.
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 that involve wallets, NFTs, or token holders, there's no indication of specific use cases, prerequisites, or comparisons to help an agent choose appropriately.
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 accessing stats but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or what the output format looks like (e.g., JSON structure, pagination). This leaves significant gaps for an agent to understand how to interact with the tool 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 concise and front-loaded, stating the core purpose in one sentence. There's no wasted text, but it could be slightly more informative without sacrificing brevity (e.g., by hinting at output structure). Overall, it's efficient and well-structured.
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 accessing blockchain stats and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'category' means, how stats are grouped, what metrics are included, or the return format. For a tool with no structured output documentation, this leaves too much ambiguity 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?
The description adds minimal value beyond the input schema, which has 100% coverage. It mentions filtering by 'chain', but the schema already documents this parameter with a description and enum values. No additional semantics (e.g., default behavior, impact of not specifying chain) are provided, so the baseline score of 3 is appropriate given 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 action ('Access') and the resource ('volume, buyers, sellers and transaction stats for a blockchain, grouped by category'), making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'evm_getvolumestatsbychain' or 'evm_gettimeseriesvolumebycategory', which might offer similar functionality with different grouping or time-series aspects.
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 minimal guidance by mentioning filtering by 'chain', but it doesn't specify when to use this tool versus alternatives (e.g., 'evm_getvolumestatsbychain' for chain-level stats or 'evm_gettimeseriesvolumebycategory' for time-series data). No exclusions, prerequisites, or context for usage are provided.
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 that the tool lists 'active' approvals, implying a read-only operation, but doesn't specify if it's paginated (though the schema hints at pagination with 'limit' and 'cursor'), what the output format is, rate limits, or any error conditions. 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 front-loaded with the core action and resource, making it easy to parse quickly. There's no wasted verbiage, earning a top score 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 tool's complexity (querying blockchain data with 4 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain the return format, pagination behavior, or potential errors, which are critical for an AI agent to use the tool effectively. The high schema coverage helps with inputs, but overall context is incomplete.
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%, meaning all parameters are documented in the schema itself. The description adds minimal value by implying the 'address' parameter is for a wallet and the output relates to ERC20 tokens, but it doesn't provide additional context like format examples or edge cases beyond what the schema already states. This meets the baseline for high schema coverage.
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: 'List active ERC20 token approvals for a wallet, showing which contracts have access.' It specifies the verb ('List'), resource ('active ERC20 token approvals'), and target ('wallet'). However, it doesn't explicitly differentiate from sibling tools like 'evm_getwallethistory' or 'evm_getwalletstats' that might also involve wallet data, so it doesn't reach the highest 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. It doesn't mention any prerequisites, exclusions, or specific contexts for usage. For example, it doesn't clarify if this is for security audits, transaction analysis, or other scenarios, leaving the agent without usage direction.
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 states the tool retrieves a summary but doesn't clarify if this is a read-only operation, what permissions might be needed, whether it's rate-limited, or what the output format looks like. The description lacks essential behavioral context for a tool that likely queries external data.
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 the core purpose without unnecessary words. It directly communicates what the tool does and includes key parameter context, 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.
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 the profitability summary includes, how results are formatted, or any behavioral traits like error handling or data freshness. Given the complexity of financial data retrieval, more context is 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 three parameters. The description mentions the 'days' parameter and its purpose but doesn't add meaningful semantics beyond what's already in the schema descriptions. This meets the baseline for high schema coverage.
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 ('profit and loss summary for a given wallet'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'evm_getwalletprofitability' or 'evm_getwalletnetworth', which appear to be related but distinct wallet analysis 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?
The description provides no guidance on when to use this tool versus alternatives. It mentions a timeframe parameter but doesn't explain why one would choose this tool over similar siblings (e.g., 'evm_getwalletprofitability' or 'evm_getwalletnetworth'), nor does it specify 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, which implies a read-only operation, but doesn't mention potential limitations like rate limits, authentication requirements, data freshness, or error conditions. The description lacks behavioral context beyond the basic operation.
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 the core purpose. It avoids unnecessary words and gets straight to the point, though it could be slightly more specific about what 'activity' entails to improve clarity without sacrificing conciseness.
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?
For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details about the return format (what specific statistics are included), behavioral constraints, or usage context. The absence of annotations and output schema means the description should do more to compensate, but it only meets the minimum viable threshold.
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 both parameters ('chain' and 'address') clearly documented in the schema. The description doesn't add any parameter semantics beyond what's already in the schema, such as explaining what 'key statistics' specifically include or how the 'activity' metric is calculated. Baseline score of 3 is appropriate given 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's purpose with a specific verb ('retrieve') and resource ('key statistics for a wallet'), and provides examples ('total transaction count and activity'). It distinguishes itself from sibling tools like 'evm_getwallethistory' or 'evm_getwalletnetworth' by focusing on aggregated statistics rather than detailed history or net worth calculations.
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. While it implies usage for wallet statistics, it doesn't mention when to choose it over similar tools like 'evm_getwalletprofitability' or 'evm_getwalletactivechains', nor does it specify any prerequisites or exclusions for its use.
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 implies a read-only operation (resolve) but doesn't disclose behavioral traits like error handling (e.g., for invalid domains), rate limits, authentication needs, or what happens if the domain doesn't exist. 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 zero waste. It is front-loaded with the core purpose and uses clear, direct language without unnecessary details.
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 incomplete. It lacks details on return values (e.g., address format, null cases), error conditions, and behavioral context. Given the complexity of ENS resolution and the absence of structured data, more information is 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%, with the parameter 'domain' fully documented in the schema. The description adds no additional semantic context beyond what the schema provides, such as format examples (e.g., 'vitalik.eth') or validation rules. Baseline 3 is appropriate since 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 verb 'resolve' and the resource 'ENS domain' with the outcome 'to its associated Ethereum address.' It distinguishes from siblings like 'evm_resolveaddress' by specifying domain resolution rather than address resolution, though it doesn't explicitly compare 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 'evm_resolveaddress' or other sibling tools. The description lacks context about prerequisites, such as needing a valid ENS domain, or when this tool is appropriate compared to other resolution 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions that 'Results are categorised into 3 arrays,' it doesn't describe important behavioral aspects like whether this is a read-only operation, what happens with invalid queries, whether there are rate limits, authentication requirements, or what the response structure looks like beyond the three array categories.
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 with just two sentences that directly state the tool's purpose and output structure. Every word earns its place, and the information is front-loaded with no unnecessary elaboration or redundancy.
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 insufficient. It doesn't explain what types of queries are supported, what the result arrays contain, whether there's pagination, error handling, or any behavioral constraints. The categorization mention is helpful but doesn't compensate for the lack of output details and behavioral 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 documents both parameters ('query' and 'limit') adequately. The description doesn't add any parameter-specific information beyond what's in the schema, such as query format examples or limit usage guidelines. This meets the baseline expectation when schema coverage is complete.
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: 'Find entities, organizations, addresses or wallets linked to blockchain addresses.' It specifies the verb ('Find') and resources ('entities, organizations, addresses or wallets'), and mentions the result categorization. However, it doesn't explicitly differentiate from sibling tools like 'evm_searchtokens' or 'evm_resolveaddress', which appear to serve related but distinct purposes.
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 like 'evm_searchtokens', 'evm_resolveaddress', and 'evm_getentity', there's no indication of what makes this tool unique or when it should be preferred over those other search/resolution tools.
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' data (implying a read-only operation) but doesn't mention rate limits, authentication requirements, error conditions, or the format of the returned balance. For a tool with no 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 directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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 insufficient for a complete understanding. It doesn't explain what 'native balance' entails (e.g., SOL in lamports or another unit), potential response formats, or error handling. For a tool with no structured behavioral data, more context is needed to be fully actionable.
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 clear documentation for both parameters ('network' and 'address'). The description adds no additional parameter semantics beyond what the schema provides, such as address format examples or network-specific considerations. With high 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 action ('Gets') and the resource ('native balance owned by the given address'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'solana_getportfolio' or 'solana_getspl', but the focus on 'native balance' (likely SOL) provides some implicit distinction from token-related queries.
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., 'solana_getportfolio' for broader balance queries, 'solana_getspl' for token balances), the description offers no context about prerequisites, typical use cases, or comparisons to other tools.
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 'aggregated statistics' but doesn't specify what types of statistics, whether it's read-only, if it requires authentication, rate limits, or error handling. This is a significant gap 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 purpose and appropriately sized for the tool's complexity, 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 'aggregated statistics' entail, the return format, or behavioral aspects like error cases. For a tool with 2 parameters and no structured output information, this leaves too many gaps for effective agent 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 already documents both parameters ('network' and 'address') with descriptions. The description doesn't add any additional meaning beyond what's in the schema, such as clarifying the token address format or network implications, resulting in the baseline score.
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 aggregated statistics') and resource ('across supported pairs of a token'), which is specific and informative. However, it doesn't explicitly differentiate from sibling tools like 'solana_getpairstats' or 'solana_gettokenpairs', which might have overlapping functionality, so it doesn't reach the highest 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. With many sibling tools available (e.g., 'solana_getpairstats', 'solana_gettokenpairs'), there's no indication of context, prerequisites, or exclusions, leaving the agent to infer usage 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 full burden for behavioral disclosure. It mentions 'list' and pagination parameters (cursor, limit), implying a read-only, paginated query, but doesn't specify rate limits, authentication needs, error conditions, or what 'bonding tokens' means operationally. This leaves significant behavioral gaps for a tool with 4 parameters.
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 front-loaded and wastes no space, 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 no annotations, no output schema, and incomplete parameter guidance (e.g., undefined 'exchange' format), the description is insufficient. It doesn't explain what 'bonding tokens' are, how results are structured, or error handling, leaving the agent with critical gaps 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 75% (3 of 4 parameters have descriptions), providing a solid baseline. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain the 'exchange' parameter format or clarify 'bonding tokens' context. With high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the list') and resource ('bonding tokens by given exchange'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'solana_getgraduatedtokensbyexchange' or 'solana_getnewtokensbyexchange', which would require more specific scope details.
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 sibling tools like 'solana_getgraduatedtokensbyexchange' and 'solana_getnewtokensbyexchange' available, the description offers no context about what distinguishes bonding tokens from graduated or new tokens, leaving the agent without selection criteria.
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 only states what the tool does ('Gets NFTs') without detailing behavioral traits like rate limits, authentication needs, pagination, error handling, or what the output looks like. For a read operation with no annotations, 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.
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 front-loaded and wastes no space, making it easy to parse quickly. This is an example of optimal conciseness 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 complexity of a tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It fails to address key contextual elements like output format, error conditions, or usage constraints. The agent would lack sufficient information to use this tool effectively without additional context or trial-and-error.
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, thoroughly documenting all 6 parameters (e.g., 'network', 'address', 'nftMetadata'). The description does not add any semantic details beyond what the schema provides, such as explaining parameter interactions or default behaviors. Given the high 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 tool's purpose with a specific verb ('Gets') and resource ('NFTs owned by the given address'), making it immediately understandable. However, it does not explicitly differentiate from sibling tools like 'solana_getportfolio' or 'solana_getwalletnfts' (from the EVM context), which might offer similar functionality, so it falls short of 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, such as other NFT-related tools in the sibling list (e.g., 'solana_getnftmetadata' or 'solana_getportfolio'). It lacks context about prerequisites, exclusions, or specific use cases, leaving the agent to infer usage based on the tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Gets' data (implying a read operation) but doesn't mention rate limits, authentication requirements, error conditions, or what format the stats are returned in. For a tool with zero 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 with zero wasted words. It's appropriately sized for a simple lookup tool and gets straight to the point without unnecessary elaboration.
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 'stats' include, the return format, error handling, or performance characteristics. Given the complexity of blockchain data queries and the lack of structured metadata, this description leaves too many contextual 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 fully documents both parameters (network and pairAddress). The description doesn't add any additional meaning about parameter usage, constraints, or examples beyond what's already in the schema. Baseline 3 is appropriate when the schema does all the parameter documentation 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 action ('Gets') and resource ('stats for a specific pair address'), providing a specific verb+resource combination. However, it doesn't distinguish from sibling tools like 'solana_getaggregatedtokenpairstats' or 'evm_getpairstats', which appear to serve similar functions on different chains.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, and there's no comparison to sibling tools that might serve overlapping purposes on different networks or with different scopes.
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 states it 'gets' data (implying a read-only operation) but doesn't mention authentication requirements, rate limits, error conditions, or response format. For a tool with 5 parameters and no output schema, this leaves significant behavioral gaps. The description doesn't contradict annotations, but it's insufficient for a mutation-free tool with complex inputs.
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 the core purpose. There's zero wasted verbiage or redundancy. It's appropriately sized for a straightforward data retrieval tool, 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 tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't address what the output looks like (e.g., balance formats, token lists), how to handle large result sets, or error scenarios. For a portfolio tool that likely returns structured financial data, this leaves the agent with insufficient context 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%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond implying the 'address' parameter is central. It doesn't explain relationships between parameters (e.g., how 'nftMetadata' and 'mediaItems' interact) or provide usage examples. Baseline 3 is appropriate since 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's purpose with a specific verb ('gets') and resource ('all the native and token balances of the given address'). It distinguishes from siblings like 'solana_balance' (which likely only gets native balance) and 'solana_getnfts' (which focuses on NFTs), though it doesn't explicitly mention these distinctions. The purpose is specific but could be more precise about scope.
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 sibling tools like 'solana_balance' for native-only balances or 'solana_getnfts' for NFT-specific queries. There's no context about prerequisites, performance implications, or typical use cases, leaving the agent with minimal usage direction.
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 a read operation ('Gets'), implying it's likely non-destructive, but doesn't disclose behavioral traits like rate limits, authentication needs, error conditions, or what the return format looks like (e.g., list of balances with details). This is a significant gap 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 purpose without any fluff. It's front-loaded and appropriately sized, with every word contributing to clarity.
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 (a read operation with 3 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on return values, error handling, or behavioral constraints, making it inadequate for the agent to fully understand how 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 fully documents all parameters (network, address, excludeSpam). The description adds no additional meaning beyond implying the address parameter is for querying balances, which is already clear from the schema. This meets the baseline for high schema coverage.
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 ('Gets') and resource ('token balances owned by the given address'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'solana_balance' or 'solana_getportfolio', which might also retrieve balance-related information, so it misses the highest 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. With many sibling tools (e.g., 'solana_balance', 'solana_getportfolio', 'solana_gettokenholders'), there's no indication of context, prerequisites, or exclusions, leaving the agent to infer usage.
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 lacks behavioral details. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication needs, pagination behavior (implied by 'cursor' but not explained), or what the return format 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 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 tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain behavioral traits, return values, or usage context. While the schema covers parameters well, the description fails to compensate for missing annotations and output information.
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 8 parameters. The description adds no additional parameter semantics beyond implying the 'address' parameter is a token address (vs. other address types), which is minimal value. 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 verb ('Get') and resource ('all swap related transactions') with specificity about the scope ('for a specific token address'). It distinguishes from sibling tools like 'solana_getswapsbypairaddress' and 'solana_getswapsbywalletaddress' by focusing on token address, but 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. The description doesn't mention prerequisites, exclusions, or recommend other tools for different query types (e.g., using 'solana_getswapsbywalletaddress' for wallet-based 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving transactions but doesn't describe the return format, pagination behavior, rate limits, authentication needs, or error conditions. For a read operation with 9 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 the core purpose. There's no wasted verbiage, and every word earns its place. It's appropriately sized for the tool's complexity.
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 (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, pagination, error handling, or performance characteristics. For a data retrieval tool with multiple filtering options, more context is needed to help the agent 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%, so the schema fully documents all 9 parameters. The description adds no additional parameter semantics beyond what's in the schema. It mentions 'swap related transactions (buy, sell)' which aligns with the 'transactionTypes' parameter but doesn't provide extra context. 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's purpose: 'Get all swap related transactions (buy, sell) for a specific wallet address.' It specifies the action ('Get'), resource ('swap related transactions'), and scope ('for a specific wallet address'). However, it doesn't explicitly differentiate from sibling tools like 'solana_getswapsbypairaddress' or 'solana_getswapsbytokenaddress', which filter by different criteria.
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 sibling tools like 'solana_getswapsbypairaddress' or 'solana_getswapsbytokenaddress', nor does it specify prerequisites or exclusions. Usage is implied by the description but not explicitly 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get' but doesn't specify if this is a read-only operation, requires authentication, has rate limits, or what the return format looks like (e.g., paginated results due to cursor/limit parameters). This leaves significant gaps in understanding how the tool behaves.
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 front-loaded and wastes no space, 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, no output schema, and a tool with 4 parameters (including pagination via cursor/limit), the description is insufficient. It doesn't explain the return format, pagination behavior, error conditions, or how 'supported pairs' are defined, leaving the agent with incomplete context for proper invocation.
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 all parameters well. The description adds minimal value by implying the 'address' parameter is a token address, but doesn't clarify semantics beyond what's in the schema (e.g., format of address, what 'supported pairs' means). 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.
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') and resource ('supported pairs for a specific token address'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'solana_getpairstats' or 'solana_getaggregatedtokenpairstats', which might offer similar functionality but with different scopes or outputs.
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 lacks context such as prerequisites (e.g., token address validity), exclusions, or comparisons to siblings like 'solana_getpairstats', leaving the agent to infer usage 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't mention rate limits, authentication requirements, data freshness, error conditions, or response format. 'Gets' implies a read-only operation, but this isn't explicitly stated.
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 the core functionality. Every word contributes to understanding the tool's purpose without unnecessary elaboration.
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 the return values look like (structure of USD/native prices), potential limitations, or how it differs from similar tools in the server, leaving significant gaps for agent understanding.
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 parameters are fully documented in the schema. The description adds minimal value by mentioning 'contract address and network' but doesn't clarify parameter relationships or provide examples beyond what the schema already specifies.
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 ('Gets') and resource ('token price'), specifying both USD and native currency outputs. It distinguishes itself from sibling tools like 'solana_getmultipletokenprices' by focusing on a single token, though it doesn't explicitly mention this distinction.
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 'solana_getmultipletokenprices' for batch queries or 'evm_gettokenprices' for EVM networks. The description only states what it does, not when it's appropriate.
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. While 'paginated' implies a multi-page result structure, the description doesn't disclose critical behavioral details: what defines 'top' holders (by balance? by percentage?), what the response format looks like, whether there are rate limits, or what authentication might be required. For a read operation 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 gets straight to the point with zero wasted words. It's appropriately sized for a straightforward query 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?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes 'top' holders, what the return data structure looks like, or how pagination works in practice. The agent would need to guess about the response format and ranking criteria despite having all parameters documented in the schema.
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 four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what type of 'address' is expected (mint address? token account?), what 'cursor' format to use, or how 'limit' interacts with pagination. 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 ('Get paginated top holders') and resource ('for a given token'), making the purpose immediately understandable. However, it doesn't differentiate this Solana-specific tool from its sibling 'solana_gettokenholders' or 'evm_gettokenholders', which would require explicit comparison to achieve 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. With multiple sibling tools for token holders (both Solana and EVM variants), there's no indication of what makes 'top holders' distinct from regular holders or when pagination is necessary versus other holder 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?
No annotations are provided, so the description carries full burden. It states the tool retrieves a 'concise overview' but doesn't disclose behavioral traits like what data is included (e.g., balances, protocols, risks), whether it's real-time or cached, rate limits, or authentication needs. For a read operation 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 front-loads the core purpose without unnecessary details. Every word earns its place, making it easy to parse quickly.
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 (DeFi positions summary), no annotations, and no output schema, the description is minimally adequate but incomplete. It lacks details on return format, data scope, or limitations, which are crucial for a tool summarizing cross-protocol positions. A 3 reflects the bare minimum viability with clear 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%, with clear descriptions for both parameters ('chain' and 'address'). The description adds no additional parameter semantics beyond what the schema provides, such as format details for 'address' or implications of chain selection. 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 verb ('Get') and resource ('concise overview of a wallet's DeFi positions across all protocols'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'evm_getdefipositionsbyprotocol' or 'evm_getdefisummary', which appear related but have different scopes.
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 siblings like 'evm_getdefipositionsbyprotocol' (positions by protocol) and 'evm_getdefisummary' (DeFi summary), the agent must infer usage from names alone, which is insufficient for reliable 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. It states the tool retrieves details and lists return fields (name, logo, etc.), which is helpful. However, it lacks critical behavioral details such as error handling (e.g., what happens if the ID is invalid), rate limits, authentication requirements, or whether it's a read-only operation. For a tool with no annotations, 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 the core action ('Retrieve details') and includes key return information. Every word serves a purpose with no redundancy, making it easy to parse quickly.
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 low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic purpose and return fields, which is adequate for a simple lookup tool. However, without annotations or output schema, it should ideally mention more behavioral aspects (e.g., read-only nature, error cases) to be fully comprehensive.
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 0% description coverage, so the description must compensate. It adds meaning by specifying that 'entityId' is a 'unique ID' for retrieving a specific entity, which clarifies the parameter's purpose beyond the schema's type definition. However, it doesn't provide format examples (e.g., numeric, string pattern) or constraints, leaving some ambiguity.
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 ('Retrieve details') and resource ('specific entity'), making the purpose evident. It distinguishes from siblings like 'evm_searchentities' (search vs. retrieve by ID) and 'evm_getentitiesbycategory' (by category vs. by ID), though not explicitly named. However, it doesn't specify what an 'entity' is in this context, leaving some ambiguity.
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. The description mentions retrieving by 'unique ID' but doesn't compare it to sibling tools like 'evm_searchentities' for unknown IDs or 'evm_getentitiesbycategory' for category-based retrieval. There's no mention of 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 implies a read-only list operation but doesn't disclose behavioral traits such as pagination (implied by the 'limit' parameter), rate limits, authentication needs, or what 'available categories' entails (e.g., static vs. dynamic). 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, clear sentence with zero waste. It's appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.
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 no annotations, no output schema, and a simple parameter with full schema coverage, the description is minimally adequate but incomplete. It lacks details on return values (e.g., format of categories), behavioral context, and usage guidelines, which are needed for a tool in a complex blockchain context with many siblings.
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 'limit' parameter well-documented in the schema. The description adds no additional meaning beyond the schema, such as default values or typical usage patterns. 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 action ('List available categories') and resource ('for blockchain entities'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'evm_getentitiesbycategory' or 'evm_getvolumestatsbycategory' which also involve categories, missing explicit distinction.
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 sibling tools like 'evm_getentitiesbycategory' and 'evm_searchentities' that might relate to categories, the description lacks context on use cases, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's function but lacks details on rate limits, error handling, response format, or any side effects. For a read operation, 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.
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 any unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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?
For a simple read operation with one well-documented parameter and no output schema, the description is adequate but minimal. It covers the basic purpose but lacks context about the return value (e.g., format of block number) and behavioral aspects, leaving gaps in completeness.
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 'specified blockchain' which aligns with the 'chain' parameter, but adds no additional meaning beyond the schema's 100% coverage. The schema already fully documents the parameter with enum values and description, so the description provides minimal extra value.
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') and resource ('most recent block number for a specified blockchain'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'evm_getblock' which might retrieve more detailed block information, though the name itself suggests a distinction.
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 sibling tools like 'evm_getblock' that might serve similar purposes, nor does it specify any prerequisites or contexts where this tool is preferred over others.
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 the output includes summary stats but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, data freshness, or error conditions. For a tool with no annotations, 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 the core purpose and lists the key stats without unnecessary words. Every part of the sentence earns its place by specifying what is being retrieved and what metrics are included.
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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavioral traits, usage context, and output format. Without annotations or an output schema, the agent must infer behavior from the description alone, which is incomplete for safe and 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 both parameters ('chain' and 'address') with descriptions and enums. The description doesn't add any parameter-specific semantics beyond what the schema provides, such as format examples for the address or clarifications on chain selection. 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's purpose with a specific verb ('Get') and resource ('summary stats by NFT collection'), listing the key metrics returned (total NFT transfers, total tokens, total owners). It distinguishes from many sibling tools focused on different aspects like metadata, trades, or wallets, but doesn't explicitly differentiate from similar collection-level tools like 'evm_getuniqueownersbycollection' or 'evm_getnftcontracttransfers'.
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 explicit guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for usage, or compare it to sibling tools that might overlap (e.g., 'evm_getuniqueownersbycollection' for owner counts or 'evm_getnftcontracttransfers' for transfer data). Usage is implied by the purpose but not elaborated.
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 the tool accesses statistics, implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns real-time or historical data, or handles errors. For a tool with no annotations, 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 the core purpose ('Access key statistics for a token pair') and provides relevant examples without unnecessary details. It is appropriately sized and wastes no words, 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.
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 (2 parameters, no output schema, no annotations), the description is minimally complete. It explains what the tool does but lacks details on output format, error handling, or performance characteristics. Without an output schema, the agent must infer the return structure, which could lead to ambiguity in 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%, with clear descriptions for both parameters: 'address' as 'The pair address' and 'chain' as 'The chain to query'. The description adds no additional semantic context beyond the schema, such as format examples for the address or default behavior for the chain. Baseline 3 is appropriate as the schema adequately documents the parameters.
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: 'Access key statistics for a token pair' with specific examples like price, buyers, sellers, liquidity, and volume. It uses a precise verb ('Access') and resource ('token pair'), but does not explicitly differentiate it from sibling tools like 'evm_getpaircandlesticks' or 'solana_getpairstats', which might offer similar data in different formats or contexts.
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 does not mention sibling tools like 'evm_getpaircandlesticks' for time-series data or 'evm_gettokenpairs' for listing pairs, leaving the agent without context for tool selection. Usage is implied only by the tool's name and description.
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 'ABI-decoded contents' which hints at parsing smart contract data, but doesn't disclose critical behaviors: whether this is a read-only operation (implied by 'Get'), error handling (e.g., for invalid hashes), rate limits, authentication needs, or what the output includes (e.g., decoded function calls, events). For a tool with no 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 the core purpose ('Get the ABI-decoded contents of a transaction') and specifies the key input ('by the given transaction hash'). There is zero waste or redundancy, making it highly concise and well-structured for quick understanding.
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 (fetching and decoding transaction data), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, output format, or error conditions. With 100% schema coverage for inputs, it's complete enough for basic use but insufficient for full agent understanding without external knowledge.
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 all parameters well-documented in the schema itself (chain, transaction_hash, include). The description adds no additional parameter semantics beyond implying the transaction_hash is used to fetch the transaction. Since the schema does the heavy lifting, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given the comprehensive schema.
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') and the resource ('ABI-decoded contents of a transaction'), specifying it's for a given transaction hash. It distinguishes from generic transaction lookups by mentioning ABI-decoded contents, but doesn't explicitly differentiate from potential siblings like 'evm_gettransaction' (if it existed) or other transaction-related tools in the list.
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 prerequisites (e.g., needing a transaction hash), compare it to other transaction tools (none are in the sibling list, but general context is missing), or specify use cases beyond the basic action. The agent must infer usage solely from the purpose statement.
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 the output includes 'first and last seen timestamps' and cross-chain querying, but does not cover critical aspects like rate limits, authentication needs, error handling, or pagination. For a read operation with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the tool's purpose and a key parameter option. There is no wasted text, but it could be slightly more structured by explicitly separating core functionality from parameter guidance.
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 tool that returns wallet activity data. It lacks details on output format (e.g., structure of the list, timestamp formats), error cases, or any behavioral constraints like rate limits. This makes it inadequate for full contextual understanding, especially compared to sibling tools that might have richer descriptions.
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 clear docs for 'address' and 'chains' parameters. The description adds minimal value by hinting at cross-chain querying with 'chains', but does not provide additional semantics beyond what the schema already states (e.g., format details or usage examples). 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.
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: 'List the blockchain networks a wallet is active on, including their first and last seen timestamps.' It specifies the verb ('List'), resource ('blockchain networks'), and scope ('a wallet is active on'), but does not explicitly differentiate it from sibling tools like 'evm_getwallethistory' or 'evm_getwalletstats', which might overlap in wallet-related queries.
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 by mentioning 'Options to query cross-chain using the `chains` parameter,' which suggests when to use this parameter for filtering. However, it does not provide explicit guidance on when to choose this tool over alternatives (e.g., vs. 'evm_getwallethistory' for transaction history) or any exclusions, leaving usage context somewhat inferred.
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 lacks behavioral details. It doesn't disclose rate limits, authentication needs, error handling, or response format. The mention of 'usd and native' prices hints at output structure, but without an output schema, this is insufficient for a mutation-free read operation.
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 front-loads the core purpose and includes key details (USD/native prices, contract address, network) without unnecessary elaboration.
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?
For a read-only tool with 100% schema coverage but no output schema or annotations, the description is minimally adequate. It covers the basic purpose but lacks behavioral context, usage guidelines, and output details, leaving gaps in completeness despite the concise structure.
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 implying that 'contract address' relates to the 'addresses' array, which is already clear from the schema. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and resource ('token price for a given contract address and network'), specifying both USD and native prices. It distinguishes from the sibling 'solana_gettokenprice' by indicating multiple token prices, but doesn't explicitly contrast with other price-related tools like 'evm_getmultipletokenprices'.
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 on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, error conditions, or compare with similar tools like 'solana_gettokenprice' (single vs. multiple) or 'evm_getmultipletokenprices' (EVM vs. Solana).
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 what data is returned without behavioral details. It doesn't disclose error conditions (e.g., invalid address handling), rate limits, authentication needs, performance characteristics, or whether it's a read-only operation (implied by 'Gets' but not explicit).
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?
Single sentence efficiently conveys core purpose with zero wasted words. Front-loaded with the main action ('Gets'), followed by resource and key metadata fields. No structural issues or redundancy.
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?
For a read operation with 3 parameters (2 required) and 100% schema coverage, the description is minimally adequate but lacks context. No output schema exists, so return format isn't described (e.g., JSON structure). It doesn't cover error cases, network-specific behaviors, or how 'mediaItems' affects 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%, so parameters are well-documented in the schema. The description adds no additional parameter context beyond implying the 'address' is for a contract and 'mediaItems' relates to media in metadata. Since schema does the heavy lifting, 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 action ('Gets') and the resource ('contract level metadata'), specifying what metadata fields are returned (mint, standard, name, symbol, metaplex). It distinguishes this as a Solana-specific tool from its sibling 'evm_getnftmetadata', but doesn't explicitly differentiate from other Solana NFT tools like 'solana_getnfts' or 'solana_gettokenmetadata' in usage context.
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. It doesn't mention prerequisites (e.g., needing a valid Solana NFT contract address), contrast with similar tools (e.g., 'solana_getnfts' for multiple NFTs vs. this for single contract metadata), or specify use cases (e.g., for verifying NFT collection details).
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 retrieves metadata but lacks details on behavioral traits such as rate limits, error handling, authentication needs, or response format. This is a significant gap for a tool with no structured safety or operational 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 with zero waste. It front-loads the core action ('Get the global token metadata') and includes essential details without redundancy, making it easy to parse quickly.
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 no annotations and no output schema, the description is moderately complete for a simple query tool. It specifies the purpose and parameters but lacks behavioral context and output details. For a tool with 2 parameters and 100% schema coverage, it meets minimum viability but could improve by adding usage or response information.
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 clear descriptions for both parameters ('network' and 'address'). The description adds minimal value beyond the schema by mentioning 'network and contract' and listing metadata fields, but it doesn't explain parameter interactions or provide examples. 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.
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 ('global token metadata'), specifying the target (network and contract) and listing key metadata fields (mint, standard, name, symbol, metaplex). It distinguishes from sibling tools like 'solana_gettokenprice' or 'solana_gettokenholders' by focusing on metadata retrieval, though it doesn't explicitly contrast with 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. While the description implies it's for token metadata, it doesn't mention prerequisites, when not to use it, or direct comparisons to similar tools like 'evm_gettokenmetadata' or 'solana_getnftmetadata', leaving the agent to infer context from tool names 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?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions timeseries data and change metrics but doesn't disclose whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or pagination behavior (despite the cursor parameter).
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 perfectly concise with two clear sentences that directly explain the tool's purpose and capabilities without any redundant information. Every word earns its place in communicating 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?
For a complex tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the output looks like (timeseries format, metrics structure), doesn't address behavioral aspects like rate limits or data availability, and leaves the agent guessing about practical usage despite good schema coverage.
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 parameters are well-documented in the schema. The description adds marginal value by implying the tool uses 'timeseries data' which relates to timeFrame and date parameters, but doesn't provide additional semantics beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 with specific verbs ('track changes') and resources ('holder base of an ERC20 token over time'), and distinguishes it from siblings like 'evm_gettokenholders' by specifying historical/timeseries analysis rather than current snapshot data.
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 'evm_gettokenholders' or 'evm_gettimeseriestokenanalytics', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.
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 states what the tool returns (last, lowest, highest, average sale prices, and total trades) but lacks critical details: it doesn't specify if this is a read-only operation (implied by 'fetch'), whether it requires authentication, rate limits, error conditions, or the data format (e.g., currency units, pagination). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and output. It front-loads the core action ('Fetch sale prices'), specifies the scope ('for NFTs in a contract over a specified number of days'), and lists the return values without unnecessary details. Every word earns its place, making it highly concise.
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 fetching financial metrics for NFTs, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., numeric values, timestamps, error handling), behavioral traits like rate limits, or prerequisites (e.g., API keys). For a tool with 3 parameters and no structured output definition, more contextual information is needed to ensure reliable 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 input schema has 100% description coverage, with clear documentation for 'chain', 'days', and 'address'. The description adds no additional parameter semantics beyond what's in the schema—it mentions 'specified number of days' and 'contract' but doesn't clarify parameter interactions or constraints. With high schema coverage, the baseline score of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Fetch sale prices for NFTs in a contract'), identifies the resource (NFTs in a contract), and specifies the temporal scope ('over a specified number of days'). It distinguishes itself from sibling tools like 'evm_getnftcollectionstats' or 'evm_getnftfloorpricebycontract' by focusing on sale price metrics rather than general stats or floor prices.
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 does not mention sibling tools like 'evm_getnftsaleprices' (which might be for individual NFTs) or 'evm_getnfttrades' (which could provide raw trade data), leaving the agent without context for tool selection. The only implied usage is for analyzing NFT contract sale prices over time.
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 filtering options but fails to disclose critical behavioral traits such as pagination behavior (implied by 'cursor' parameter), rate limits, authentication requirements, error handling, or the structure of returned data. This leaves significant gaps for an agent to understand how the tool behaves.
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 the core purpose and briefly mentions filtering options. There is no wasted language, and it's appropriately sized for the tool's complexity.
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 incomplete. It doesn't explain the return format, pagination, error cases, or performance characteristics. For a data-fetching tool with many parameters, more context is needed to guide effective 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 11 parameters thoroughly. The description adds minimal value by listing filter types ('date, token, or other parameters'), but doesn't provide additional syntax, examples, or constraints beyond what's in the schema. This meets the baseline for high schema coverage.
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 ('NFT transfers for a contract'), making the purpose specific. It distinguishes this tool from siblings like 'evm_getnfttrades' or 'evm_gettokentransfers' by focusing on contract-level NFT transfers, though it doesn't explicitly name alternatives.
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 through the phrase 'with options to filter by date, token, or other parameters,' suggesting when to use it for filtered queries. However, it lacks explicit guidance on when to choose this tool over alternatives like 'evm_getnfttrades' or 'evm_gettokentransfers,' and doesn't 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions listing transactions with optional filtering, but doesn't describe pagination behavior (cursor/limit parameters), rate limits, authentication requirements, error handling, or what the response format looks like. For a tool with 11 parameters and no output schema, 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 with just two sentences that efficiently communicate the core functionality and optional filtering. Every word earns its place, and the information is front-loaded with no wasted verbiage or redundancy.
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 (11 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain the response format, pagination behavior, error conditions, or how parameters like 'fromBlock'/'fromDate' interact. For a data retrieval tool with many filtering options, users need more context about what to expect from the 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%, so the schema already documents all 11 parameters thoroughly. The description adds minimal value beyond the schema by mentioning the optional tokenAddress filter, but doesn't provide additional context about parameter interactions, dependencies, or usage patterns. This meets the baseline for high schema coverage.
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: 'List all swap transactions (buy/sell) for a specific wallet' with optional filtering by token address. It specifies the verb ('List'), resource ('swap transactions'), and scope ('for a specific wallet'), but doesn't explicitly differentiate from sibling tools like 'evm_getswapsbypairaddress' or 'evm_getswapsbytokenaddress' beyond the wallet focus.
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 context by mentioning optional filtering by token address, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'evm_getswapsbypairaddress' or 'evm_getswapsbytokenaddress'. It also doesn't mention prerequisites or exclusions, leaving usage context partially implied rather than clearly defined.
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 states the tool fetches data (implying read-only), but doesn't describe response format, pagination, rate limits, authentication needs, or error conditions. For a timeseries query tool with zero 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 front-loads the core purpose and includes the optional parameter note. Every word contributes directly to understanding the tool's function with zero wasted text.
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 timeseries data fetching tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the returned data structure looks like, time granularity, how 'FDV' is calculated, or any limitations. The high schema coverage helps with inputs, but the overall context for proper tool invocation remains incomplete.
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 all parameters well-documented in the schema itself. The description adds minimal value by mentioning the optional 'chain' filter, but doesn't provide additional context about parameter interactions, default behaviors, or the meaning of 'categoryId' beyond what's in the schema.
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 ('Fetch') and the specific data returned ('timeseries buy volume, sell volume, liquidity and FDV'), with the target resource being 'a specific category'. It distinguishes from siblings like 'evm_gettimeseriesvolume' (which appears to be general volume) by specifying 'by category', but doesn't explicitly contrast with other category-related tools like 'evm_getvolumestatsbycategory'.
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 when timeseries metrics for a category are needed, and mentions optional chain filtering. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'evm_getvolumestatsbycategory' or 'evm_gettimeseriestokenanalytics', 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 the full burden of behavioral disclosure. It only states what the tool does without detailing behavioral traits such as rate limits, authentication requirements, pagination, or the format of returned data. For a tool with zero annotation coverage, this is a significant gap, leaving the agent with insufficient information about 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: 'Get cryptocurrencies with the highest 24 hour trading volume.' It is front-loaded with the core purpose, contains no unnecessary words, and effectively communicates the tool's function without redundancy or fluff, 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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose clearly but lacks behavioral details and usage guidelines. While it meets basic requirements for a simple tool, it does not provide enough context for an agent to fully understand operational aspects like data format or constraints, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% schema description coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since none exist. This aligns with the tool's simplicity, and the description does not need to compensate for missing parameter details, earning a baseline score of 4 for clarity in this context.
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: 'Get cryptocurrencies with the highest 24 hour trading volume.' It specifies the action ('Get'), resource ('cryptocurrencies'), and scope ('highest 24 hour trading volume'), which is specific and actionable. However, it does not explicitly distinguish itself from sibling tools like 'evm_gettopcryptocurrenciesbymarketcap', which serves a similar ranking purpose but by a different metric.
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 does not mention any prerequisites, context, or exclusions, nor does it reference sibling tools that might be more appropriate in certain scenarios. For example, it does not clarify when to choose this over 'evm_gettopcryptocurrenciesbymarketcap' or other ranking tools in the 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?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions 'complete decoded transaction history' but doesn't disclose pagination behavior (implied by 'cursor' parameter), rate limits, authentication requirements, or whether it's a read-only operation. The description adds minimal context beyond basic functionality, leaving gaps for a tool with 11 parameters.
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 the core purpose ('Get the complete decoded transaction history for a given wallet') and adds clarifying details without redundancy. Every word earns its place, making it easy to parse while conveying key features like decoding and summarization.
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 complex tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return format, error conditions, or behavioral constraints like rate limits. While concise, it fails to provide the necessary context for safe and effective use, especially given the lack of structured metadata.
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 11 parameters. The description adds no parameter-specific information beyond implying the 'address' parameter is required and that results are 'human-readable'. It doesn't explain parameter interactions or provide examples, so it meets the baseline for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 with specific verbs ('get', 'parsed', 'decoded', 'categorized', 'summarized') and resource ('complete decoded transaction history for a given wallet'). It distinguishes itself from sibling tools like evm_gettransactionverbose (single transaction) or evm_gettokentransfers (token-specific) by emphasizing comprehensive wallet history with human-readable summaries.
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 sibling tools like evm_getwalletnfts (NFT-specific) or evm_getwalletstats (statistical summary), nor does it specify prerequisites such as wallet address format or chain compatibility. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 cross-chain support, filtering, and sorting options, but doesn't cover critical aspects like rate limits, authentication needs, pagination behavior (despite a 'limit' parameter), error handling, or what the output looks like. For a search tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 appropriately sized with two sentences that efficiently convey key information: the search functionality and additional options. It's front-loaded with the core purpose and avoids unnecessary details. However, it could be slightly more structured by separating cross-chain behavior from filtering/sorting, but overall it's concise and effective.
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 complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers the search scope and some behavioral traits but misses details like output format, pagination, and error handling. Without annotations or an output schema, the description should do more to compensate, but it provides a basic understanding, making it adequate but with clear 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%, meaning all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning 'chains' filtering and 'sortBy' options, but doesn't provide additional context like examples or usage tips. With high schema coverage, the baseline is 3, and 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.
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: 'Search for tokens using their contract address, pair address, name, or symbol.' It specifies the verb ('search') and resource ('tokens') with search criteria. However, it doesn't explicitly differentiate from sibling tools like 'evm_getfilteredtokens' or 'evm_getdiscoverytoken', which appear related, so it doesn't reach the highest score.
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 provides some implied usage context by mentioning 'cross-chain by default' and the ability to filter by chains and sort by metrics. However, it doesn't explicitly state when to use this tool versus alternatives like 'evm_getfilteredtokens' or 'evm_gettrendingtokensv2', nor does it provide exclusions or prerequisites. The guidance is present but not comprehensive.
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 states what data is retrieved but doesn't mention important behavioral aspects like pagination behavior (implied by cursor parameter but not explained), rate limits, authentication requirements, error conditions, or response format. The description is minimal and lacks operational context.
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 unnecessary words. It's appropriately sized for a data retrieval tool and front-loads the essential information about what transactions are retrieved and for what resource.
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 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the response structure, pagination behavior, or operational constraints. While the schema covers parameters well, the description fails to provide the contextual information needed to use this tool effectively in practice.
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?
With 100% schema description coverage, the schema already documents all 8 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'pair address' which is already covered, but provides no additional context about parameter interactions, defaults, or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 ('all swap related transactions') with specific scope ('for a specific pair address'), listing the exact transaction types included (buy, sell, add liquidity, remove liquidity). It distinguishes from sibling tools like solana_getswapsbytokenaddress and solana_getswapsbywalletaddress by specifying it's for pair addresses rather than token or wallet addresses.
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. While it implicitly indicates this is for pair addresses, it doesn't mention when to choose this over other swap-related tools like solana_getswapsbytokenaddress or solana_getswapsbywalletaddress, nor does it discuss prerequisites or limitations.
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 the Ethereum limitation, which is useful context, but fails to describe other key behaviors: it doesn't specify if this is a read-only operation, what the output format looks like (e.g., list of collections with volume data), whether there are rate limits, or how results are sorted (e.g., by volume descending). For a 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 highly concise and well-structured: two sentences that directly state the tool's purpose and its limitation. Every word earns its place, with no redundancy or fluff. It's front-loaded with the core functionality, 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 (a data retrieval tool for NFT collections) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of collections with names and volumes), how results are sorted or limited, or any error conditions. For a tool that likely returns structured data, more context is needed to use it effectively, especially without an output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate since none exist. It adds value by clarifying the scope (24-hour trading volume, Ethereum-only), but since there are no parameters to explain, a baseline of 4 is applied as it adequately addresses the lack of parameters.
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: 'Get NFT collections by their 24 hour trading volume.' It specifies the verb ('Get'), resource ('NFT collections'), and metric ('24 hour trading volume'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'evm_gettopnftcollectionsbymarketcap' or 'evm_getnftcollectionstats', which reduces it from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage guideline: 'Currently only supports Ethereum.' This provides context about limitations. However, it doesn't specify when to use this tool versus alternatives like 'evm_gettopnftcollectionsbymarketcap' or other NFT-related tools, nor does it mention prerequisites or exclusions. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the array limit (up to 200 tokens) and required fields (chain, tokenAddress), but does not disclose behavioral traits such as rate limits, authentication needs, response format, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its operation.
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 front-loaded with key information (purpose and parameters) in two sentences, with no wasted words. It efficiently conveys the tool's function and input requirements, though it could be slightly more structured for clarity.
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 lacks details on response format, error conditions, rate limits, and authentication requirements. For a tool fetching analytics for multiple tokens, this leaves the agent without sufficient context to handle 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%, with the schema fully documenting the tokens array, chain, and tokenAddress parameters. The description adds minimal value beyond the schema, mentioning the array limit and required fields, which are already covered. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch') and resource ('analytics for multiple tokens'), specifying the analytics types (buy volume, sell volume, buyers, sellers, transactions, liquidity, FDV trends over time). It distinguishes from siblings like evm_gettimeseriestokenanalytics by emphasizing batch processing of multiple tokens rather than time-series for a single token.
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 batch token analytics but does not explicitly state when to use this tool versus alternatives like evm_gettimeseriestokenanalytics or evm_gettokenmetadata. It mentions the array limit of up to 200 tokens, which provides some context, but lacks explicit guidance on prerequisites or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses that data 'Refreshes every 30 minutes,' which is a useful behavioral trait regarding update frequency. However, it lacks details on error handling, rate limits, authentication needs, or what the output looks like (e.g., price format, units). This partial disclosure is adequate but leaves gaps for a tool with no annotations.
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 and front-loaded: 'Get floor price for a given collection. Refreshes every 30 minutes.' Both sentences earn their place by stating the core purpose and a key behavioral trait. There is no wasted text, making it efficient and well-structured for quick understanding.
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 (2 parameters, no output schema, no annotations), the description is minimally complete. It covers the basic purpose and a freshness constraint but lacks details on output format, error cases, or integration with sibling tools. Without annotations or output schema, more context would be beneficial, but it meets a baseline adequacy for a simple query tool.
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 clear descriptions for 'chain' and 'address'. The description does not add any parameter-specific details beyond the schema, such as examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract from the schema's 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: 'Get floor price for a given collection.' It specifies the verb ('Get') and resource ('floor price'), but does not explicitly differentiate from sibling tools like 'evm_getnftcollectionstats' or 'evm_getnfthistoricalfloorpricebycontract', which might also provide floor price-related data. This makes it clear but not fully distinguished from 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 'Refreshes every 30 minutes,' which hints at data freshness, but does not specify use cases, prerequisites, or comparisons to siblings like 'evm_getnftcollectionstats' or 'evm_getnfthistoricalfloorpricebycontract'. This lack of explicit when-to-use or alternative recommendations results in minimal guidance.
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 what metrics are returned (last/lowest/highest sale, average, total trades). It doesn't disclose behavioral traits like rate limits, authentication needs, error conditions, data freshness, or whether it's a read-only operation. The description is functional but lacks operational context.
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 perfectly concise with two sentences: one stating the purpose and parameters, another listing the returned metrics. Every word earns its place with zero waste, and information is front-loaded appropriately.
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?
For a tool with 4 parameters, 100% schema coverage, but no annotations or output schema, the description adequately covers the basic purpose and return metrics. However, it lacks context about the tool's behavior, error handling, and practical usage scenarios that would be helpful given the complexity of NFT price data.
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 parameters are well-documented in the schema. The description adds minimal value beyond the schema by implying the 'days' parameter affects the aggregation period, but doesn't explain parameter interactions or provide additional context. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Fetch sale prices'), target resource ('for a specific NFT'), and scope ('over a specified number of days'). It distinguishes from siblings like 'evm_getnftcollectionstats' (collection-level) and 'evm_getnfttrades' (raw trades) by focusing on aggregated price metrics for a single NFT.
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 'evm_getnftcontractsaleprices' (contract-level) or 'evm_getnfttrades' (transaction-level). It mentions the time period parameter but doesn't explain use cases, prerequisites, or comparisons with sibling tools.
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 that results include metadata, floor prices, and more, but fails to describe critical behaviors: pagination (implied by 'cursor' parameter but not explained), rate limits, authentication requirements, error handling, or response format. For a read operation with 7 parameters, 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, well-structured sentence that efficiently conveys the core purpose and key result attributes. It's front-loaded with the main action and resource, and every phrase ('on-chain metadata as well as off-chain metadata, floor prices and more') adds useful context without redundancy.
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 complexity (7 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and result types but lacks critical context: no output format details, no pagination explanation, no error or limit behaviors. It meets the bare minimum for a read operation but doesn't fully compensate for the missing structured data.
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 7 parameters. The description adds marginal value by implying the scope ('all NFT Collections') and hinting at result content ('on-chain metadata, off-chain metadata, floor prices'), but doesn't provide additional syntax, format details, or usage examples beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 with a specific verb ('Fetch') and resource ('all NFT Collections held by a specified wallet address'), distinguishing it from siblings like 'evm_getwalletnfts' (which fetches individual NFTs) and 'evm_getnftcollectionstats' (which fetches stats for specific collections). It precisely defines the scope as collections rather than individual tokens.
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 sibling tools like 'evm_getwalletnfts' (for individual NFTs) or 'evm_getnftcollectionstats' (for collection statistics), nor does it specify prerequisites or exclusions. Usage is implied only by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a read operation (implied by 'retrieve'), supports up to 100 tokens (though the schema says 30), includes metadata and spam status, and offers filtering options. However, it lacks details on rate limits, error handling, authentication needs, or response format, which are 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded, with the core purpose in the first sentence. However, it could be more structured: the second sentence mixes parameter details with return value information, and the token limit is inconsistent (100 in description vs. 30 in schema). Most sentences earn their place, but there's minor redundancy and disorganization.
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 (5 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose, basic usage, and some behavioral aspects, but lacks output format details, error handling, and explicit differentiation from siblings. Without annotations or output schema, the agent must infer behavior, leaving gaps in understanding the full tool 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 documents all parameters thoroughly. The description adds marginal value by mentioning 'optional fields such as `to_block` or `exchange`' and 'Additional options to exclude low-liquidity tokens and inactive tokens,' which loosely map to parameters but don't provide syntax or format details beyond what the schema provides. 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's purpose: 'Retrieve the current or historical prices for multiple ERC20 tokens in the blockchain’s native currency and USD.' It specifies the verb ('retrieve'), resource ('prices for multiple ERC20 tokens'), and scope ('current or historical'), but doesn't explicitly differentiate from sibling tools like 'evm_gettokenmetadata' or 'solana_getmultipletokenprices' beyond the multi-token focus.
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 price retrieval of multiple tokens, with optional historical data via 'to_block' and exchange filtering. However, it doesn't explicitly state when to use this tool versus alternatives like 'evm_gettokenmetadata' for single tokens or 'evm_gettopcryptocurrenciesbymarketcap' for aggregated data, nor does it mention prerequisites or exclusions beyond the optional filters for low-liquidity/inactive tokens.
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 the token limit (200) but does not disclose other behavioral traits such as rate limits, authentication needs, error handling, or response format. For a data-fetching tool with no annotation coverage, this leaves significant gaps in understanding its operation.
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 the purpose and key constraint. Every word earns its place with no redundancy, 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 fetching timeseries analytics for multiple tokens, no annotations, and no output schema, the description is incomplete. It lacks details on response structure, error conditions, rate limits, and how the metrics are calculated or returned, which are crucial 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%, so the schema fully documents both parameters. The description adds minimal value by mentioning the token array requirement and its structure, but does not provide additional semantics beyond what the schema already specifies. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Fetch'), the resource ('timeseries buy volume, sell volume, liquidity and FDV'), and the scope ('for multiple tokens'). It distinguishes from siblings like 'evm_getmultipletokenanalytics' (likely cross-sectional) by specifying timeseries data, and from 'evm_gettimeseriesvolume' by listing additional metrics beyond volume.
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 timeseries analytics on tokens, but does not explicitly state when to use this tool versus alternatives like 'evm_getmultipletokenanalytics' or 'evm_gettimeseriesvolume'. It mentions the token array constraint, but lacks guidance on 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 the full burden. It mentions the Ethereum limitation, which is useful context, but fails to disclose critical behavioral traits such as whether this is a read-only operation, rate limits, data freshness, or what 'top' means (e.g., number of results, sorting criteria). 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 two sentences, front-loaded with the core purpose and followed by a key limitation. Every word earns its place with no redundancy or fluff, making it highly efficient 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 0 parameters and no output schema, the description is minimally complete for a simple query tool. It covers the purpose and a key limitation, but without annotations or output details, it lacks information on behavioral aspects like safety, performance, or result format. This is adequate but leaves room for improvement in transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it does include the Ethereum constraint, which slightly enhances context beyond the schema. Baseline is 3 for high schema coverage, but the added constraint justifies a 4.
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 top NFT collections') and the resource ('by their current market cap'), making the purpose specific and understandable. It distinguishes from siblings like 'evm_gethottestnftcollectionsbytradingvolume' by focusing on market cap rather than trading volume, though it doesn't explicitly name alternatives.
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 when market cap ranking is needed, and the limitation 'Currently only supports Ethereum' provides some context for when not to use it (e.g., for other blockchains). However, it lacks explicit guidance on when to choose this over similar tools like 'evm_gettopcryptocurrenciesbymarketcap' or 'evm_gettoperc20tokensbymarketcap'.
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 that it 'Returns data for all chains in a single request,' which adds useful context about scope and efficiency. However, it lacks details on rate limits, authentication needs, error conditions, or the format/structure of the returned data, which are important for a tool with 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 two sentences that are front-loaded with the core purpose and efficiently add context about multi-chain returns. Every word contributes value without redundancy or unnecessary elaboration.
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 has no parameters (simplifying input) but also no annotations and no output schema, the description is moderately complete. It covers what data is retrieved and the multi-chain scope, but it lacks details on behavioral aspects like performance, errors, or data format, which are needed for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied since there are no parameters to document.
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 'Retrieve' and specifies the resources: 'volume, active wallets and transaction stats for a blockchain over various time periods.' It distinguishes from siblings by focusing on aggregated blockchain statistics rather than specific entities or transactions. However, it doesn't explicitly differentiate from similar tools like 'evm_gettimeseriesvolume' or 'evm_getwalletstats'.
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 retrieving aggregated blockchain statistics over time periods, which suggests when to use it. However, it doesn't provide explicit guidance on when to choose this tool versus alternatives like 'evm_gettimeseriesvolume' or 'evm_getwalletstats', nor does it mention any 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data (implying read-only) but does not specify rate limits, authentication needs, data freshness, or error conditions, leaving significant gaps for a tool with financial data.
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 the core purpose and includes key optional parameters, with no redundant or unnecessary 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?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return format (e.g., structure of P&L breakdown), error handling, and behavioral constraints, which are critical for proper 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by mentioning the optional filter by token_addresses and timeframe, but does not provide additional context beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 with specific verbs ('Get a detailed profit and loss breakdown') and resources ('by token for a given wallet'), distinguishing it from siblings like evm_getwalletnetworth or evm_getwalletprofitabilitysummary by focusing on token-level P&L over a timeframe.
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 retrieving token-level P&L over a timeframe, but does not explicitly state when to use this tool versus alternatives like evm_getwalletprofitabilitysummary or evm_getwallethistory, 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions batch capability ('one or many') but doesn't disclose rate limits, authentication requirements, error conditions, response format, or that balances are checked at a specific block (implied by parameter but not described). For a read operation with no 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 front-loads the core purpose and includes all essential elements (action, resource, scope) without unnecessary elaboration.
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?
For a 3-parameter tool with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose but lacks crucial context about response format, error handling, rate limits, and detailed usage scenarios. The high schema coverage helps, but behavioral transparency remains a significant gap.
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 parameters are well-documented in the schema. The description adds marginal value by implying 'one or many' addresses relates to the 'wallet_addresses' array and mentioning native tokens (e.g., ETH) which contextualizes the 'chain' parameter. However, it doesn't explain parameter interactions or provide additional semantic context beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve'), resource ('native token balances'), and scope ('for one or many wallet addresses in single request'). It distinguishes from siblings like 'evm_getwallettokenbalancesprice' by focusing specifically on native tokens rather than all token balances.
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 context through 'in single request' suggesting batch efficiency, but provides no explicit guidance on when to use this tool versus alternatives like 'evm_getwallettokenbalancesprice' or 'solana_balance'. No prerequisites, exclusions, or comparative advantages are mentioned.
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 basic conversion function. It lacks disclosure of behavioral traits like rate limits, authentication needs, error handling for unregistered addresses, response format, or performance characteristics. The description doesn't contradict annotations, but provides minimal behavioral context.
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 the core purpose without unnecessary words. Every element ('Convert,' 'Ethereum address,' 'ENS domain,' 'if registered') earns its place, making it maximally concise while remaining clear.
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?
For a single-parameter tool with no annotations and no output schema, the description covers the basic purpose adequately but lacks completeness regarding behavioral aspects and output details. It doesn't explain what happens when an address isn't registered or what the return format looks like, leaving gaps in contextual understanding.
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 one parameter clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema already provides (e.g., address format requirements, validation rules). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Convert an Ethereum address') and target resource ('to its associated ENS domain'), with the conditional outcome ('if registered') providing precise scope. It effectively distinguishes from sibling tools like 'evm_resolveensdomain' which performs the reverse operation.
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 address-to-ENS resolution but doesn't explicitly state when to use this tool versus alternatives or provide any exclusions. The conditional 'if registered' hints at a limitation, but no explicit guidance on prerequisites or error cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 behavioral aspects like returning metadata, logos, spam status, and filtering options, which is helpful. However, it lacks details on rate limits, error conditions, pagination behavior (implied by 'cursor' parameter but not explained), or performance characteristics, leaving gaps for a tool with 11 parameters.
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 front-loaded with the core purpose and key features in the first sentence, followed by additional options. It uses two sentences efficiently with no redundant information, though it could be slightly more structured by explicitly grouping related filtering options.
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 complexity (11 parameters, no annotations, no output schema), the description is moderately complete. It covers the main purpose and filtering features but lacks details on output format, error handling, or pagination behavior. For a tool with this many parameters and no structured output schema, more contextual information would be beneficial.
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 marginal value by mentioning filtering options like excluding spam, low-liquidity, and inactive tokens, which map to parameters like 'exclude_spam' and 'min_pair_side_liquidity_usd', but does not provide additional semantic context beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Fetch'), resource ('ERC20 and native token balances for a given wallet address'), and includes key features like USD prices and metadata. It effectively distinguishes this from sibling tools like 'evm_getnativebalancesforaddresses' (native only) or 'evm_getfilteredtokens' (general token filtering) by emphasizing comprehensive wallet balance retrieval with pricing.
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 retrieving wallet balances with pricing and filtering options, but does not explicitly state when to use this tool versus alternatives like 'evm_getwalletnetworth' (net worth focus) or 'evm_getwalletstats' (statistical overview). It mentions filtering capabilities but lacks clear guidance on scenarios where this tool is preferred over others.
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 retrieving 'comprehensive details' but doesn't specify what 'comprehensive' includes (e.g., token supply, decimals, contract info), whether it's a read-only operation, potential rate limits, or error conditions. The description lacks behavioral details needed for safe invocation.
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 highly concise and front-loaded: the first sentence states the core purpose, and the following sentences provide essential usage guidelines. Every sentence adds value without redundancy, making it efficient for an agent to parse.
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 no annotations and no output schema, the description should do more to explain behavioral aspects and return values. It covers purpose and usage guidelines well but lacks details on what 'comprehensive details' includes, error handling, or response format, leaving gaps for a tool with two required 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?
Schema description coverage is 100%, so the schema already documents both parameters ('chain' and 'token_address') with descriptions and enum values. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
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: 'Retrieve comprehensive details for a specific token, including metadata and stats.' It specifies the verb ('retrieve'), resource ('token'), and scope ('comprehensive details'). However, it doesn't explicitly differentiate from similar siblings like 'evm_gettokenmetadata' or 'evm_gettokenpairs', which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives: 'For more detailed tokens stats we recommended to use `getTokenAnalytics` or `getMultipleTokenAnalytics`. For pair stats, we recommend to use `getPairStats`.' This clearly defines the tool's scope relative to other options, helping the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the bulk nature (up to 25 contracts) and lists returned data types (name, symbol, off-chain metadata, floor prices). However, it doesn't mention rate limits, authentication requirements, error conditions, or response format details that would be helpful for an agent.
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 perfectly concise with two sentences that efficiently convey the tool's purpose and capabilities. The first sentence establishes the core functionality, and the second adds valuable context about additional data returned. No wasted words or redundancy.
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?
For a tool with 3 parameters, 100% schema coverage, but no output schema or annotations, the description provides adequate but minimal context. It covers what the tool does and what data it returns, but doesn't address behavioral aspects like error handling, rate limits, or response structure that would be helpful given the lack of output schema.
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 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve metadata'), resource ('NFT contracts'), and scope ('up to 25 NFT contracts in one call'). It distinguishes from sibling tools like 'evm_getnftmetadata' by emphasizing bulk retrieval and listing additional data fields returned.
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 context by mentioning bulk retrieval (up to 25 contracts) and listing returned data fields, but doesn't explicitly state when to use this tool versus alternatives like 'evm_getnftmetadata' or 'evm_getnftcollectionstats'. No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 the default behavior (cross-chain results including Solana) and optional filtering by chain, which adds useful context. However, it lacks details on rate limits, authentication needs, pagination (implied by the limit parameter but not explained), or what 'trending' specifically entails (e.g., time frame, algorithm). For a tool with no annotations, this leaves gaps in understanding its operational 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 concise and well-structured, consisting of two sentences that efficiently convey key information: the tool's purpose and its usage guidelines. Every sentence earns its place, with no wasted words, and it is front-loaded with the core functionality. This makes it easy for an AI agent to quickly grasp the tool's intent and parameters.
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 complexity of a trending tokens tool with 2 parameters, no annotations, and no output schema, the description is moderately complete. It covers the purpose and basic usage but lacks details on behavioral aspects like rate limits, authentication, or output format. While it compensates somewhat by explaining the chain parameter's semantics, it doesn't fully address the gaps left by the absence of annotations and output schema, making it adequate but with room for improvement.
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 both parameters ('chain' and 'limit') well-documented in the schema itself. The description adds value by explaining the default cross-chain behavior and optional filtering by 'chain', which clarifies the semantic use of the chain parameter beyond the enum list. However, it doesn't provide additional details on the 'limit' parameter or any constraints not already in the schema. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'List top tokens trending based on trading activity, volume, liquidity and more.' It specifies the verb ('List') and resource ('top tokens trending'), and mentions the criteria (trading activity, volume, liquidity). However, it doesn't explicitly differentiate from sibling tools like 'evm_gettopgainerstokens' or 'evm_gettoploserstokens', which might also involve trending or performance metrics, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'By default this returns cross-chain results, including Solana. Optionally filter by `chain` for single chain results.' This indicates when to use the tool (for trending tokens across chains or filtered by chain) and implies an alternative (using the chain parameter for single-chain results). However, it doesn't explicitly state when not to use it or compare it to other trending-related siblings, such as 'evm_gettopcryptocurrenciesbytradingvolume', which might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses key behavioral traits: the tool returns detailed token data including trading metrics and metadata, supports advanced filters (e.g., whale holdings, category exclusion), and handles time-based analytics. However, it lacks details on rate limits, pagination, error conditions, or authentication requirements, which are important for a complex query 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 appropriately sized and front-loaded: the first sentence captures the core functionality, followed by specifics on filters, use cases, and output details. Every sentence adds value, but it could be slightly more concise by integrating the use-case sentence more tightly with the purpose statement.
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 complexity of the tool (multiple parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, filtering capabilities, use cases, and output content, but lacks details on response format, error handling, or performance considerations. Without an output schema, more information on return structure would be beneficial for full completeness.
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 parameters thoroughly. The description adds some context by mentioning 'advanced filters (e.g. “top 10 whales hold <40%”), category-based inclusion/exclusion,' which helps interpret the 'filters' and 'categories' parameters. However, it does not provide additional syntax or examples beyond what the schema enumerates, 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.
Purpose5/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: 'Fetch a list of tokens across multiple chains, filtered and ranked by dynamic on-chain metrics.' It specifies the action (fetch), resource (tokens), scope (multiple chains), and filtering mechanism (metrics like volume, price change, liquidity). It distinguishes from siblings by emphasizing advanced filtering capabilities not present in simpler token tools like evm_searchtokens or evm_gettopcryptocurrenciesbymarketcap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Ideal for token discovery, investor research, risk analysis, and portfolio tools.' It implicitly suggests when to use this tool (for detailed filtered analysis) versus simpler alternatives, but does not explicitly name alternative tools or state when not to use it. The guidance is helpful but lacks explicit comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a calculation/query tool (implied read-only, non-destructive), supports cross-chain queries via the 'chains' parameter, and offers filtering for accuracy (exclude spam, low-liquidity, inactive tokens). However, it doesn't mention rate limits, authentication needs, data freshness, or error conditions, which are gaps for a tool with 6 parameters.
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 efficiently structured in two sentences: the first states the core purpose and key option (exclude spam), the second adds cross-chain capability and additional filtering options. Every phrase adds value, though it could be slightly more front-loaded by merging the two sentences for immediate clarity.
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 complexity (6 parameters, cross-chain queries, filtering logic) and lack of annotations or output schema, the description is adequate but incomplete. It covers the tool's purpose and key features but doesn't explain the return format (e.g., USD value breakdown, token list), performance expectations, or error handling, which are important for a net worth calculation tool.
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 6 parameters. The description adds marginal value by mentioning the 'chains' parameter for cross-chain querying and the purpose of excluding spam tokens, but doesn't provide additional syntax, format details, or examples beyond what the schema already specifies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('calculate the total net worth'), target resource ('of a wallet in USD'), and key capabilities ('with options to exclude spam tokens for accuracy', 'query cross-chain'). It distinguishes from siblings like 'evm_getwallettokenbalancesprice' (which focuses on token balances/prices) and 'solana_getportfolio' (which is chain-specific) by emphasizing comprehensive net worth calculation across chains with filtering options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for calculating wallet net worth with accuracy options (excluding spam, low-liquidity, inactive tokens) and cross-chain querying. It doesn't explicitly state when not to use it or name specific alternatives among the many siblings, but the purpose naturally differentiates it from tools focused on NFTs, transactions, or token-specific analytics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 that the tool returns 'on-chain metadata as well as off-chain metadata, floor prices, rarity and more where available,' which adds useful context about the richness of the response. However, it doesn't disclose critical behavioral traits like pagination behavior (implied by the 'cursor' parameter but not explained), rate limits, authentication requirements, or error handling, leaving significant gaps for an agent.
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 front-loaded with the core purpose in the first sentence and follows with a specific usage tip and details about the response content. Every sentence earns its place by adding value without redundancy, making it efficient and well-structured for quick comprehension.
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 complexity (10 parameters, no annotations, no output schema), the description is incomplete. It adequately covers the purpose and hints at response richness but lacks details on output structure, pagination, error cases, or performance considerations. For a tool with this many parameters and no structured output documentation, more contextual information would be needed for an agent 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?
The schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds minimal value beyond the schema by mentioning the 'token_addresses' parameter for filtering, but it doesn't provide additional semantic context (e.g., explaining what 'normalizeMetadata' entails or how 'include_prices' affects results). With high 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch') and resource ('all NFTs held by a specified wallet address'), making the purpose specific and unambiguous. It distinguishes this tool from sibling tools like 'evm_getwalletnftcollections' (which focuses on collections rather than individual NFTs) and 'evm_getmultiplenfts' (which likely operates differently).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Fetch all NFTs held by a specified wallet address') and includes a specific usage tip ('Use `token_addresses` to filter by one or many specific contract(s)'). However, it doesn't explicitly state when NOT to use it or name alternative tools for different scenarios, such as when only metadata is needed (e.g., 'evm_getnftmetadata').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses the Ethereum-only limitation, which is valuable behavioral context. However, it doesn't mention other important traits like whether this is a read-only operation, potential rate limits, pagination behavior, or what format the results come in. For a tool with zero annotation coverage, this leaves significant gaps in behavioral understanding.
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 perfectly concise and well-structured in just two sentences. The first sentence states the core purpose, the second provides important limitations and alternatives. Every word earns its place with zero redundancy or fluff.
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 has 0 parameters and no output schema, the description provides adequate basic information about what the tool does and its limitations. However, for a tool with no annotations, it should ideally mention whether this is a read operation (likely yes), what the return format looks like, or any other behavioral aspects. The description is minimally complete but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters, which is appropriate. It gets a 4 (not 5) because while it correctly doesn't discuss parameters, it also doesn't explicitly state there are no parameters (though the empty schema implies this).
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: 'List the top ERC20 tokens ranked by market cap.' It specifies the verb ('List'), resource ('top ERC20 tokens'), and ranking criterion ('by market cap'). However, it doesn't explicitly differentiate from its closest sibling 'evm_gettopcryptocurrenciesbymarketcap' (which might include non-ERC20 tokens), though the mention of 'ERC20' provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Currently only supports Ethereum' sets a clear limitation, and 'For more flexibility, we recommend to use getFilteredTokens' names a specific alternative tool. This directly tells the agent when to use this tool (for Ethereum-only top ERC20 tokens by market cap) and when to consider an alternative (for more flexible filtering).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses that the tool is limited to Ethereum (a behavioral constraint) and implies it returns both winners and losers, but it doesn't specify details like rate limits, data freshness, or response format. This is a moderate disclosure given the lack of annotations.
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 two sentences with zero waste: the first states the purpose and limitation, the second provides alternatives. Every word earns its place, and it's front-loaded with the core functionality.
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 complexity (a data retrieval tool with no parameters), no annotations, and no output schema, the description is somewhat complete but lacks details on what 'top' means (e.g., count, time frame) or the response structure. It covers usage and limitations but leaves gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it doesn't fully compensate for the lack of output schema by explaining return values, keeping it from a perfect score.
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 'top ERC20 tokens by price movements (winners and losers)', making the purpose specific and understandable. However, it doesn't explicitly differentiate from its siblings like 'getTopGainersTokens' and 'getTopLosersTokens' beyond mentioning them as alternatives, which prevents 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: it states 'Currently only supports Ethereum' (a limitation) and recommends 'For more flexibility, use getFilteredTokens or getTopGainersTokens and getTopLosersTokens' (named alternatives). This covers both when-to-use and when-not-to-use scenarios effectively.
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:

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

Score Badge

Copy to your README.md:

[![moralis-mcp-server MCP server](https://glama.ai/mcp/servers/MoralisWeb3/moralis-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/MoralisWeb3/moralis-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/MoralisWeb3/moralis-mcp-server'

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