agentek-eth

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
The tool set has significant overlap and ambiguity, with many tools performing similar functions on different resources (e.g., multiple address info tools like getAddressInfo, getAddressCounters, getAddressTransactions) and redundant operations (e.g., getBlock and getBlockInfo, getTransaction and getTransactionInfo). This creates confusion about which tool to use for specific tasks, leading to potential misselection.
Naming Consistency4/5
Naming is mostly consistent with a verb_noun pattern (e.g., getBalance, estimateGas, intentTransfer), though there are minor deviations like canUnlockSlow (adjective_verb_noun) and think (single verb). The majority follow a predictable structure, making the set readable despite the large size.
Tool Count2/5
With 127 tools, the count is excessive for a single server, even given the broad Ethereum/DeFi domain. This overwhelms the surface and suggests poor scoping, as many tools could be consolidated or omitted without losing functionality, making it cumbersome for agents to navigate.
Completeness5/5
The tool set provides comprehensive coverage for Ethereum and DeFi operations, including address analysis, token management, smart contract interactions, yield comparisons, and intent-based transactions. It supports full CRUD/lifecycle for key resources like tokens, pools, and positions, with no apparent gaps in the domain.
Average 2.9/5 across 127 of 127 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action ('Get proposals') without any details on permissions required, rate limits, pagination, return format, or error conditions. For a tool with 3 required parameters and no output schema, this leaves critical behavior undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, though overly brief given the tool's complexity. Every word earns its place, even if it's insufficient for full understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required parameters with 0% schema coverage, no annotations, no output schema, and no sibling differentiation, the description is severely incomplete. It doesn't explain what the tool returns, how parameters affect results, or behavioral constraints, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (account, chainId, dao) are documented in the schema. The description adds no information about what these parameters mean, their expected formats, or how they influence the proposal retrieval. This fails to compensate for the lack of schema documentation.
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 proposals for NANIDAO' restates the tool name 'getNaniProposals' almost verbatim, making it tautological. It specifies the resource ('proposals for NANIDAO') but lacks a clear verb beyond 'get', which is implied in the name. It doesn't differentiate from siblings like 'intentProposeNani' or 'intentVoteNaniProposal', leaving ambiguity about what type of proposals are retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include 'intentProposeNani' (for creating proposals) and 'intentVoteNaniProposal' (for voting), but the description doesn't clarify if this tool is for listing, fetching details, or something else. There's no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action ('Get') without details on permissions, rate limits, output format, or potential side effects. This is insufficient for a tool that likely involves data retrieval, as it omits critical 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise to the point of under-specification, consisting of a single phrase that fails to convey necessary details. While brief, it lacks structure and does not front-load key information, making it inefficient rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns, how results are formatted, or any behavioral nuances, leaving significant gaps for a tool that likely outputs a list of holders, which is inadequate for 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?
The input schema has 100% description coverage, clearly documenting the 'chain' parameter with supported values. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate but not enhanced parameter information.
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 native coin holders list' restates the tool name with minimal elaboration, making it tautological. It specifies the resource ('native coin holders list') but lacks a clear verb beyond 'Get' and doesn't differentiate from sibling tools like 'getHolders' or 'getTokenHolders', leaving ambiguity about what distinguishes this tool.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'getHolders' and 'getTokenHolders' present, there is no indication of context, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get address coin balance history' but reveals nothing about the tool's behavior: no information on rate limits, authentication needs, data freshness, pagination, error conditions, or what the output looks like (e.g., time-series format, date ranges, or units). For a tool with no 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 extremely concise with just four words, making it front-loaded and free of unnecessary information. Every word contributes directly to the core purpose, though this brevity comes at the cost of completeness. There's no wasted language or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain data queries, no annotations, no output schema, and low schema description coverage (50%), the description is severely incomplete. It doesn't explain what 'coin balance history' entails, how results are structured, any limitations, or how it differs from similar tools. For a tool that likely returns time-series financial data, this lack of context makes it inadequate for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 50% description coverage (only 'chain' has a description). The description adds no parameter semantics beyond what's in the schema—it doesn't explain what 'address' should be (e.g., Ethereum address format), doesn't clarify the meaning of 'coin balance history' in relation to parameters, and doesn't address any optional behaviors like date ranges or granularity. With low schema coverage, the description fails to compensate for undocumented parameters.
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 address coin balance history' is essentially a tautology that restates the tool name with minor grammatical changes. It specifies the verb 'Get' and resource 'address coin balance history', but doesn't clarify what 'coin balance history' means (e.g., time-series data, transaction-based changes, or periodic snapshots). It also fails to distinguish this tool from sibling tools like 'getAddressCoinBalanceHistoryByDay' or 'getCoinBalance', leaving the scope ambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions. With sibling tools like 'getAddressCoinBalanceHistoryByDay' (likely for daily granularity) and 'getCoinBalance' (likely for current balance), there's no indication of how this tool differs or when it's the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to do so—it doesn't mention whether this is a read-only operation, potential rate limits, authentication needs, or what the output entails (e.g., list of contracts, details). The description is too sparse to inform the agent about 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, overly concise phrase that under-specifies the tool's function rather than being efficiently structured. It lacks front-loaded clarity and fails to earn its place with useful details, making it feel incomplete rather than succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of smart contract retrieval and the lack of annotations and output schema, the description is inadequate. It doesn't explain what 'smart contract' refers to, the format of results, or any behavioral aspects like pagination or error handling. For a tool with three parameters and no structured output, more descriptive 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 'chain', 'q', and 'language' parameters. The description adds no additional semantic context beyond the schema, such as examples of valid queries or how the language parameter affects results. However, since the schema is well-documented, a 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get smart contract for the query' is tautological—it essentially restates the tool name 'getSmartContracts' without adding meaningful specificity. While it implies retrieving smart contracts based on a query, it lacks details about what 'smart contract' means in this context (e.g., source code, metadata, or deployment info) or how the query operates, making it vague and minimally informative.
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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like getCode, getTransaction, or getAddressInfo that might overlap with smart contract data, there is no indication of this tool's specific use case, prerequisites, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('Get') without any information about rate limits, authentication requirements, data freshness, pagination, error conditions, or what the output looks like (e.g., time-series format). For a tool that likely queries blockchain data, this lack of behavioral context is a significant gap, leaving the agent with minimal operational 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 extremely concise—a single phrase with no wasted words. It's front-loaded with the core action and resource. While this brevity contributes to clarity in structure, it comes at the cost of completeness, as noted in other dimensions. Every word earns its place, but the description may be too minimal for effective tool selection.
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 data queries, two required parameters, no annotations, and no output schema, the description is incomplete. It lacks essential context such as output format, time range defaults, error handling, and differentiation from siblings. The description does not provide enough information for an agent to use the tool confidently or understand its behavior beyond the basic action stated.
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 50% (only the 'chain' parameter has a description). The tool description adds no parameter-specific information beyond what's implied by the name ('address' and 'by day'). It doesn't clarify parameter meanings, formats (e.g., address validation, date ranges implied by 'by day'), or dependencies. With two required parameters and low schema coverage, the description fails to compensate, resulting in inadequate parameter documentation.
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 address coin balance history by day' is a tautology that essentially restates the tool name with minimal elaboration. It specifies the verb ('Get') and resource ('address coin balance history by day'), but lacks specificity about what 'coin' refers to (likely native cryptocurrency vs. tokens) or how the history is structured. It doesn't distinguish from siblings like 'getAddressCoinBalanceHistory' (without 'by day') or 'getCoinBalance', leaving ambiguity about scope and granularity.
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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to address balances (e.g., 'getAddressCoinBalanceHistory', 'getCoinBalance', 'getAddressTokenBalances'), there's no indication of when this daily history tool is appropriate, what prerequisites might exist, or when other tools should be preferred. This absence of context makes it difficult for an agent to select correctly among similar options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action without mentioning rate limits, authentication needs, pagination, error handling, or what the returned list includes (e.g., format, size). This is inadequate for a tool with 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 front-loads the core purpose without unnecessary words. It's appropriately sized for the tool's apparent complexity, with no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It lacks details on behavior, parameter meanings, return values, and usage context, making it inadequate for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (chainId, start, finish) are undocumented in the schema. The description mentions 'index ranges' but doesn't explain what these parameters represent (e.g., chainId values, start/finish units or constraints), failing to compensate for the coverage gap.
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 a list') and resource ('Coinchan token IDs') with scope ('between index ranges'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'coinchanGetCoinsCount' or 'getCoinTokenMetadata', 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 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 tokens and coins (e.g., 'getCoin', 'getLatestTokens'), there's no mention 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a receipt, implying a read-only operation, but doesn't clarify if it requires specific permissions, has rate limits, returns structured data, or handles errors. For a tool with no annotation coverage, this minimal description is insufficient to inform safe and effective use.
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, straightforward sentence with no wasted words, making it easy to parse. However, it's overly concise to the point of under-specification, as it lacks necessary details for a tool with two undocumented parameters and no annotations, but it's not verbose or poorly 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 (a tool with two required parameters, no annotations, no output schema, and many sibling tools), the description is incomplete. It doesn't explain what a transaction receipt includes, how parameters are used, or when to choose this over similar tools. For a tool in a crowded namespace with no structured support, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (hash and chainId) with 0% description coverage, meaning their purposes are undocumented. The description adds no information about these parameters—it doesn't explain what 'hash' refers to (e.g., transaction hash) or what 'chainId' is used for (e.g., blockchain network identifier). This leaves the agent to infer parameter meanings from context, which is inadequate.
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 receipt of a transaction' clearly states the action (get) and resource (transaction receipt), making the purpose understandable. However, it lacks specificity about what a 'receipt' entails (e.g., confirmation details, gas used, logs) and doesn't differentiate from sibling tools like 'getTransaction' or 'getTransactionInfo', which might retrieve similar transaction-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 that handle transaction data (e.g., getTransaction, getTransactionInfo, getTransactionLogs), there's no indication of what makes this tool unique or when it's preferred, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool estimates gas but doesn't explain what 'estimate' entails (e.g., simulation-based, network-dependent, accuracy), potential side effects, error conditions, or output format. This leaves significant gaps for a tool that likely interacts with blockchain networks.
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 ('Estimate gas for a transaction') with no wasted words. It's front-loaded and efficiently communicates the core function in a single phrase, though this brevity contributes to gaps in other dimensions.
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 blockchain transaction tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the estimation process, return values, error handling, or how parameters interact, leaving the agent with inadequate context for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'to', 'value', 'data', or 'chainId' represent, their formats (e.g., hex addresses, wei units), or how they affect the gas estimation. This is inadequate for 4 parameters with no schema descriptions.
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 ('Estimate gas for a transaction'), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'estimateGasCost' or 'getGasPrice', leaving ambiguity about when to use this specific tool versus 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 'estimateGasCost' or 'getGasPrice'. The description lacks context about prerequisites, typical use cases, or exclusions, offering no help 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 full burden. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't disclose behavioral traits such as rate limits, authentication needs, error handling, or what the output looks like (e.g., JSON structure). 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 with no wasted words. It's front-loaded and to the point, though it could benefit from more detail given the tool's complexity. No structural issues are present.
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 moderate schema coverage (50%), the description is incomplete. It doesn't explain what 'counters' are, the return format, or behavioral aspects like pagination or errors. For a tool in a crowded sibling set with potential complexity, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only the 'chain' parameter has a description). The description adds no additional meaning beyond the schema—it doesn't explain what 'counters' are or how parameters affect them. Since schema coverage is moderate, the baseline is 3, but the description fails to compensate for the undocumented 'address' 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 counters for a specific address' clearly states the verb ('Get') and resource ('counters for a specific address'), but it's vague about what 'counters' means—it could refer to transaction counts, balance changes, or other metrics. It doesn't distinguish from siblings like getAddressInfo or getAddressTransactions, 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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like getAddressInfo, getAddressTransactions, and getAddressTokenTransfers that might offer similar or complementary data, the description lacks any context on use cases, prerequisites, or comparisons.
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 implies a read-only operation ('Get'), but doesn't disclose error conditions, rate limits, authentication needs, or what the output contains. For a tool with no annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for its minimal content, though this conciseness comes at the cost of detail.
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 (2 required parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't provide enough context for an agent to use the tool effectively, missing details on parameters, behavior, and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters 'blockNumber' and 'chainId' are undocumented in the schema. The description adds no parameter semantics—it doesn't explain what these parameters mean, their formats, or valid ranges. This fails to compensate for the schema gap.
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 information about a block' clearly states the verb ('Get') and resource ('block'), but it's vague about what specific information is retrieved. It distinguishes from siblings like 'getBlockInfo' and 'getBlockTransactions' only by being more generic, not by clarifying its unique 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 'getBlockInfo' or 'getBlockTransactions'. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from 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 a read operation ('Get'), implying no destructive effects, but lacks details on permissions, rate limits, error handling, or output format. This is insufficient for a tool that interacts with blockchain data, where such behavioral traits are critical.
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 no wasted words, making it highly concise and front-loaded. It efficiently states the core action 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?
Given the tool's complexity (blockchain bytecode retrieval), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It does not address key aspects like return format, error cases, or dependencies, leaving 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'address' but does not explain its format (e.g., Ethereum address) or the purpose of 'chainId'. It adds minimal semantic value beyond naming one parameter, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the bytecode of an address' specifies a verb ('Get') and resource ('bytecode of an address'), making the purpose clear. However, it does not distinguish this tool from siblings like 'getSmartContract' or 'getAddressInfo', which might also retrieve contract-related data, leaving ambiguity in 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 for blockchain data (e.g., 'getSmartContract', 'getAddressInfo'), there is no indication of specific contexts, prerequisites, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'trending tokens and market data' but doesn't disclose behavioral traits such as data freshness (e.g., real-time vs. delayed), rate limits, authentication needs, or what happens if no trending data is available. 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 a single, efficient sentence: 'Get trending tokens and market data'. It's front-loaded with the core action and resource, with no wasted words. However, it could be more structured by explicitly separating the two components (trending tokens vs. market data) 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 the complexity implied by 'trending tokens and market data', no annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned (e.g., token list, prices, volumes), how trending is determined, or any limitations. For a tool that likely provides dynamic, multi-faceted data, this lack of detail makes it inadequate 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 input schema has 100% description coverage, with 'chainId' documented as 'Chain Id'. The description doesn't add any parameter-specific information beyond this, such as example chain IDs or how the parameter affects the output (e.g., whether it filters results by blockchain). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get trending tokens and market data' states a general purpose but lacks specificity. It mentions 'trending tokens' and 'market data' but doesn't clarify what constitutes 'trending' (e.g., by volume, price change, social activity) or what specific market data is included. It distinguishes somewhat from siblings like 'getTokenInfo' or 'getTokenMetadata' by focusing on trending items rather than individual token details, but the distinction is vague.
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 'getTokenInfo', 'getTokenChart', and 'getCryptoPrice', there's no indication of when this tool is preferred (e.g., for discovering popular tokens vs. detailed analysis). No prerequisites, exclusions, or contextual advice 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?
No annotations are provided, so the description carries the full burden. It states it 'Gets' data, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, error conditions, or what the output looks like (no output schema). 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 appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and 2 required parameters, the description is incomplete. It doesn't provide enough context for an AI agent to understand how to invoke the tool correctly or interpret results, especially with many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'for a pool' but doesn't explain the parameters 'poolAddress' and 'chainId' (e.g., format of poolAddress, what chainId represents). The description adds minimal value beyond the schema, failing to clarify parameter meanings.
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 fee-related data for a pool' states a clear verb ('Gets') and resource ('fee-related data for a pool'), but it's vague about what specific fee data is retrieved. It doesn't distinguish from siblings like 'getPool' or 'getUniV3Pool', which might also provide pool-related information.
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 (e.g., 'getPool', 'getUniV3Pool', 'getFeeHistory'), the description lacks context on its specific use case, 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. 'Get statistics' implies a read-only operation, but the description doesn't specify what kind of statistics are returned (network metrics, address metrics, token metrics), the format of the response, whether there are rate limits, authentication requirements, or any other behavioral characteristics. It's minimally informative for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a tool with one parameter, though it could be more informative while remaining concise. The structure is straightforward but could benefit from front-loading more specific information about what statistics are available.
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, no output schema, and a single parameter, the description is incomplete. It doesn't explain what 'statistics' or 'blockchain metrics' actually mean in this context, what format the response takes, or how this tool differs from the many specific data retrieval tools in the sibling list. 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?
The description mentions 'blockchain metrics' but doesn't explain how the 'chain' parameter relates to what statistics are available. With 100% schema description coverage (the schema fully documents the chain parameter with enum values and description), the description adds minimal value beyond what's already in the structured schema. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get statistics for various blockchain metrics' states the general purpose (retrieving statistics) but is vague about what specific statistics are available. It mentions 'blockchain metrics' but doesn't specify whether these are network-level stats, address stats, token stats, etc. Compared to sibling tools like getBalance, getTransaction, or getTokenInfo, it's unclear what distinguishes this tool.
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 retrieve specific blockchain data (getBalance, getTransaction, getTokenInfo, etc.), there's no indication whether this tool provides aggregated/network-level statistics versus address-specific statistics, or when it would be preferred over more specific 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 the tool 'retrieves' data, implying a read-only operation, but doesn't specify any behavioral traits like rate limits, authentication requirements, error conditions, or what the output format looks like. For a tool with no annotations, this leaves significant gaps in understanding how it 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 gets straight to the point without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be more informative by specifying what 'summary' entails.
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 (2 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the summary includes, how it differs from other transaction-related tools, or what the output looks like. For a tool with no output schema and partial parameter documentation, more context is needed to make it fully usable.
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 50%, with the 'chain' parameter well-documented (including enum values and description) but 'txhash' lacking any description. The tool description doesn't add any parameter semantics beyond what's in the schema—it doesn't explain what 'txhash' represents (e.g., a transaction hash string) or provide context for the parameters. Given the partial schema coverage, the description doesn't compensate, resulting in a baseline score.
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 'Retrieve a summary of data related to a transaction' clearly states the verb ('retrieve') and resource ('summary of data'), but it's vague about what specific data is included in the summary. It doesn't distinguish this tool from sibling tools like 'getTransaction', 'getTransactionInfo', or 'getTransactionReceipt', which likely provide more detailed or different transaction 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 sibling tools like 'getTransaction', 'getTransactionInfo', and 'getTransactionReceipt' available, there's no indication of what makes 'getTransactionSummary' unique—such as whether it provides aggregated data, a high-level overview, or specific summary metrics compared to those 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 'predict,' implying a read-only or simulation operation, but doesn't clarify if this is a safe, non-destructive call, what the output format might be (e.g., string, object), or any limitations (e.g., accuracy, rate limits). For a tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Predict a transfer ID for a potential transfer') that directly states the tool's purpose without unnecessary words. It's front-loaded and easy to parse, though it could be slightly more informative (e.g., by hinting at use cases). Overall, it's 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?
Given the complexity (predictive tool with 4 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'transfer ID' is, how the prediction works, or what the output entails (e.g., format, reliability). For a tool that likely involves simulation or estimation, more context is needed to understand its role and limitations.
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 (from, to, id, amount). The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints. Since schema coverage is high, the baseline score is 3, as the schema adequately documents parameters without needing extra detail from the description.
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 'predicts a transfer ID for a potential transfer,' which clarifies the action (predict) and resource (transfer ID). However, it's somewhat vague about what a 'transfer ID' represents in this context (e.g., a transaction hash, reference number) and doesn't distinguish it from sibling tools like 'intentTransfer' or 'getTransaction,' which involve actual transfers or transaction data. It provides a basic purpose 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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., before executing a transfer), exclusions (e.g., not for actual transfers), or refer to sibling tools like 'intentTransfer' for real transfers or 'getTransaction' for existing IDs. Without such context, users must infer usage, which is insufficient for effective 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 only states it 'gets information', implying a read-only operation, but doesn't specify what information is returned, potential rate limits, error conditions, or data freshness. For a tool with no annotation coverage, this minimal description fails to provide necessary behavioral context for reliable use.
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 no wasted words. It's front-loaded with the core purpose and appropriately sized for what it conveys, 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 (2 required parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what information is returned, how results are structured, or any limitations. For a tool that likely returns varied address data, this leaves too many unknowns for effective use by an agent.
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 'a specific address' which aligns with the 'address' parameter, but doesn't explain the 'chain' parameter or what the combination yields. With 50% schema description coverage (only 'chain' has a description), the description adds minimal value beyond the schema. It doesn't compensate for the lack of schema description for 'address' or provide additional context about parameter interactions.
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 information about a specific address', which clearly indicates it retrieves data (verb 'Get') for an address resource. However, it doesn't specify what type of information (e.g., balance, transactions, metadata) or differentiate from many sibling tools that also get address-related data (e.g., getAddressTransactions, getAddressTokenBalances). This makes it somewhat vague compared to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools like getAddressTransactions, getAddressTokenBalances, and getBalance that might overlap in functionality, there's no indication of what makes this tool unique or when it's the appropriate choice. This lack of context leaves the agent guessing.
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 only states the action ('Get information') without detailing response format, error conditions, rate limits, or authentication needs. This is inadequate for a tool that likely returns complex blockchain 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 with no wasted words. It is front-loaded and directly states 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 of blockchain data, no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not explain what information is returned, how to interpret results, or handle edge cases, leaving significant gaps for the agent.
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 50%, with 'chain' well-documented but 'blockNumberOrHash' lacking a description. The tool description does not add any parameter details beyond the schema, failing to compensate for the coverage gap. However, the schema provides some clarity, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about a specific block' clearly states the verb ('Get') and resource ('block'), making the purpose understandable. However, it lacks specificity about what information is retrieved (e.g., block details, transactions, timestamps) and does not differentiate from sibling tools like 'getBlock' or 'getBlockTransactions', leaving ambiguity 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or compare it to sibling tools such as 'getBlock' or 'getBlockTransactions', leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves historical data, implying a read-only operation, but doesn't specify any behavioral traits like rate limits, authentication needs, data freshness, 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 extremely concise with a single phrase 'Get historical gas fee info', which is front-loaded and wastes no words. Every part of the sentence contributes directly to the purpose, 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 complexity of retrieving historical gas fee data with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects, parameter usage, and expected output format, making it inadequate for an agent to fully understand how to invoke and interpret results from this 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 67%, with two parameters (blockCount, rewardPercentiles) well-described in the schema, while 'chainId' lacks a description. The tool description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between parameters or typical values. Since coverage is moderate, the baseline score of 3 is appropriate, but it doesn't compensate for the undocumented 'chainId' 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 historical gas fee info' clearly states the action ('Get') and resource ('historical gas fee info'), making the purpose understandable. However, it's somewhat vague about what specific fee information is retrieved (e.g., average fees, percentile fees, etc.), and it doesn't differentiate from sibling tools like 'getGasPrice' or 'estimateGasCost', which also relate to gas fees but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, context for usage, or comparisons to sibling tools such as 'getGasPrice' (for current prices) or 'estimateGasCost' (for future estimates), leaving the agent without clear direction on 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 full burden. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't disclose behavioral traits such as permissions needed, rate limits, error conditions, or what the output looks like (e.g., format, fields). This leaves significant gaps 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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse 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?
Given the tool's complexity (read operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'guardian information' includes, how results are structured, or any behavioral context, making it inadequate for reliable use despite the concise wording.
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 'user' documented as 'The user address to check'. The description adds no additional meaning beyond this, such as format examples or constraints. Given 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get guardian information for a user' clearly states the action (get) and resource (guardian information), but it's vague about what 'guardian information' entails. It doesn't differentiate from sibling tools like 'getSlowStatus' or 'intentSetSlowGuardian', leaving the specific purpose ambiguous.
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 'getSlowStatus' and 'intentSetSlowGuardian', the description lacks context about prerequisites, timing, or distinctions, offering no help for 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 implies a read-only operation ('Get') but doesn't specify if it requires authentication, has rate limits, or details the return format (e.g., numeric value, units). More context on the output behavior is needed for safe use.
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 avoids redundancy and is 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 lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't cover parameter meanings, behavioral traits like error handling, or return value details, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It doesn't mention 'chainId' or 'coinId' at all, leaving their purposes (e.g., blockchain network, token identifier) undocumented. This gap reduces usability for an agent.
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 specific resource ('amount of liquidity currently available to vest for a locked Coinchan token'). It distinguishes itself from siblings by focusing on vestable liquidity for locked tokens, though it doesn't explicitly contrast with tools like 'coinchanGetCoins' or 'intentCoinchanClaimVested'.
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 needing a locked token, or suggest other tools for related actions like claiming vested amounts or checking token 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires authentication, has rate limits, returns cached or real-time data, or what error conditions might occur. For a tool with 3 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose without any unnecessary verbiage. Every word serves a purpose, making it efficient for quick scanning while still conveying the essential action and 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 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (balance in wei/ether, error formats), doesn't clarify parameter usage, and provides no behavioral context. Given the complexity implied by multiple parameters and the lack of structured documentation, this description leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so all 3 parameters are undocumented in structured fields. The description mentions 'address' but doesn't explain what format it expects (checksummed, lowercase, ENS name?), what 'chainId' represents (mainnet vs testnets), or what 'formatEth' does (wei vs ether units). The description adds minimal value beyond the parameter names visible 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 ('Get') and resource ('ETH balance for an address'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from similar sibling tools like 'getCoinBalance' or 'getAddressCoinBalanceHistory', which could cause confusion in tool selection.
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 'getCoinBalance' or 'getAddressTokenBalances'. There's no mention of prerequisites, limitations, or specific contexts where this tool is preferred over other balance-checking tools in the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool gets a quote, implying a read-only operation, but doesn't clarify if it requires network calls, has rate limits, returns estimated costs, or provides any error handling details. This leaves significant gaps in understanding its behavior beyond the basic action.
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 unnecessary words. It is front-loaded and wastes no space, 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 complexity of a token swap quote tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to explain parameter meanings, return values, or behavioral traits, leaving the agent with insufficient information to use the tool effectively in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the parameters are documented in the schema. The description adds no information about what 'tokenIn', 'tokenOut', 'amount', or 'side' mean, their expected formats, or how they interact. For a tool with 4 required parameters, this lack of semantic guidance is a major deficiency.
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 a quote') and the resource ('for swapping ERC20 and ERC6909 tokens'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from the 'swap' sibling tool, which appears to perform the actual swap operation, 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 no guidance on when to use this tool versus alternatives like 'swap' or other quote-related tools. It lacks context about prerequisites, such as needing token addresses or amounts, and doesn't mention any exclusions or specific scenarios 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 for behavioral disclosure. 'Get details about a transaction' implies a read-only operation, but it doesn't specify what details are returned, whether there are rate limits, authentication requirements, error conditions, or how it differs from other transaction tools. This leaves significant gaps for an agent to understand 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 extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 required parameters with 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain what the tool returns, how to interpret parameters, or how it differs from similar tools. For a tool that likely queries blockchain transactions, more context about return format, error handling, and differentiation from siblings is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter (hash, chainId) has descriptions in the schema. The tool description provides no additional information about what these parameters mean, their expected formats, or examples. For instance, it doesn't clarify if 'hash' is a transaction hash, what 'chainId' represents, or valid values for 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 action ('Get details') and resource ('about a transaction'), making the purpose understandable. However, it doesn't differentiate this tool from similar sibling tools like 'getTransactionInfo', 'getTransactionSummary', or 'getTransactionReceipt', which all appear to retrieve transaction-related information.
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 transaction-related tools in the sibling list (e.g., getTransactionInfo, getTransactionSummary, getTransactionReceipt), there's no indication of what distinguishes this tool from those or when it should be preferred.
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 'Get' implies a read operation, it doesn't disclose important behavioral aspects: whether this requires API keys/authentication, rate limits, what format the count is returned in (integer, string), whether it's real-time or cached data, or error conditions. For a blockchain query tool with zero 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 gets straight to the point with zero wasted words. It's appropriately sized for a simple query tool and front-loads the core functionality 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 blockchain query tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (just a count number? with metadata?), doesn't clarify parameter semantics, and provides no behavioral context. Given the complexity of blockchain APIs and the lack of structured documentation, the description should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but doesn't. It mentions 'address' but doesn't explain format requirements (checksum, case sensitivity) or provide examples. The 'chainId' parameter isn't mentioned at all, leaving users guessing about its purpose and required values. With 2 parameters and 0% schema coverage, the description adds minimal value beyond what's obvious from the tool name.
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 ('number of transactions sent from an address'), providing specific verb+resource combination. It distinguishes from many sibling tools that handle different blockchain data (e.g., getBalance, getTransaction, getAddressTransactions), though it doesn't explicitly differentiate from getAddressCounters which might include transaction counts.
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. With many sibling tools for address-related data (getAddressTransactions, getAddressCounters, getAddressInfo), the description doesn't indicate whether this is a specialized count-only endpoint, when it's preferable to other transaction query tools, or any prerequisites for 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 states this is a read operation ('Gets information'), which implies it's non-destructive, but it doesn't disclose any behavioral traits such as rate limits, authentication needs, error conditions, or what specific information is returned. 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 unnecessary words. It's front-loaded and wastes no space, 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.
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 data retrieval, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what information is returned, how to interpret results, or address potential issues like invalid addresses or network errors, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It mentions 'Uniswap V3 pool' which hints at the 'poolAddress' parameter, but it doesn't explain what 'poolAddress' or 'chainId' mean, their formats, or provide any examples. This leaves both parameters poorly documented beyond their basic types.
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 information') and resource ('about a Uniswap V3 pool'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getPool' or 'getPoolFeeData', which appear to be related pool information tools, 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 sibling tools like 'getPool' and 'getPoolFeeData' that might overlap in functionality, there's no indication of what makes this tool unique or when it should be preferred, leaving usage ambiguous.
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 it 'gets' data without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what the return format looks like. This leaves significant gaps for a tool that presumably queries blockchain 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 essential information. There's no wasted verbiage or unnecessary elaboration, 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 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter formats, return values, error conditions, or behavioral constraints. Given the complexity of blockchain data queries and the lack of structured documentation, this leaves too many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'for a user' which hints at the 'user' parameter but doesn't explain what format it expects (address, ENS name, etc.) or mention the 'chainId' parameter at all. This fails to compensate for the schema's lack of descriptions.
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 ('all Uniswap V3 positions for a user'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'getPositionDetails' or 'getAccountPortfolio', but the specificity of 'Uniswap V3 positions' 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?
No guidance is provided on when to use this tool versus alternatives like 'getAccountPortfolio' or 'getPositionDetails'. The description lacks context about prerequisites, limitations, or comparison to sibling tools, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions creation and liquidity holding, it lacks critical details such as required permissions, whether this is a write operation, potential costs or gas fees, rate limits, or what happens upon failure. For a complex 9-parameter 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, 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?
Given the complexity (9 required parameters, no annotations, no output schema), the description is inadequate. It doesn't explain the return values, error conditions, or the broader context of token creation and liquidity management. For a tool with such rich input requirements, more completeness 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% (only the 'creator' parameter has a description), leaving 8 parameters undocumented. The description adds no semantic context for parameters like 'chainId', 'poolSupply', 'swapFee', or 'value', failing to compensate for the low coverage. This leaves most inputs ambiguous.
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 ('Create a new Coinchan token') and the outcome ('hold liquidity for the creator'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'intentCoinchanMake' or 'intentCoinchanMakeLocked', which appear to be similar token creation tools, so it doesn't achieve full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'intentCoinchanMake' and 'intentCoinchanMakeLocked' that likely serve similar purposes, there's no indication of the specific scenarios, prerequisites, or trade-offs that would inform 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 the action without behavioral details. It does not disclose that this is likely a write operation (implied by 'collects'), potential gas costs, authorization needs, or effects on the position, leaving 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.
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 is front-loaded with the core purpose, 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.
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 blockchain transaction tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameters, outputs, and context needed for safe and effective use, falling short of providing adequate guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It does not explain what 'tokenId', 'recipient', or 'chainId' represent, their formats, or how they affect the operation, failing to provide necessary semantics beyond the bare 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 ('collects') and the resource ('accumulated fees from a Uniswap V3 position'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'intentWithdrawFromSlow' or other fee-related operations, missing an opportunity for precise 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. It lacks context on prerequisites (e.g., position must have accumulated fees), exclusions, or comparisons to other tools like 'getPositionDetails' for checking fee amounts, leaving the agent with no 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 full burden for behavioral disclosure. While 'Removes liquidity' implies a destructive write operation, it doesn't disclose critical behavioral aspects like required permissions, gas costs, confirmation requirements, whether the action is reversible, or what happens to removed liquidity. This is a significant gap for a financial transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action, 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 financial transaction tool with 5 parameters (3 required), no annotations, 0% schema description coverage, and no output schema, the description is severely inadequate. It doesn't explain what the tool returns, what the parameters mean, or the behavioral implications of removing liquidity from a Uniswap position.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 5 parameters, the description provides no information about what 'tokenId', 'liquidity', 'slippageTolerance', 'deadline', or 'chainId' mean or how they should be formatted. The description doesn't compensate for this complete lack of parameter documentation 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 ('Removes liquidity') and target resource ('from a Uniswap V3 position'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'intentIncreaseLiquidity' or 'intentCollectFees', which are related liquidity management operations.
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 'intentIncreaseLiquidity' (for adding liquidity) or 'intentCollectFees' (for collecting fees from positions). 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Adds more liquidity,' implying a write/mutation operation, but does not disclose critical traits such as required permissions, gas costs, irreversible effects, or expected response format. This leaves significant gaps in understanding the tool's behavior and risks.
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 no wasted words. It is front-loaded with the core action and resource, making it highly efficient and easy to parse, which is ideal 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 of a DeFi liquidity operation with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, parameter meanings, and expected outcomes, making it insufficient for safe and effective use by an AI agent in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning all 6 parameters are undocumented in the schema. The description does not add any meaning or context for parameters like 'tokenId', 'amount0Desired', or 'slippageTolerance', failing to compensate for the schema's lack of documentation and leaving the agent without guidance on what these inputs represent.
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 ('Adds more liquidity') and the target resource ('an existing Uniswap V3 position'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'intentDecreaseLiquidity' or 'intentMintPosition', which would require mentioning it's for increasing liquidity in existing positions versus decreasing or creating new ones.
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 (e.g., needing an existing position), exclusions, or compare it to related tools like 'intentDecreaseLiquidity' or 'intentMintPosition', leaving the agent to infer usage from context 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 only states the action without behavioral details. It doesn't disclose that this is a write operation requiring blockchain interaction, potential gas costs, slippage handling (implied by parameter but not explained), or that it might involve token approvals. This leaves significant gaps for a complex financial tool.
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?
For a complex tool with 11 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It lacks details on behavior (e.g., transaction signing, error handling), parameter meanings, and expected outcomes, making it insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'token0', 'tickLower', 'slippageTolerance', or other 11 parameters mean, their formats (e.g., token addresses as strings, tick values as integers), or how they interact (e.g., fee tiers, liquidity ranges). This is inadequate for such a parameter-rich tool.
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 ('Creates') and resource ('new Uniswap V3 liquidity position'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'intentIncreaseLiquidity' or 'intentDecreaseLiquidity', which also manage liquidity positions, 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. It doesn't mention prerequisites (e.g., token approvals, sufficient balances), context (e.g., initial setup vs. adjustments), or compare to related tools like 'intentIncreaseLiquidity' or 'swap', leaving the agent with no 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 states the tool performs a transfer, implying a write operation, but doesn't mention critical details like required permissions, gas costs, confirmation times, or potential side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded and wastes no space, 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?
Given the complexity of transferring an LP NFT (a blockchain write operation), the lack of annotations, 0% schema coverage, and no output schema, the description is inadequate. It doesn't cover behavioral risks, parameter details, or expected outcomes, leaving too many gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the parameters (tokenId, to, chainId) are documented in the schema. The description doesn't add any information about what these parameters mean, their formats, or examples, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Transfers ownership') and the resource ('Uniswap V3 LP NFT'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'intentTransfer' or 'intentTransferFrom', which also involve transfers, so it doesn't fully differentiate 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. With sibling tools like 'intentTransfer' and 'intentTransferFrom' available, there's no indication of the specific context or prerequisites for transferring an LP NFT, leaving usage ambiguous.
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 'check' implies a read-only operation, it doesn't confirm safety, rate limits, authentication needs, or what 'info' includes. For a tool with no annotations, this is insufficient—it should describe the return format, potential errors, or side effects.
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 wording or redundancy, making it easy to parse quickly. It effectively communicates the essential action in minimal space.
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 check operation with no output schema and no annotations), the description is incomplete. It doesn't explain what 'info' is returned, error conditions, or how it differs from related tools. For a tool in a domain with many siblings (e.g., 'intentUnlockSlow'), more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with one parameter ('transferId') fully documented in the schema. The description doesn't add any parameter details beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since 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 tool's purpose: 'Check if a transfer can be unlocked and get info about it'. It specifies the verb ('check'), resource ('transfer'), and outcome ('get info'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'getCanReverseSlowTransfer' or 'intentUnlockSlow', 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or sibling tools like 'getCanReverseSlowTransfer' (which checks reversibility) or 'intentUnlockSlow' (which performs the unlock). 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 checks for malicious associations but does not describe what constitutes 'malicious activity', how the check is performed (e.g., database lookup, API call), or the response format (e.g., boolean, risk score). This leaves significant gaps in understanding the tool's behavior and output.
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 function without unnecessary words. It is front-loaded with the main purpose, making it easy to understand quickly. There is no wasted verbiage, and it avoids 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 complexity of checking for malicious activity and the lack of annotations and output schema, the description is insufficient. It does not explain what the tool returns (e.g., true/false, risk details), potential errors, or limitations (e.g., coverage scope, data freshness). For a security-related tool with no structured context, more detail is needed to ensure proper 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 one parameter ('address') with 0% description coverage, meaning the schema provides no semantic details. The description implies the parameter is an Ethereum address but does not specify format requirements (e.g., checksum, length) or validation rules. It adds minimal value beyond the schema's structural definition, resulting in a baseline score due to incomplete 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 tool's purpose: 'Check if an Ethereum address has been associated with malicious activity.' It specifies the verb ('check') and resource ('Ethereum address'), making the intent unambiguous. However, it does not differentiate from sibling tools like 'checkMaliciousWebsite' or 'getAddressInfo', which might provide related but different functionality.
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 valid Ethereum address format, or exclusions, like not working for non-Ethereum addresses. With many sibling tools available (e.g., 'getAddressInfo', 'checkMaliciousWebsite'), the lack of comparative context leaves 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 implies a read-only operation ('check'), but doesn't specify data sources, accuracy limitations, rate limits, or authentication needs. For a security-checking tool, this lack of behavioral context 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 directly states the tool's function without 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security assessment tool with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't explain what constitutes 'malicious activity,' how results are returned, or any limitations, making it inadequate for informed tool selection.
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 'website' as the parameter, which aligns with the single parameter in the schema. However, with 0% schema description coverage, it doesn't add details like URL format requirements or validation rules. The baseline is appropriate given the single parameter, but it doesn't fully compensate for the schema's lack of 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: checking if a website is associated with crypto scams or malicious activity. It uses specific verbs ('check') and identifies the resource ('website'), but doesn't explicitly differentiate from sibling tools like 'checkMaliciousAddress' or 'scrapeWebContent', 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 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 not to use it (e.g., for non-crypto-related checks) or reference sibling tools like 'checkMaliciousAddress' for address-specific checks, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a 'Get' operation (implying read-only), but doesn't disclose behavioral traits like rate limits, authentication needs, error conditions, or what the output format looks like. For a tool 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's appropriately sized for a simple tool and front-loads the core purpose immediately.
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 low parameter schema coverage, the description is incomplete. It doesn't explain what the tool returns (just a count? formatted how?), doesn't cover error cases, and provides minimal context for a tool that likely interacts with blockchain data where chainId specificity matters.
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 (chainId) with 0% description coverage. The tool description doesn't mention any parameters or explain what chainId represents (e.g., which blockchain network). With low schema coverage, the description doesn't compensate by adding parameter meaning, but since there's only one parameter, the baseline is adjusted to 3.
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 total number') and resource ('Coinchan tokens created'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'coinchanGetCoins' or 'getCoinTokenMetadata', which might retrieve similar token information.
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 tokens and coins (e.g., 'coinchanGetCoins', 'getCoinTokenMetadata', 'getTokenInfo'), there's no indication of when this specific count retrieval is appropriate or what distinguishes it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool compares yield opportunities but doesn't explain what 'compares' entails—e.g., whether it returns data in a specific format, if it's a read-only operation, potential rate limits, or error conditions. For a tool 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's front-loaded and wastes no space, making it easy for an agent to parse quickly. Every part of the sentence contributes 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 tool's complexity (comparing yield opportunities across protocols), no annotations, and no output schema, the description is incomplete. It doesn't explain what the comparison outputs (e.g., a list, table, or metrics), how results are structured, or any behavioral aspects like data freshness or limitations. 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?
The input schema has 100% description coverage, clearly documenting all parameters ('assets', 'amount', 'duration') with examples and constraints. The description adds no additional semantic information beyond the schema, such as explaining how 'assets' relate to protocols or what 'yield opportunities' means in practice. 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: 'Compares yield opportunities for specific assets across different protocols.' It specifies the verb ('compares'), resource ('yield opportunities'), and scope ('specific assets across different protocols'), making the function evident. However, it doesn't explicitly differentiate from sibling tools like 'getYieldTool' or 'compareYieldHistoryTool', which might have overlapping or related purposes, so it doesn't 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. It doesn't mention prerequisites, exclusions, or comparisons to sibling tools such as 'getYieldTool' or 'compareYieldHistoryTool', leaving the agent to infer usage context. This lack of explicit guidance reduces its effectiveness in 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 estimates gas cost but doesn't explain how it works (e.g., uses current gas prices, network data), potential limitations (e.g., accuracy, network dependencies), or error conditions. For a tool with no 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 clearly states the tool's purpose without unnecessary words. It's front-loaded with the key action and output, making it easy to understand at a glance. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of gas estimation (involving network data and currency conversion) and the lack of annotations and output schema, the description is insufficient. It doesn't explain the estimation method, return format, or potential inaccuracies, leaving gaps for the agent to infer behavior. This is inadequate for a tool with no structured support.
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, so the schema fully documents all parameters (chainId, gasUnits, maxFeePerGas, maxPriorityFeePerGas). The description adds no additional parameter details beyond what the schema provides, such as examples or usage context. This meets the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estimate the gas cost for a transaction in both native token and USD.' It specifies the action (estimate), resource (gas cost), and output format (both native token and USD). However, it doesn't differentiate from sibling tools like 'estimateGas' or 'getGasPrice,' which appear to be related but 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 sibling tools like 'estimateGas' or 'getGasPrice,' nor does it specify prerequisites, such as needing transaction details or network selection. 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 returns token balances and metadata, which implies a read-only operation, but doesn't address critical aspects like rate limits, error handling (e.g., invalid addresses), data freshness, or pagination for large portfolios. 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, well-structured sentence that efficiently conveys the core functionality: input (wallet address), action (return), and output (all token balances with metadata). There's no wasted verbiage, and it's front-loaded with essential information, 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 (querying all token balances with metadata), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return structure (e.g., list of tokens with balances and metadata details), potential limitations (e.g., only supports certain blockchains), or prerequisites (e.g., address must be on a supported network). For a tool with rich data output, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'Given a wallet address', which aligns with the single 'address' parameter in the schema. However, schema description coverage is 0%, so the schema provides no details about the parameter. The description adds minimal semantics by indicating it's a wallet address, but doesn't specify format (e.g., Ethereum address with 0x prefix), validation, or examples. This is a baseline score given the schema's lack of descriptions.
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: 'Given a wallet address, return all token balances the account holds, including coin metadata.' It specifies the action (return token balances), resource (account/wallet), and scope (all tokens with metadata). However, it doesn't explicitly differentiate from siblings like 'getAddressTokenBalances' or 'getBalance', which appear similar, so it doesn't reach the highest clarity level.
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 'getAddressTokenBalances', 'getBalance', and 'getCoinBalance', there's no indication of differences in scope (e.g., all tokens vs. specific tokens) or output format. This leaves the agent to guess based on tool names alone, which is insufficient for effective 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 fetching a 'suggested fee quote' via a REST API, which implies a read-only, non-destructive operation, but doesn't detail potential rate limits, authentication needs, error conditions, or the format of the returned quote. 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's front-loaded with the key action and resource, making it easy to parse and understand quickly. Every part of the sentence contributes 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 six required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the returned fee quote includes (e.g., breakdown of costs, validity period), how to interpret the result, or any dependencies on external factors like network conditions. This leaves the agent with incomplete 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 input schema has 100% description coverage, clearly documenting all six required parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters or providing examples. 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 action ('fetches a suggested fee quote') and resource ('for a cross-chain asset bridge using the Across Protocol REST API'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getQuote' or 'estimateGasCost', which might also provide pricing information, 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 'getQuote' or other fee estimation tools in the sibling list. It lacks context about prerequisites, typical use cases, 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 full burden. It states what the tool does but reveals nothing about behavioral traits: no indication of read/write nature, rate limits, authentication needs, pagination, error conditions, or what 'validated' entails operationally. For a query tool with no annotation coverage, this leaves significant gaps in understanding how it 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, focused sentence with zero wasted words. It front-loads the core purpose efficiently. Every word earns its place without redundancy or 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 2-parameter query tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'blocks validated' means, the return format, time ranges, or any behavioral constraints. With rich sibling tools and blockchain complexity, more context is needed 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 50% (only 'chain' has a description). The description mentions 'specific address' which aligns with the 'address' parameter but adds no semantic detail beyond the schema's type declaration. It doesn't explain address format requirements or what 'validated' means for the output. With partial schema coverage, the description provides minimal compensatory 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 verb ('Get') and resource ('blocks validated by a specific address'), making the purpose understandable. It distinguishes from siblings like getBlock or getAddressTransactions by focusing on validation activity rather than block data or transaction history. However, it doesn't specify what 'validated' means in this context (e.g., mined, attested, approved).
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 for address-related queries (getAddressInfo, getAddressTransactions, etc.), there's no indication of when 'blocks validated' is the appropriate metric versus other address activities. No prerequisites, exclusions, or comparison to similar tools 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 for behavioral disclosure. It states what the tool does but provides no information about rate limits, authentication requirements, pagination, response format, error conditions, or whether this is a read-only operation. 'Get' implies read-only, but this isn't explicitly confirmed.
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 simple data retrieval 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 2 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'internal transactions' are (versus regular transactions), doesn't describe the return format, and provides no behavioral context. Given the complexity of blockchain data and multiple similar sibling tools, 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 50% (only the 'chain' parameter has a description). The tool description adds no parameter information beyond what's in the schema. It doesn't explain what 'internal transactions' are, what format the address should be in, or provide context about the two required parameters. Baseline 3 is appropriate since the schema covers half 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 action ('Get internal transactions') and target resource ('for a specific address'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'getAddressTransactions' or 'getTransactionInternalTransactions', which handle related but different transaction types.
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 dealing with transactions (getAddressTransactions, getTransactionInternalTransactions, getAddressTokenTransfers, etc.), there's no indication of what distinguishes internal transactions from other transaction types or when this specific tool is 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 the full burden of behavioral disclosure. It states 'Get logs' which implies a read-only operation, but doesn't specify what 'logs' include (e.g., transaction logs, event logs), whether there are rate limits, authentication requirements, or what the output format looks like. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the key information ('Get logs for a specific address').
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 2 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'logs' are, their format, or any behavioral aspects like error handling or limitations. Given the complexity of blockchain data retrieval and lack of structured documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'chain' has a description), and the description doesn't add any parameter details beyond what's in the schema. It mentions 'address' but doesn't explain what type of address (e.g., Ethereum address format) or provide context for the 'chain' parameter. With moderate schema coverage, this meets the baseline but doesn't compensate for gaps.
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 'logs for a specific address', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getAddressTransactions' or 'getAddressTokenTransfers' that might also retrieve address-related data, 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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools that retrieve address data (e.g., getAddressTransactions, getAddressTokenTransfers), the description lacks any context about what makes 'logs' distinct or when this specific tool is 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 the full burden of behavioral disclosure. While it indicates a read operation ('Get list'), it lacks details on permissions, rate limits, pagination, error handling, or output format. For a tool with no 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 functionality without unnecessary words. It directly communicates the tool's purpose and grouping feature, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of querying NFTs across blockchains, the lack of annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It does not address behavioral aspects like response structure, error cases, or usage constraints, leaving the agent with inadequate context for reliable 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 50% (only the 'chain' parameter has a description). The tool description does not add any parameter-specific information beyond what the schema provides, such as explaining the 'address' parameter format (e.g., Ethereum address) or clarifying the 'chain' parameter's enum values. With moderate schema coverage, the baseline score of 3 is appropriate, as the description does not compensate for the coverage gap.
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 list of NFTs owned by address, grouped by collection.' It specifies the verb ('Get'), resource ('NFTs'), and grouping criteria ('grouped by collection'). However, it does not explicitly differentiate from sibling tools like 'getAddressNFTs', which might have different grouping or filtering behavior.
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, exclusions, or comparisons to sibling tools such as 'getAddressNFTs' or 'getNFTMetadata', leaving the agent to infer usage context solely from the tool name and 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 of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't mention any constraints like rate limits, pagination, error conditions, or what the output format looks like (e.g., list structure, fields included). For a tool with no annotation coverage, this leaves significant gaps in understanding how it 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 with zero wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place by conveying essential information without 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 complexity of querying NFTs (which can involve pagination, metadata, and varied outputs), no annotations, no output schema, and low parameter coverage, the description is inadequate. It doesn't address what the tool returns (e.g., NFT IDs, metadata, images), how results are structured, or any limitations, leaving 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 50% (only 'chain' has a description), and the description adds no parameter information beyond what's implied by the name. It doesn't explain what 'address' should be (e.g., Ethereum address format), clarify the chain IDs, or mention any optional parameters. With low schema coverage, the description fails to compensate, resulting in minimal added value over 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 'Get list of NFTs owned by address' clearly states the verb ('Get list') and resource ('NFTs owned by address'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getAddressNFTCollections' or 'getNFTMetadata', which could cause confusion about scope or granularity.
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 that might overlap (e.g., 'getAddressNFTCollections', 'getNFTMetadata'), the description offers no context about whether this returns raw NFTs, collections, metadata, or filtered results, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it is likely non-destructive, but lacks details on permissions, rate limits, return format, or pagination. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 is front-loaded and directly conveys the core functionality, 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?
Given no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is inadequate. It lacks details on behavior, return values, and usage context, making it incomplete for effective tool invocation in a complex environment 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 50% (only 'chain' has a description), so the description must compensate. It mentions 'a specific address', which aligns with the 'address' parameter, adding some meaning. However, it does not explain parameter constraints or usage beyond what is implied, resulting in a 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 verb 'Get' and the resource 'all token balances for a specific address', making the purpose evident. However, it does not differentiate from siblings like 'getAddressTokens' or 'getAddressCoinBalanceHistory', which might offer similar or 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. With many sibling tools related to addresses and tokens (e.g., 'getAddressTokens', 'getAddressCoinBalanceHistory'), there is no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
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 'filtering and pagination', which hints at query capabilities, but doesn't specify what filtering options exist, pagination limits, rate limits, authentication needs, or error conditions. For a read operation with no annotation coverage, this is insufficient to inform safe and effective use.
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 front-loaded with the core purpose and includes key behavioral hints ('filtering and pagination'). Every element 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.
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 filtering/pagination), lack of annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't explain what data is returned, how filtering works, pagination behavior, or error handling. For a tool in a crowded sibling set, more context is needed to ensure correct 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 50% (only the 'chain' parameter has a description). The description adds no specific details about parameters beyond implying general 'filtering' (which might relate to unspecified parameters not in the schema). It doesn't clarify the 'address' parameter format (e.g., Ethereum address) or explain how filtering/pagination work with the given inputs. Baseline 3 is appropriate as the schema covers half the parameters, but the description doesn't compensate for the gaps.
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 'Get token balances with filtering and pagination' clearly states the verb ('Get') and resource ('token balances'), and specifies additional capabilities ('filtering and pagination'). However, it doesn't explicitly distinguish this tool from sibling tools like 'getAddressTokenBalances' or 'getAddressInfo', which likely have overlapping functionality in the same domain.
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 address data (e.g., 'getAddressTokenBalances', 'getAddressInfo', 'getBalance'), there's no indication of specific use cases, prerequisites, or comparisons. This leaves the agent to guess 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 but only states the basic action without details on permissions, rate limits, pagination, or response format. It fails to describe how transfers are retrieved (e.g., time range, token types) or any constraints, leaving significant gaps for a 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 no wasted words, making it easy to parse and front-loaded with the core action. It is 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 no annotations, no output schema, and incomplete parameter coverage (50%), the description is inadequate. It does not explain return values, behavioral traits, or usage context, making it insufficient for an AI agent to fully understand and invoke the tool correctly in a complex environment 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 50% (only 'chain' has a description), and the description adds no additional parameter semantics beyond what the schema provides. It mentions 'address' but gives no context on format or validation. Baseline is 3 as the schema covers half the parameters, but the description does not compensate for the lack of details on 'address'.
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 ('token transfers for a specific address'), making the purpose understandable. However, it does not differentiate from sibling tools like 'getTokenTransfers' or 'getTransactionTokenTransfers', which might have overlapping or distinct scopes, 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 no guidance on when to use this tool versus alternatives, such as 'getTokenTransfers' or 'getAddressTransactions', nor does it mention prerequisites or exclusions. It lacks explicit context 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 the full burden of behavioral disclosure. It only states what the tool does without mentioning any behavioral traits such as rate limits, pagination, error handling, or what the output looks like (e.g., format, fields). For a tool that likely queries blockchain data, this omission is significant, as it leaves the agent without crucial 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 extremely concise—a single sentence with no wasted words. It is front-loaded and directly states the tool's purpose without unnecessary elaboration, making it easy to parse quickly. This efficiency is appropriate for a simple tool, though it may sacrifice detail for brevity.
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 (fetching transactions from blockchain networks), lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not cover behavioral aspects, output format, or usage distinctions from siblings. For a tool with potential nuances in blockchain data retrieval, this leaves the agent with inadequate information 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 50% (only the 'chain' parameter has a description). The description does not add any parameter details beyond what the schema provides, such as explaining the 'address' parameter format (e.g., Ethereum address) or clarifying the 'chain' parameter's numeric vs. string input. Since schema coverage is moderate, the baseline is 3, as the description neither compensates for gaps nor adds meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get transactions for a specific address.' It specifies the verb ('Get') and resource ('transactions'), making it easy to understand what the tool does. However, it does not differentiate from sibling tools like 'getTransaction', 'getAddressTokenTransfers', or 'getAddressInternalTransactions', which also retrieve transaction-related data for addresses, leaving some ambiguity about its unique 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. With many sibling tools that fetch transaction data (e.g., 'getTransaction', 'getAddressTokenTransfers'), there is no indication of whether this tool returns all transactions, specific types, or how it differs. This lack of context makes it difficult for an agent to choose correctly 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 the full burden of behavioral disclosure. It only states what the tool does ('Get withdrawals'), but doesn't describe any behavioral traits such as rate limits, authentication needs, response format, pagination, or error handling. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's complexity, earning full marks 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'withdrawals' means in this context, the return format, or any behavioral aspects. For a tool with no structured metadata, this minimal description 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 50% (only the 'chain' parameter has a description). The description adds no parameter semantics beyond what's in the schema—it doesn't explain what 'withdrawals' entails or provide context for the 'address' parameter. However, with 2 parameters and partial schema coverage, the baseline is 3 as the schema does some work, but the description doesn't compensate for gaps.
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 'withdrawals for a specific address', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getAddressTransactions' or 'getAddressTokenTransfers', which might also involve address-specific data retrieval, so it lacks 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. With many sibling tools that retrieve address-related data (e.g., getAddressTransactions, getAddressTokenTransfers), there's no indication of what makes withdrawals unique or when this specific tool is 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 the full burden of behavioral disclosure. While it correctly describes a read operation ('Gets'), it lacks details about 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, clear sentence that efficiently conveys the core functionality without any wasted words. It is front-loaded with the essential information, 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 complexity of blockchain interactions, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the balance value represents (e.g., units, decimals), potential errors, or how to interpret results, which are critical for an agent to use this tool effectively 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?
The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional semantic context about the parameters beyond what the schema provides (e.g., explaining what 'chainId' defaults to or how addresses should be formatted). 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 ('ERC20 token balance of an address'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'getCoinBalance' or 'getAddressTokenBalances', which appear to serve related functions, 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. With many sibling tools that seem related to balances (e.g., getCoinBalance, getAddressTokenBalances), there is no indication of how this tool differs or when it should be preferred, leaving the agent to guess based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('perform a search query') but lacks details on rate limits, authentication needs, error handling, or what the search returns (e.g., format, pagination). For a tool with no 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 directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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?
Given the complexity of a blockchain search tool with no annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't cover behavioral aspects, return values, or usage context, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
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 50% (only the 'chain' parameter has a description). The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain the 'query' parameter's format or examples. Since the schema covers half the parameters, the baseline is 3, but the description fails to compensate for the undocumented 'query' parameter.
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 ('perform a search query') and the resource ('blocks, transactions, addresses, or tokens on the blockchain'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'lookupENS' or 'resolveENS' that also involve blockchain lookups, 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 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 for specific blockchain queries (e.g., 'getAddressInfo', 'getTransaction'), there's no indication of when a general search is preferred over targeted tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool's function but doesn't describe return format (e.g., list of transactions, pagination), error conditions (e.g., invalid block), rate limits, or authentication needs. For a read operation with no 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 with zero waste. It front-loads the core purpose ('Get transactions within a specific block') without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (blockchain data retrieval), lack of annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't cover behavioral aspects like response structure, error handling, or usage context, leaving significant gaps for an AI agent to operate 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 50% (only 'chain' has a description). The description adds no parameter-specific information beyond implying 'blockNumberOrHash' is required. It doesn't clarify parameter formats (e.g., numeric vs. string for blockNumberOrHash) or usage. With low schema coverage, the description fails to compensate, resulting in minimal added 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 'Get transactions within a specific block' clearly states the verb ('Get') and resource ('transactions'), specifying the scope ('within a specific block'). It distinguishes from siblings like 'getBlock' (which likely returns block metadata) and 'getTransaction' (which fetches individual transactions). However, it doesn't explicitly differentiate from 'getAddressTransactions' or 'getBlockWithdrawals', which slightly reduces 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, such as needing a valid block identifier, or compare it to siblings like 'getBlock' (for block details) or 'getAddressTransactions' (for address-specific transactions). 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 retrieves data ('Get'), implying a read-only operation, but doesn't specify if it's safe, has rate limits, requires authentication, or details the return format. 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 with no wasted words, clearly front-loading the purpose. It's appropriately sized for a simple retrieval tool, 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 incomplete parameter documentation (50% coverage), the description is insufficient. It doesn't explain what the tool returns, potential errors, or behavioral traits like safety or performance, making it inadequate for a tool with two required parameters in a complex blockchain 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 50%, with the 'chain' parameter well-documented but 'blockNumberOrHash' lacking a description. The tool description doesn't add any parameter details beyond the schema, such as explaining what 'blockNumberOrHash' entails or providing examples. With partial schema coverage, the description doesn't compensate for the gaps, resulting in a 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 'Get withdrawals within a specific block' clearly states the verb ('Get') and resource ('withdrawals'), with the scope 'within a specific block' providing context. However, it doesn't differentiate from sibling tools like 'getAddressWithdrawals' or 'getTransaction', which might retrieve withdrawals by address or transaction instead of block.
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 compare it to sibling tools such as 'getAddressWithdrawals' or 'getBlockTransactions', 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 provides minimal behavioral information. It states this is a read operation ('fetches'), but doesn't disclose rate limits, data freshness, error conditions, authentication requirements, or what format the information is returned in. The description doesn't contradict any annotations since none exist.
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 essential information without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the key action and 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 no annotations and no output schema, the description is insufficient. It doesn't explain what format the information is returned in, what specific data fields are included beyond 'balance and tx count', or any limitations of the data. Given the complexity of blockchain data retrieval and the lack of structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'address' well-documented. The description adds context about what type of address ('Bitcoin address') but doesn't provide additional semantic information 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 action ('fetches information') and resource ('Bitcoin address'), specifying the type of information retrieved ('balance and tx count'). It distinguishes from many siblings by focusing on Bitcoin addresses, but doesn't explicitly differentiate from 'getAddressInfo' which appears to be a more general version.
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 'getAddressInfo' or 'getBalance'. The description implies Bitcoin-specific functionality, but doesn't explicitly state this as a distinguishing factor or mention any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a list but does not disclose behavioral traits like error handling, rate limits, data format, or whether it's read-only. This is inadequate for a tool with no annotation support.
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 functionality without any wasted words. It is appropriately sized for the tool's simplicity.
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 simple input schema, the description is incomplete. It fails to explain return values, error cases, or behavioral context, making it insufficient for an agent to fully understand the tool's 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%, with the parameter 'blockHash' fully documented in the schema. The description adds no additional meaning beyond implying the parameter is used to fetch txids, aligning with the baseline score 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 ('Returns') and resource ('list of transaction IDs in a block'), specifying the action and target. However, it does not explicitly differentiate from sibling tools like 'getBlockTransactions' or 'getBtcTxDetails', which might have overlapping functionality, 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 no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, exclusions, or comparisons to siblings such as 'getBlockTransactions' or 'getBtcTxDetails', 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 full burden for behavioral disclosure. It states it 'fetches details' but doesn't describe what details are returned, whether it's a read-only operation, potential rate limits, error conditions, or data freshness. The description is minimal and leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's function. There's no wasted verbiage or unnecessary elaboration, making it efficiently front-loaded with 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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'details' are returned, the format of the response, potential errors, or limitations. Given the complexity of blockchain transaction data and the lack of structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'txid' clearly documented in the schema. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline expectation but doesn't provide 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 ('fetches details') and resource ('Bitcoin transaction ID'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'getTransaction' or 'getTransactionInfo', but the Bitcoin-specific focus 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 like 'getTransaction' or 'getTransactionInfo' from the sibling list. It doesn't mention prerequisites, limitations, or appropriate contexts for Bitcoin transaction queries specifically.
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 checking reversibility but does not specify whether this is a read-only operation, what permissions are required, if there are rate limits, or what the output format looks like (e.g., boolean, detailed status). This leaves significant gaps for an agent to understand 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, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently conveys the core purpose without unnecessary elaboration, which is ideal for clarity and quick understanding.
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 for a tool that likely returns a boolean or status about transfer reversibility. It does not explain the return value, error conditions, or behavioral traits like safety or side effects, leaving the agent with insufficient context to use it effectively beyond the basic parameter.
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 'transferId' clearly documented as 'The transfer ID to check'. The description does not add any extra meaning beyond this, such as format examples or constraints. 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 'Check if a transfer can be reversed' clearly states the action (check) and resource (transfer reversibility), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'intentReverseSlowTransfer' or 'getSlowTransferApprovalRequired', which might handle related operations, 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 no guidance on when to use this tool versus alternatives, such as 'intentReverseSlowTransfer' for performing the reversal or 'getSlowTransferApprovalRequired' for checking approval needs. It lacks context on prerequisites, timing, or exclusions, offering only a basic functional 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 states it 'fetches' metadata, implying a read-only operation, but doesn't mention potential side effects, authentication needs, rate limits, error conditions, or the format/scope of the returned data. 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 a single, efficient sentence that front-loads the purpose and key details. Every word contributes meaning without redundancy, making it appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that fetches metadata. It doesn't explain what 'pools' refers to, the data format, potential limitations, or how errors are handled. In a context with many sibling tools, more guidance is needed to ensure correct 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 description mentions 'Given a coin symbol' as the input, which aligns with the single required 'symbol' parameter in the schema. However, with 0% schema description coverage, it doesn't add details like symbol format, case sensitivity, or examples. The baseline is 3 since the schema covers the parameter structure, but the description provides only minimal semantic 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 verb ('fetch') and resource ('metadata about a coin'), specifying the type of data returned (name, symbol, total supply, image, pools). However, it doesn't explicitly differentiate from sibling tools like 'getCoinBalance' or 'getCoinTokenMetadata', which appear to be related but distinct operations.
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 might overlap (e.g., 'getCoinBalance', 'getCoinTokenMetadata'), there's no indication of prerequisites, context, or exclusions for using this specific metadata-fetching tool.
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. It mentions ordering and default behavior, but lacks critical details like pagination handling (implied by limit/offset but not explained), rate limits, authentication needs, error conditions, or what the output looks like (no output schema). This is insufficient for a tool with 3 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.
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. Every word earns its place, with no redundant information or fluff.
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 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter meanings, output format, error handling, or behavioral constraints, leaving significant gaps for an AI agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'coinId' is required to specify the coin, and mentions ordering which relates to the output, but doesn't explain what 'coinId' represents, the purpose of 'limit' and 'offset', or their interaction. The description adds minimal value beyond the bare 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 resource ('list of holders for a given coin'), with specific ordering ('ordered by balance descending by default'). However, it doesn't explicitly distinguish from sibling tools like 'getNativeCoinHolders' or 'getTokenHolders', which might serve similar purposes for different asset types.
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 'getNativeCoinHolders' or 'getTokenHolders' from the sibling list. The description implies it's for coins, but doesn't clarify if this is for native coins, tokens, or specific types, leaving usage context ambiguous.
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 function. It doesn't disclose whether this is a read-only operation (implied but not explicit), potential rate limits, authentication needs, error conditions, or what format the name is returned in (string, object, etc.). For a tool with no annotation coverage, this is insufficient behavioral disclosure.
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 states exactly what the tool does without any unnecessary words. It's perfectly front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too minimal. It doesn't explain what the return value looks like (string name? object with metadata?), error conditions, or behavioral constraints. Given the complexity of blockchain interactions and the lack of structured output documentation, the description should provide more complete 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?
The schema description coverage is 100%, so both parameters ('token' and 'chainId') are fully documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets') and resource ('name of an ERC20 token'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getSymbol' or 'getTokenInfo' that might retrieve similar token metadata, so it doesn't achieve full 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 like 'getSymbol' or 'getTokenInfo' from the sibling list. There's no mention of prerequisites, context, or comparison with other token metadata retrieval 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 full burden. It mentions fetching 'latest state' which implies read-only behavior, but doesn't disclose important behavioral traits like whether this requires authentication, rate limits, error conditions, response format, or if it's a real-time query versus cached 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?
Single sentence that efficiently conveys the core purpose. No wasted words or unnecessary elaboration. The structure is front-loaded with the main action and immediately specifies what information is included.
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, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain the single required parameter, doesn't describe the return format, and provides minimal behavioral context. Given the complexity of DeFi pool data, more guidance 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 0%, so the description must compensate. It doesn't mention the 'poolId' parameter at all, nor provide any context about what format it expects or where to obtain valid pool IDs. The baseline would be lower, but with only 1 parameter, some understanding can be inferred from 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 action ('Fetch') and resource ('pool'), specifying what information is retrieved ('latest state, including reserves and price information'). It distinguishes from some siblings like 'getUniV3Pool' by being generic, but doesn't explicitly differentiate from all pool-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'getUniV3Pool' or 'getPoolFeeData'. The description implies it's for retrieving pool state, but provides no context about prerequisites, limitations, or when other tools might be 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?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Gets'), implying non-destructive behavior, but lacks details on permissions, rate limits, error conditions, or return format. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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, 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 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't clarify parameter meanings, behavioral constraints, or return values, leaving the agent with inadequate context 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 0%, so the description must compensate. It implies parameters identify 'a specific LP position' but doesn't explain what 'tokenId' and 'chainId' represent or their expected formats. This adds minimal semantic value beyond the schema's property names, meeting the baseline for partial 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 ('Gets') and resource ('detailed information about a specific LP position'), making the purpose explicit. However, it doesn't differentiate from sibling tools like 'getUserPositions' or 'getPool' that might also retrieve position-related data, 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. With siblings like 'getUserPositions' (likely listing multiple positions) and 'getPool' (possibly pool-level data), there's no indication of this tool's specific context or prerequisites for retrieving details of a single position.
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 this is a read operation ('Get information'), implying it's non-destructive, but doesn't disclose behavioral traits like rate limits, authentication needs, response format, or error conditions. For a tool with no annotations, this leaves significant gaps in understanding how it 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 front-loads the core purpose without unnecessary details. It avoids redundancy and wastes no words, though it could be slightly more structured by separating key concepts (e.g., tokens vs. balances vs. transfers).
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 multiple SLOW data types), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what information is returned, how results are formatted, or any limitations (e.g., pagination). For a read tool with no structured behavioral data, this leaves the agent under-informed.
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 all parameters (user, tokenId, transferId). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. 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 ('Get information') and the resource ('tokens, unlocked balances, and pending transfers in SLOW'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'getSlowGuardianInfo' or 'getSlowTransferApprovalRequired', which also query SLOW-related data but for different 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 no guidance on when to use this tool versus alternatives. With many sibling tools querying SLOW or blockchain data (e.g., 'getSlowGuardianInfo', 'getTokenInfo'), there's no indication of context, prerequisites, or exclusions 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 of behavioral disclosure. While 'Check' implies a read-only operation, it doesn't specify whether this is a simple lookup, requires authentication, has rate limits, returns structured data, or has side effects. For a tool with 4 required parameters in a financial/blockchain context, 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 directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and contains zero redundant information, 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 4 required parameters in a blockchain/transfer approval context and no annotations or output schema, the description is insufficient. It doesn't explain what constitutes a 'slow transfer', what 'guardian approval' means in this system, what format the response takes (boolean, object, etc.), or error conditions. Given the complexity implied by the parameter set and sibling tools, 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%, with all parameters clearly documented in the schema itself (user, to, id, amount). The description doesn't add any parameter-specific context beyond implying these are needed to evaluate approval requirements. This meets the baseline for high schema coverage, but doesn't enhance understanding of how parameters interact or their validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('if a transfer needs guardian approval'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getSlowGuardianInfo' or 'getSlowStatus', which appear related to the same 'slow' transfer system, leaving some ambiguity about scope boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'getSlowGuardianInfo', 'getSlowStatus', 'getCanReverseSlowTransfer', and various 'intent' tools for slow transfers, there's no indication of prerequisites, appropriate contexts, or exclusions. The agent must 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 states the tool retrieves data, implying a read-only operation, but doesn't mention any behavioral traits such as rate limits, authentication requirements, error handling, or response format. For a tool 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 extremely concise and front-loaded: a single sentence that directly states the tool's purpose without any fluff or redundancy. Every word earns its place, making it efficient for quick understanding.
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 retrieving contract data, no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is insufficient. It doesn't address what the output includes (e.g., format of source code, ABI structure), error cases, or usage constraints, leaving significant gaps for the agent to navigate.
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 what the input schema provides. With schema description coverage at 50% (only 'chain' has a description), the 'address' parameter is undocumented in both schema and description. The description doesn't explain what 'address' represents (e.g., contract address) or provide any additional context, so it doesn't compensate for the coverage gap, resulting in a 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 tool's purpose: 'Retrieve the source code, ABI and metadata a contract.' It specifies the verb ('Retrieve') and the resources (source code, ABI, metadata), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'getCode' or 'getSmartContracts', 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. With many sibling tools (e.g., 'getCode', 'getSmartContracts', 'getTokenMetadata'), there's no indication of specific contexts, prerequisites, or exclusions. This lack of differentiation leaves the agent to guess based on 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 only states it 'fetches' events without disclosing behavioral traits like rate limits, pagination (though limit parameter exists), authentication needs, data freshness, or error conditions. It mentions optional filtering but doesn't explain default behavior when parameters are omitted.
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 ('Fetch recent swap events') and includes the optional filtering. Every word earns its place with no redundancy or 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 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a 'swap event', the return format, error handling, or practical usage constraints. The agent would struggle to use this tool effectively without additional 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 0%, so the schema provides no parameter documentation. The description mentions 'pool' (mapping to poolId) and 'block range' (mapping to startBlock/endBlock) but doesn't explain the limit parameter or provide format details for any parameters. It adds some meaning but doesn't fully compensate for the complete lack of schema descriptions.
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 resource ('recent swap events for a given pool'), with optional filtering by block range. It distinguishes from siblings like 'getPool' or 'getTransaction' by focusing specifically on swap events. However, it doesn't explicitly differentiate from similar event-fetching tools like 'getAddressLogs' or 'getTransactionLogs'.
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 with 'optionally filtered by block range' but offers no explicit when-to-use advice, no mention of prerequisites, and no alternatives among the many sibling tools. There's no indication of when to choose this over other data-fetching tools in the extensive 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 offers minimal behavioral insight. It doesn't mention whether this is a read-only operation, what happens with invalid token addresses, rate limits, authentication requirements, or response format. 'Gets' implies a safe read, but explicit confirmation would help.
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 front-loaded with the core purpose and appropriately sized for a simple lookup 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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the return value looks like (string format, error cases), nor does it provide behavioral context needed for reliable agent usage. The 100% schema coverage helps parameters, but overall completeness is poor.
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. The description adds no additional parameter context beyond what's in the schema (e.g., format examples, edge cases, or chainId implications). 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 ('Gets') and resource ('symbol of an ERC20 token'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getTokenInfo' or 'getTokenMetadata' that might also provide symbol information, 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?
No guidance is provided on when to use this tool versus alternatives like 'getTokenInfo' or 'getTokenMetadata' which may return symbol data along with other information. The description lacks any context about preferred use cases 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 states the tool 'gets' data, implying a read-only operation, but doesn't mention potential rate limits, authentication needs, data freshness, or error conditions. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action, resource, and data source, 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?
Given the complexity (4 parameters with nested objects) and lack of annotations or output schema, the description is insufficient. It doesn't explain what the returned chart data looks like (e.g., format, fields), potential limitations, or how to interpret results. For a tool fetching historical price data, this leaves too many unknowns 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%, meaning all parameters are documented in the schema itself. The description doesn't add any additional meaning or context beyond what's in the schema (e.g., it doesn't explain token format conventions or period implications). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets historical price chart data') and resource ('for one or more tokens from DeFi Llama'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getCryptoPrice' or 'getTransactionsChart', which might offer related price or chart 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. With many sibling tools related to tokens, prices, and charts (e.g., 'getCryptoPrice', 'getTransactionsChart'), there's no indication of context, prerequisites, or exclusions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the retrieval action but fails to mention critical details like whether this is a read-only operation, potential rate limits, pagination behavior (implied by 'page' and 'offset' parameters but not explained), or expected output format. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 function without unnecessary words. It is front-loaded with the main action and resource, making it easy to parse quickly, which is ideal 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 of blockchain data retrieval, no annotations, no output schema, and low schema description coverage, the description is insufficient. It lacks details on behavioral traits (e.g., pagination, rate limits), output format, and differentiation from similar tools, making it incomplete for effective agent use in this 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 low at 25%, with only the 'chain' parameter having a description. The tool description adds no additional parameter semantics beyond what's implied by the tool name (e.g., 'tokenContract' is inferred but not explained). However, since there are only 4 parameters and the tool name strongly hints at their purpose, the baseline score of 3 is appropriate, though more detail would improve clarity.
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') and target resources ('token holders and their balances for a given token'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getHolders' or 'getNativeCoinHolders', which appear to serve similar purposes, missing an opportunity for precise 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 such as 'getHolders' or 'getNativeCoinHolders'. The description lacks context about prerequisites, exclusions, or typical scenarios for application, leaving the agent to infer usage from 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 full burden but only states it 'fetches metadata' without detailing what metadata is returned, whether it's a read-only operation, potential rate limits, error conditions, or authentication needs. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple fetch operation.
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 2 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what metadata is returned, how results are structured, or any behavioral aspects. The agent would need to guess about the tool's behavior and output format.
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 50% (only the 'chain' parameter has a description). The tool description doesn't add any parameter-specific information beyond what's in the schema. Since the schema partially documents parameters, this meets the baseline for minimal adequacy but doesn't compensate for the coverage gap.
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 'Fetch metadata for a token contract' clearly states the action (fetch) and resource (token contract metadata). It distinguishes from siblings like getTokenMetadata (which might focus on different metadata aspects) and getTokenHolders (which focuses on holders rather than general metadata), though the 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?
The description provides no guidance on when to use this tool versus alternatives like getTokenMetadata or getCoinTokenMetadata. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from 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 full burden for behavioral disclosure. It mentions 'pagination support' which is useful context, but fails to describe what the tool returns (format, structure), error conditions, rate limits, authentication requirements, or whether it's a read-only operation. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a list operation and front-loads the core purpose immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how pagination works, error handling, or provide sufficient parameter guidance. For a data retrieval tool with multiple parameters and no structured output documentation, the description should do more to help an agent understand how 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 only 25% (only the 'chain' parameter has a description), so the description needs to compensate but doesn't. It mentions 'token contract' which maps to the 'tokenContract' parameter, and 'pagination support' which hints at 'page' and 'offset' parameters, but provides no additional semantic context about parameter formats, constraints, or usage beyond what's minimally implied. The description adds some value but doesn't adequately compensate for the low 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 transfers') and target resource ('for a specific token contract'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'getAddressTokenTransfers' or 'getTransactionTokenTransfers', which appear to serve similar purposes but with different scoping parameters.
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 'getAddressTokenTransfers' or 'getTransactionTokenTransfers' from the sibling list. It mentions 'pagination support' which hints at usage for large datasets, but offers no explicit when/when-not criteria or alternative recommendations.
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 information, implying a read-only operation, but does not specify if it requires authentication, has rate limits, what the return format is, or any error conditions. 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 appropriately sized and front-loaded, with no wasted 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 retrieving transaction details, no annotations, no output schema, and only 50% schema description coverage, the description is incomplete. It lacks information on return values, error handling, and behavioral traits, making it inadequate for full 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?
The schema description coverage is 50% (only 'chain' has a description), and the description does not add any details about parameters beyond what the schema provides. It mentions 'transaction hash' which aligns with the 'txhash' parameter but offers no additional semantics. With partial schema coverage, the description does not fully compensate, resulting in a 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 verb ('Retrieve') and resource ('detailed information for a given transaction hash'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'getTransaction', 'getTransactionReceipt', or 'getTransactionSummary', 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 such as 'getTransaction' or 'getTransactionReceipt', nor does it mention any prerequisites or context for usage. It lacks explicit when-to-use or when-not-to-use instructions.
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 the tool does without behavioral details. It doesn't disclose whether this is a read-only operation (implied by 'Retrieve'), potential rate limits, authentication needs, error conditions, or what format the internal transactions are returned in. For a tool 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 that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration. It follows best practices for concise tool descriptions.
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 2 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes 'internal transactions', what data they contain, how results are structured, or any limitations. Given the complexity of blockchain transaction data and lack of structured documentation, 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 50% (only 'chain' has a description). The description adds no parameter semantics beyond what's in the schema - it mentions 'given transaction' which relates to 'txhash' but provides no additional context about hash format, validation, or examples. With moderate schema coverage, the baseline 3 is appropriate as the description doesn't compensate for the undocumented 'txhash' parameter.
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 ('internal transactions'), specifying they occur 'within a given transaction'. It distinguishes from siblings like getAddressInternalTransactions by focusing on transaction-level rather than address-level data. However, it doesn't explicitly contrast with getTransactionRawTrace or getTransactionStateChanges which might provide similar transaction 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 like getAddressInternalTransactions (for address-focused queries) or other transaction detail tools. The description implies usage for internal transactions within a specific transaction but doesn't mention 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is to 'retrieve logs,' implying a read-only operation, but doesn't specify any behavioral traits like rate limits, authentication needs, error handling, or the format/structure of the returned logs. 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, clear sentence with no wasted words, making it highly concise and front-loaded. Every word contributes directly to stating the tool's purpose, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain data retrieval, no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is inadequate. It lacks details on what 'logs' entail (e.g., event logs, raw data), behavioral aspects, and how it differs from sibling tools, making it incomplete 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 50% (only the 'chain' parameter has a description), and the description adds no additional parameter semantics. It mentions 'specific transaction' which hints at the 'txhash' parameter, but provides no details on format (e.g., hex string) or constraints. With low schema coverage, the description doesn't compensate enough, resulting in a 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 verb 'retrieve' and the resource 'logs generated from a specific transaction,' making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'getTransaction' or 'getTransactionInfo,' which might retrieve related transaction data, leaving some ambiguity about its unique role.
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 transactions (e.g., getTransaction, getTransactionInfo, getTransactionTokenTransfers), there is no indication of what makes this tool specific for logs, such as whether it returns raw event logs, filtered data, or other details, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Retrieve' which implies a read-only operation, but does not disclose behavioral traits such as rate limits, authentication needs, error conditions, or what 'raw trace' entails (e.g., format, depth, or computational cost). This leaves significant gaps for an agent to understand 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, clear sentence with no wasted words. It is front-loaded with the core purpose, making it efficient and easy to parse, which is ideal 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 of blockchain transaction tools, no annotations, no output schema, and low schema description coverage, the description is inadequate. It lacks details on what 'raw trace' returns, error handling, or usage context, making it incomplete for effective tool selection and 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 50% (only 'chain' has a description), and the description does not add any parameter details beyond what the schema provides. It mentions 'specific transaction' which loosely relates to 'txhash', but no specifics on format or constraints. With low coverage, the description fails to compensate, resulting in minimal added 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 ('Retrieve') and resource ('raw trace information for a specific transaction'), making the purpose evident. However, it does not differentiate from sibling tools like getTransaction, getTransactionInfo, or getTransactionReceipt, which likely provide different types of transaction data, so it lacks 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. With many sibling tools related to transactions (e.g., getTransaction, getTransactionInfo), there is no indication of what makes 'raw trace' unique or when it should be preferred, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Retrieve' which implies a read operation, but doesn't disclose important behavioral traits like whether this requires authentication, rate limits, what format the chart data returns (JSON, image, etc.), or any pagination/limiting behavior for potentially large datasets.
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 retrieval tool and front-loads the essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'chart data' means in terms of format or structure, nor does it provide behavioral context about authentication, rate limits, or error conditions that would be important for an AI agent to use it correctly.
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 the single 'chain' parameter with its enum values and description. The description adds no additional parameter semantics beyond what's in the schema, 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.
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') and resource ('daily transaction statistics chart data'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'getTransactionSummary' or 'getAddressTransactions' that might also retrieve transaction-related data, 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. With many sibling tools dealing with transactions (e.g., getTransactionSummary, getAddressTransactions), there's no indication of when this chart-focused tool is appropriate versus other transaction retrieval 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 states it's a retrieval operation, implying read-only behavior, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what format the state changes are in. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for the tool's apparent 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 no annotations, no output schema, and moderate schema coverage (50%), the description is incomplete. It doesn't explain what 'state changes' entail, the return format, error conditions, or behavioral traits like rate limits. For a blockchain data retrieval tool with two parameters, this leaves significant gaps for an AI agent.
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 50% (only 'chain' has a description). The description adds no parameter semantics beyond what's in the schema—it doesn't explain what 'state changes' are, how 'txhash' should be formatted, or provide examples. Since schema coverage is moderate, the baseline is 3, but the description doesn't compensate for the undocumented 'txhash' parameter.
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 ('state changes that occurred during a transaction'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getTransaction', 'getTransactionInfo', or 'getTransactionSummary', which might retrieve different aspects of transactions.
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, context, or compare it to similar sibling tools (e.g., 'getTransaction' or 'getTransactionInfo'), 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 the full burden of behavioral disclosure. It states the action ('Retrieve') but does not cover critical aspects like whether this is a read-only operation, potential rate limits, error handling, or the format of returned data. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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?
Given the complexity of blockchain data retrieval, no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It fails to address behavioral traits, return values, or usage context, making it inadequate for a tool with two required parameters in this domain.
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 50% (only 'chain' has a description), and the description does not add any parameter-specific details beyond what the schema provides. It mentions 'given transaction' which relates to 'txhash', but offers no additional semantics. With moderate schema coverage, the baseline score of 3 is appropriate as the description does not compensate for the lack of 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 verb ('Retrieve') and resource ('all token transfers that occurred within a given transaction'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'getTokenTransfers' or 'getAddressTokenTransfers', which might have overlapping functionality, 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, such as sibling tools like 'getTokenTransfers' or 'getTransactionInfo'. It lacks context on prerequisites, exclusions, or specific scenarios, leaving the agent without clear usage instructions.
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 'fetches and analyzes' implies a read-only operation, it doesn't clarify data freshness, rate limits, authentication requirements, or what 'analyzes' entails (e.g., returns processed statistics vs raw 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 a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by separating fetching from analysis aspects. Every word earns its place, making it appropriately 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 no annotations, no output schema, and a tool that performs analysis (implying processed output), the description is incomplete. It doesn't explain what the analysis includes, the return format, or error conditions. For a tool with 'analyzes' in its purpose and lacking structured output documentation, this leaves too many unknowns 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 clear documentation for both parameters (poolId and days). The description adds no additional parameter semantics beyond what's in the schema, such as example pool IDs or analysis specifics. With high schema coverage, the baseline 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 action ('fetches and analyzes historical yield data') and the resource ('for a specific pool from DefiLlama'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'getYieldTool' (which likely fetches current yield data) or 'compareYieldHistoryTool' (which likely compares multiple pools), missing 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 no guidance on when to use this tool versus alternatives like 'getYieldTool' or 'compareYieldHistoryTool'. There's no mention of prerequisites, typical use cases, or exclusions, leaving the agent without contextual usage instructions.
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 analysis and comparison but lacks details on output format, data freshness, rate limits, authentication needs, or potential side effects. For a tool with 10 parameters and no output schema, 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 function without unnecessary words. It is appropriately sized and front-loaded, with every word contributing to understanding the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no output schema, no annotations), the description is insufficient. It lacks details on what the analysis returns, how results are structured, or any behavioral traits like error handling or data sources. For a tool that analyzes and compares yields, this leaves critical gaps for an AI agent.
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 each parameter well-documented in the schema itself. The description adds no additional parameter semantics beyond implying filtering across protocols, which is already covered by the schema. This meets the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('analyzes and compares') and resource ('yield opportunities from DefiLlama across all DeFi protocols'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'compareYieldTool' or 'getYieldHistoryTool', which appear related to yield analysis but with different scopes or methodologies.
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 such as 'compareYieldTool' or 'getYieldHistoryTool'. The description implies a broad analysis across all protocols but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context 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 for behavioral disclosure. It mentions the outcome ('earn interest') but lacks critical details: whether this is a write operation requiring authorization, gas costs, transaction finality, error conditions, or what happens on success/failure. For a financial transaction tool with 3 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 front-loaded with the core action and purpose, making it easy to parse. Every element ('Deposits tokens', 'into the Aave protocol', 'to supply liquidity and earn interest') 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 financial transaction tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context: what permissions are needed, gas implications, return values, error handling, or how it integrates with other Aave tools. The 100% schema coverage helps with parameters, but overall context for safe/effective use is lacking.
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 parameter-specific information beyond what's in the schema (chainId, asset address, amount format). It doesn't explain parameter relationships or provide examples, so it meets the baseline but doesn't add 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 ('Deposits tokens') and target ('into the Aave protocol'), with the purpose 'to supply liquidity and earn interest'. It distinguishes from sibling tools like 'depositWETH' or 'intentDepositAcross' by specifying Aave protocol, but doesn't explicitly differentiate from other Aave tools like 'intentAaveBorrow' or 'intentAaveWithdraw' beyond the verb 'deposits'.
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., token approval, sufficient balance), when to choose this over other deposit tools like 'depositWETH', or how it relates to sibling Aave tools (borrow, repay, withdraw). Usage is implied by the action but not explicitly 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, the description carries full burden. It states the tool performs a withdrawal (implying a write/mutation), but lacks details on permissions needed, gas costs, confirmation times, or error conditions. It mentions redeeming aTokens, which adds some context, but overall behavioral disclosure is minimal for a financial transaction tool.
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 and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no annotations and no output schema, the description is insufficient. It doesn't cover expected outputs, error cases, or important behavioral aspects like transaction finality or cost implications, leaving significant gaps for an AI agent.
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 no additional parameter semantics beyond implying the withdrawal involves aTokens, but this is already inferred from the tool's purpose. 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 ('Withdraws tokens') and target resource ('from Aave'), specifying it redeems supplied assets (aTokens). It distinguishes from siblings like 'intentWithdrawFromSlow' by naming Aave, but doesn't explicitly differentiate from other Aave tools like 'intentAaveDeposit' beyond the verb.
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 on when to use this tool versus alternatives is provided. While it mentions redeeming aTokens, it doesn't clarify prerequisites (e.g., must have supplied assets first) or compare to other withdrawal tools like 'intentWithdrawFromSlow' or 'withdrawWETH'.
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 this 'creates an intent' (implying a write operation that may require user confirmation or blockchain interaction), but doesn't clarify if this is a simulation, requires signing, has side effects, or what the output looks like. For a tool that likely modifies blockchain state, 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, direct sentence with zero wasted words. It front-loads the core purpose ('Creates an intent to approve token spending') efficiently, making it easy to parse and understand immediately.
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 that likely performs a blockchain write operation (token approval) with 4 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what an 'intent' entails, how it differs from immediate execution, what happens after creation, or potential errors. Given the complexity and lack of structured data, 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 all parameters are documented in the schema itself. The description doesn't add any additional context about parameter meanings, relationships, or examples beyond what the schema provides. This meets the baseline for high schema coverage but doesn't enhance 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 action ('Creates an intent to approve') and the resource ('token spending'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'intentApproveSlowTransfer' or 'getAllowance', but the core functionality is well-defined.
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 'intentApproveSlowTransfer' (for slow transfers) or 'getAllowance' (to check existing approvals). There's no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from context 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 only states the action without behavioral details. It doesn't disclose if this is a write operation (implied by 'approves'), permission requirements, side effects, rate limits, or response format. For a tool that likely modifies state, this lack of transparency 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 with no wasted words. It's front-loaded with the core action, though it could be slightly more structured by including key constraints or outcomes.
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 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., what approval entails, success/failure responses), usage prerequisites, and doesn't compensate for the absence of structured metadata, making it inadequate for safe 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 documented in the schema. The description adds no additional parameter context beyond implying 'transferId' relates to a transfer in SLOW contract. Since the schema does the heavy lifting, baseline 3 is appropriate with minimal value added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('approves a transfer') and resource ('in SLOW contract'), with 'Guardian' specifying the actor role. It distinguishes from siblings like 'intentReverseSlowTransfer' or 'intentSetSlowGuardian' by focusing on approval, but doesn't explicitly differentiate from 'getSlowTransferApprovalRequired' or 'getCanReverseSlowTransfer' which are read-only checks.
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. It doesn't mention prerequisites (e.g., needing guardian status), conditions for approval, or when to choose this over other intent tools like 'intentReverseSlowTransfer'. The description assumes context without explicit usage instructions.
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 'Airdrop' implies a write operation that transfers tokens, the description doesn't mention critical aspects like required permissions, whether this is irreversible, gas costs, rate limits, or what happens on failure. This leaves significant gaps for a mutation tool.
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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., side effects, error handling), parameter guidance, and output expectations. Given the complexity and lack of structured support, the description should provide more comprehensive information to be effective.
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 60% (3 out of 5 parameters have descriptions: recipients, amounts, totalSum), while chainId and coinId lack descriptions. The description doesn't add any parameter semantics beyond what the schema provides—it doesn't explain what chainId or coinId represent, acceptable values, or relationships between arrays. With moderate schema coverage, the baseline 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 ('Airdrop') and resource ('Coinchan token') with scope ('to multiple addresses'), providing a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'intentTransfer' or 'intentCoinchanMake', which might have overlapping functionality, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'intentTransfer' (for single transfers) and 'intentCoinchanMake' (for creating tokens), there's no indication of when this batch airdrop tool is preferred or what prerequisites might be needed.
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 implies a write operation ('Claim') but doesn't specify permissions required, transaction costs, side effects (e.g., token transfer), or error conditions. This is inadequate for a mutation tool with zero 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 appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't explain what happens after claiming (e.g., token receipt, transaction confirmation) or address potential complexities like network-specific requirements.
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 50% (only 'coinId' has a description). The description adds no additional parameter information beyond the schema, failing to compensate for the undocumented 'chainId' parameter. Baseline is 3 since the schema partially documents 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 action ('Claim') and the resource ('vested liquidity for a locked Coinchan token'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'coinchanGetVestableAmount' or 'intentCoinchanMakeLocked', 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 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 lacks context about prerequisites (e.g., needing vested liquidity available) or exclusions, 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 full burden for behavioral disclosure. It states this creates a token with locked liquidity and vesting options, implying a write operation that likely involves blockchain transactions and value transfers. However, it doesn't mention critical behaviors like gas costs, transaction finality, permission requirements, error conditions, or what happens upon success/failure. For an 11-parameter mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place: 'Create' (action), 'new Coinchan token' (resource), 'with locked liquidity' (key feature), 'and optional vesting schedule' (additional feature). No wasted words or redundant 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?
This is a complex mutation tool with 11 required parameters, no annotations, and no output schema. The description is too minimal given this complexity—it doesn't explain what the tool returns, error conditions, gas implications, or security considerations. While the schema covers parameter definitions well, the description fails to provide the broader context needed 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 82% (high), so most parameters are documented in the schema itself. The description mentions 'locked liquidity' (implied by unlockPeriod) and 'optional vesting schedule' (implied by vesting parameter), adding some context beyond the schema. However, it doesn't explain relationships between parameters (e.g., how poolSupply and creatorSupply interact) or provide usage examples, so it meets but doesn't exceed the baseline.
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 ('Create a new Coinchan token') and specifies key characteristics ('with locked liquidity and optional vesting schedule'), which distinguishes it from generic token creation tools. However, it doesn't explicitly differentiate from sibling tools like 'intentCoinchanMake' or 'intentCoinchanMakeHold', which appear to be related Coinchan token creation 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 like 'intentCoinchanMake' or 'intentCoinchanMakeHold'. It mentions 'locked liquidity and optional vesting schedule' which hints at use cases, but offers no explicit when/when-not instructions or prerequisites for invocation.
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 indicates a creation operation but lacks details on permissions required, gas costs, transaction finality, error conditions, or whether this is a simulated or on-chain action. For a tool that likely involves blockchain writes, 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 action and key parameters without any fluff or redundancy. Every word contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool that creates tokens on a blockchain (implied by parameters like chainId and ERC6909), with no annotations and no output schema, the description is incomplete. It misses critical context such as return values, error handling, gas implications, and how it differs from similar sibling tools, leaving significant gaps for an AI agent.
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 lists the parameters (name, symbol, metadata URI, owner, initial supply) and mentions 'chainId' implicitly via 'deploy on'. Since schema description coverage is 100%, the schema already documents each parameter well, so the description adds minimal value beyond restating what's in the schema, meeting the baseline.
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 ('Creates') and resource ('new ERC6909 token inside the Coins contract') with specific attributes (name, symbol, metadata URI, owner, initial supply). However, it doesn't explicitly differentiate from sibling tools like 'intentCoinchanMake' or 'intentMintPosition' that might also create tokens or positions, 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, such as other token creation tools in the sibling list (e.g., 'intentCoinchanMake'), nor does it mention prerequisites like network selection or permissions. It's a basic statement of function without 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 full burden for behavioral disclosure. While 'deposits tokens' implies a write operation, it doesn't disclose critical behavioral traits like required permissions, transaction costs, confirmation times, whether the operation is reversible, or what happens on failure. The description lacks essential context for a financial transaction tool.
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 states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deposit initiation, what the tool returns, error conditions, or the broader cross-chain transfer process. The context signals show this is a complex operation with 6 required parameters, yet the description provides minimal operational 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 six parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deposits tokens') and the resource ('Across Protocol bridge') with the purpose of initiating a cross-chain transfer. It distinguishes from siblings like 'intentDepositToSlow' by specifying the Across Protocol, but doesn't explicitly contrast with other deposit-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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or compare it to other bridging tools in the sibling list like 'intentDepositToSlow' or 'swap'.
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 a 'timelock' which implies funds are locked for a delay period, but doesn't disclose critical behaviors like whether this is a write operation (likely yes), if it requires specific permissions, gas costs, or what happens on failure. For a financial transaction tool, this is a significant gap in safety and operational details.
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 and key constraint ('with a timelock'). There is zero waste, 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 a financial deposit tool with timelock, no annotations, and no output schema, the description is inadequate. It lacks details on behavioral traits (e.g., mutability, error handling), expected outputs, or integration context, leaving the agent under-informed 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 all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the timelock implications or token address format. 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 action ('Deposit tokens or ETH') and target ('into SLOW contract with a timelock'), providing specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like 'intentDepositAcross' or 'depositWETH', which might also involve deposits but to different protocols or without timelocks.
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 approval for token deposits, or compare it to other deposit-related tools in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Create' implies a write/mutation operation but lacks details on permissions required, whether the proposal is immediately active, any confirmation steps, or potential side effects. This is a significant gap for a governance tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a governance proposal (a write operation with potential side effects), no annotations, and no output schema, the description is incomplete. It should explain more about the proposal lifecycle, expected outcomes, or error conditions to adequately guide an AI agent.
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 ('content' and 'chainId'). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new governance proposal for NANIDAO'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'intentVoteNaniProposal' or 'getNaniProposals', which are related to NANIDAO proposals but serve different functions.
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 specific permissions or tokens), nor does it clarify its role among sibling tools like 'intentVoteNaniProposal' or 'getNaniProposals'.
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 of behavioral disclosure. While 'Reverse a pending transfer' implies a write/mutation operation, the description doesn't disclose critical behavioral aspects: whether this requires specific permissions, what happens to the reversed transfer, whether the action is reversible, potential side effects, or error conditions. For a mutation tool with zero 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 with zero wasted words. It's appropriately sized for a tool with only two parameters 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 mutation tool ('Reverse') with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after reversal, what the tool returns, error conditions, or how this differs from related SLOW contract tools. Given the complexity implied by 'SLOW contract' operations and the lack of structured behavioral information, the description should provide more complete 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%, with both parameters (chainId, transferId) clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. With complete schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting for 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 ('Reverse') and target resource ('a pending transfer in SLOW contract'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'canUnlockSlow', 'intentUnlockSlow', or 'getCanReverseSlowTransfer', which appear related to similar SLOW contract operations.
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 SLOW contracts (canUnlockSlow, intentUnlockSlow, getCanReverseSlowTransfer, intentApproveSlowTransfer, etc.), there's no indication of prerequisites, constraints, or appropriate contexts for choosing this specific reversal tool.
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 context. It mentions setting/removing a guardian but doesn't disclose permissions needed, whether this is a write operation, potential side effects, or response format. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after execution, error conditions, or behavioral traits. Given the complexity of blockchain operations and lack of structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 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 ('Set a guardian') and target ('for a user in the SLOW contract'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'getSlowGuardianInfo' or 'intentUnlockSlow', 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 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 lacks context about prerequisites, when this operation is appropriate, or how it relates to other SLOW-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the outcome ('receive xNANI tokens') but lacks critical details such as permission requirements, transaction costs, rate limits, irreversible effects, or response format. For a financial transaction tool with zero 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 action and outcome with zero wasted words. It is 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 tool's complexity (a financial transaction with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like safety, costs, or response format, leaving gaps that could hinder an AI agent's correct 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 schema already documents both parameters ('amount' and 'chainId') adequately. The description does not add any meaning beyond what the schema provides (e.g., units for 'amount', specific chain IDs for 'chainId'), resulting in a baseline score of 3.
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 ('Stake NANI tokens') and outcome ('receive xNANI tokens, which can be used for governance'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'intentUnstakeNani' or other staking-related tools, 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 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 (e.g., 'intentUnstakeNani' or other staking/intent tools), nor does it mention prerequisites, exclusions, or context for usage. It merely states what the tool does without operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states 'creates an intent,' implying a preparatory or non-immediate action, but doesn't clarify what an 'intent' entails—such as whether it's reversible, requires confirmation, has side effects, or interacts with permissions. 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 with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly, which is ideal for conciseness in tool definitions.
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 creating a token transfer intent with no annotations or output schema, the description is insufficient. It lacks details on what the intent does (e.g., is it submitted to a blockchain, stored locally?), expected outcomes, error conditions, or how it differs from other transfer tools. This makes it incomplete for safe and effective use by an agent.
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 all parameters (token, amount, to, chainId). The description adds no additional meaning beyond this, as it doesn't explain parameter relationships or usage nuances. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles 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 ('creates an intent') and the resource ('to transfer tokens'), which is specific and unambiguous. However, it doesn't differentiate this tool from sibling tools like 'intentTransferFrom' or 'intentTransferPosition', which also involve transfer intents but with different mechanisms 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. With many sibling tools like 'intentTransferFrom' and 'swap' that might handle similar token transfers, there's no indication of prerequisites, use cases, or exclusions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Creates an intent,' implying a preparatory or non-immediate action, but fails to detail critical aspects like whether this requires authentication, has side effects, involves rate limits, or what the output entails (e.g., a transaction hash or intent ID). 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 wastes no space, making it easy to parse quickly while conveying the essential action.
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 token transfer tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., mutability, error handling), output expectations, and differentiation from siblings. For a tool that likely involves blockchain interactions, more context is needed to ensure safe and correct usage by an AI agent.
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 all parameters (token, amount, from, to, chainId). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, a baseline score of 3 is appropriate, indicating adequate but not enhanced 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 action ('Creates an intent to transfer tokens') and specifies the resource ('from another address'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'intentTransfer' or 'intentTransferPosition', which might handle similar token transfers but with different contexts or parameters, leaving room for 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?
The description provides no guidance on when to use this tool versus alternatives, such as 'intentTransfer' or other intent-related tools in the sibling list. It lacks context about prerequisites, scenarios, or exclusions, leaving the agent to infer usage based solely on the tool name and 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an unlock operation (implying a write/mutation), but doesn't specify permissions required, whether it's reversible, gas costs, confirmation requirements, or what happens upon success/failure. For a blockchain transaction tool, 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 with zero wasted words. It's front-loaded with the core action and resource, making it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a blockchain transaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'unlock' entails operationally, what the expected outcome is, error conditions, or how this interacts with the SLOW contract system. The context demands more 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 fully documents both parameters (chainId and transferId). The description doesn't add any additional semantic context about these parameters beyond what's in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unlock') and the resource ('a time-locked transfer in SLOW contract'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'canUnlockSlow' or 'intentReverseSlowTransfer', 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 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 'canUnlockSlow' (which likely checks unlockability) or 'intentReverseSlowTransfer'. There's no mention of prerequisites, conditions, or exclusions for using this unlock function.
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 'Unstake' which implies a write operation, but fails to detail critical aspects like permission requirements, transaction costs, reversibility, or potential side effects (e.g., lock-up periods). 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, direct sentence with no wasted words, effectively front-loading the core action and resource. It is 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 tool involves a write operation (unstaking) with no annotations and no output schema, the description is insufficient. It lacks details on return values, error conditions, or operational context, which are crucial for an agent to invoke this tool correctly in a financial or blockchain environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('amount' and 'chainId'). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints, so it meets the baseline for adequate but not enhanced 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 action ('Unstake') and the resource ('xNANI tokens back to NANI tokens'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'intentStakeNani' or 'intentCoinchanClaimVested', which might involve similar token operations, 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 staking or token conversion tools in the sibling list. It lacks context about prerequisites, timing, or exclusions, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Vote on') but doesn't cover critical aspects like whether this is a write operation requiring authentication, potential gas costs, irreversible effects, or rate limits. This leaves significant gaps for a governance voting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core action.
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 governance voting tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits (authentication needs, mutability), expected outcomes, error conditions, and how it fits within the broader governance workflow alongside sibling tools.
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 three parameters clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, meeting 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Vote on') and target ('an existing NANIDAO governance proposal'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'intentProposeNani' (which creates proposals) or 'getNaniProposals' (which retrieves them), missing 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing proposal from 'getNaniProposals'), exclusions, or comparisons to other voting or governance tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a read-only or mutative operation, permission requirements, transaction costs, side effects, or error conditions, leaving significant gaps for a tool that likely involves blockchain transactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context, usage guidance, and details on what happens after withdrawal (e.g., transaction confirmation, error handling). This is inadequate given the complexity and 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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying withdrawal of tokens, which is already clear from the tool name and schema. Baseline score of 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 ('Withdraw') and target ('unlocked tokens from SLOW contract'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'intentUnlockSlow' or 'intentReverseSlowTransfer', which may handle related SLOW contract operations.
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 (e.g., tokens must be unlocked), exclusions, or refer to sibling tools for related actions like unlocking or checking status.
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 lookup action but doesn't mention potential outcomes (e.g., returns null if no ENS name exists), error conditions, rate limits, or authentication needs. For a tool with no 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, direct sentence with no wasted words. It's front-loaded with the core action and efficiently communicates the tool's purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a string or null), error handling, or how it differs from similar tools like 'resolveENS'. For a lookup tool in a complex ecosystem, more context is needed to ensure correct 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 the 'address' parameter fully documented in the schema itself. The description doesn't add any extra semantic context beyond what the schema provides, such as examples or edge cases. This meets the baseline for high schema coverage but doesn't enhance 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: 'Looks up the ENS name for an Ethereum address.' It specifies the verb ('looks up'), resource ('ENS name'), and target ('Ethereum address'). However, it doesn't differentiate from sibling tools like 'resolveENS' or 'getName', 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. With sibling tools such as 'resolveENS' and 'getName' present, there's no indication of differences in scope, input/output, or use cases. This lack of comparative context leaves the agent without clear 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic function but omits critical details: whether this is a read-only operation, potential rate limits, network dependencies, error handling, or what happens with invalid ENS names. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely interacts with blockchain data. It doesn't explain return values, error formats, or behavioral constraints, leaving significant gaps for an AI agent to understand how to properly invoke and interpret results from this 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 schema description coverage is 100%, with the single parameter 'name' clearly documented in the schema. The description adds no additional parameter context beyond what the schema already provides, so it meets the baseline for high schema coverage without adding 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 ('Resolves') and target resource ('an ENS name to an Ethereum address'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'lookupENS', which appears to serve a similar function, 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 like 'lookupENS' or other address resolution methods. There's no mention of prerequisites, error conditions, or typical use cases, leaving the agent with minimal context for decision-making.
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 context. It states what happens (WETH converted to ETH) but doesn't mention permissions needed, gas costs, whether this is a transaction or simulation, confirmation requirements, or potential side effects. For a financial operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a tool with two well-documented parameters 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 financial transaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after withdrawal (where ETH goes), confirmation requirements, error conditions, or return values. The context demands more complete operational guidance than provided.
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 ('chainId' and 'amount') well-documented in the schema. The description adds no additional parameter context beyond what's already in the structured schema, so it meets but doesn't exceed the baseline expectation.
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 ('withdraw') and resource ('WETH back to native ETH'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'depositWETH' or other withdrawal-related tools, though the conversion aspect (WETH→ETH) 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. With siblings like 'depositWETH' and various 'intentWithdraw' tools present, there's no indication of when this specific WETH withdrawal tool is appropriate versus other withdrawal mechanisms.
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 the analysis involves 'historical yield performance' and specific metrics, it does not describe key behavioral traits such as whether this is a read-only operation, potential rate limits, data freshness, or the format of the output (e.g., structured comparison, charts). For a tool with no 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, well-structured sentence that efficiently conveys the tool's purpose and scope without unnecessary words. It is front-loaded with the core action ('Compares historical yield performance') and includes key details ('across multiple pools, analyzing metrics like APY, volatility, and TVL trends'), making it highly 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 tool's complexity (historical analysis with multiple metrics), lack of annotations, and no output schema, the description is moderately complete. It outlines what the tool does but falls short in explaining behavioral aspects, output format, or integration with sibling tools. While it covers the basic purpose, it does not provide enough context for an agent to fully understand the tool's operation and limitations in this environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for each parameter (poolIds, days, sortBy). The description adds minimal value beyond the schema by implying the tool uses these parameters for comparison, but it does not provide additional context like how the metrics are calculated or what 'volatility' and 'stability' entail. Given the high schema coverage, the baseline score of 3 is appropriate, as the description does not 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: 'Compares historical yield performance across multiple pools, analyzing metrics like APY, volatility, and TVL trends.' It specifies the verb ('compares'), resource ('historical yield performance across multiple pools'), and scope ('analyzing metrics like APY, volatility, and TVL trends'), which is specific and informative. However, it does not explicitly differentiate from its sibling 'compareYieldTool' or other analysis tools, preventing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing pool IDs from other tools, or when to choose it over similar tools like 'compareYieldTool' or 'getYieldHistoryTool' in the sibling list. This lack of contextual direction leaves the agent without clear usage instructions.
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 'fetches' data, implying a read-only operation, but doesn't mention potential side effects, rate limits, authentication needs, error handling, or response format. 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, well-structured sentence that efficiently conveys the tool's purpose and key data points without unnecessary words. It's front-loaded and every part earns its place.
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 minimally adequate for a read operation but lacks details on behavioral traits, error cases, and return values. It covers the basic purpose but doesn't fully compensate for the missing structured data, making it suitable for a baseline score.
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 ('asset' as token contract address, 'chainId' as chain ID). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 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 ('fetches') and resource ('reserve data for a given asset from Aave'), with specific details about what data is included (liquidity, debt, interest rates). However, it doesn't explicitly differentiate from sibling tools like 'getAaveUserData' or other data-fetching tools in the list, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'getAaveUserData' for user-specific data or other Aave-related tools, nor does it specify prerequisites or exclusions for 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?
No annotations are provided, so the description carries full burden. It implies a read-only fetch operation but doesn't disclose behavioral aspects like rate limits, authentication needs, error conditions, or response format. For a financial data tool with zero annotation coverage, this leaves significant gaps in understanding how it 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 purpose and lists key data points without waste. Every word contributes to understanding what the tool retrieves, making it appropriately sized 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 2 parameters with full schema coverage, no output schema, and no annotations, the description is minimally adequate. It clearly states what data is fetched but lacks details on behavioral traits and usage context. For a tool in a crowded sibling set, it should do more to guide selection and set expectations.
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 ('userAddress' and 'chainId') well-documented in the schema. The description adds no additional parameter semantics beyond implying these are needed to fetch user data. 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 'fetches' and the resource 'Aave user data', listing specific financial metrics like collateral, debt, borrowing power, and health factor. However, it doesn't explicitly differentiate from sibling tools like 'getAaveReserveData' or 'getAccountPortfolio', which might overlap in domain.
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 'getAaveReserveData' (for reserve-level data) and 'getAccountPortfolio' (possibly broader portfolio info), there's no indication of context, prerequisites, or exclusions for selecting this specific user-data tool.
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. While 'Gets' implies a read-only operation, it doesn't specify whether this requires network calls, has rate limits, returns cached data, or handles errors. For a tool with zero annotation coverage, this is insufficient 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 communicates the core purpose without any wasted words. It's appropriately sized for a simple lookup 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.
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 good schema coverage but no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks important context about behavior, alternatives, and return format that would be helpful for an AI agent.
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 ('token' and 'chainId') well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, so it meets the baseline expectation but doesn't enhance 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 action ('Gets') and resource ('number of decimals of an ERC20 token'), making the purpose immediately understandable. However, it doesn't differentiate from potential siblings like 'getTokenMetadata' or 'getTokenInfo' that might also provide decimal information, 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. With many sibling tools like 'getTokenMetadata' that might include decimals, there's no indication whether this is the preferred method for obtaining decimal information or when other tools might be 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'fetches' data, implying a read-only operation, but doesn't mention potential rate limits, authentication requirements, error conditions, or what 'details' includes. This leaves significant behavioral gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't specify what 'details' includes (e.g., block hash, timestamp, transactions), return format, or any behavioral constraints. For a data-fetching tool with no structured support, this leaves too much undefined.
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. A baseline of 4 is applied since it avoids redundancy while the schema fully handles 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 action ('fetches') and resource ('latest Bitcoin block details'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'getBlock' or 'getBlockInfo' 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. With many sibling tools related to blockchain data (e.g., 'getBlock', 'getBlockInfo'), there's no indication of when this specific tool is preferred or what distinguishes it, 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 full burden but only states the basic operation. It doesn't disclose whether this is a read-only operation (implied by 'Gets' but not explicit), potential rate limits, authentication requirements, error responses, or what metadata fields are returned. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes the two primary parameters. Every word earns its place without being overly terse.
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 well-documented parameters and no output schema, the description is minimally adequate. However, it doesn't explain what 'metadata' includes (attributes, image URL, etc.) or provide context about the NFT ecosystem. With no annotations and no output schema, the agent has incomplete information about what the tool actually returns.
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 mentions contractAddress and tokenId but omits chainId, adding minimal value beyond what the schema already provides. The baseline of 3 is appropriate since the schema does the heavy lifting, though the description could have better explained the relationship between 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 action ('Gets metadata') and target resource ('for an NFT token'), specifying it's by contract address and token ID. It distinguishes from similar tools like getTokenMetadata or getAddressNFTs by focusing on individual NFT metadata rather than token-level metadata or address-level NFT collections. However, it doesn't explicitly mention the chain ID parameter which is also required.
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 getTokenMetadata (for fungible tokens) or getAddressNFTs (for all NFTs at an address). It doesn't mention prerequisites, error conditions, or typical use cases. The agent must infer usage from the parameter 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?
No annotations are provided, so the description carries full burden. It states a read operation ('Gets') but doesn't disclose behavioral traits such as rate limits, error conditions, data freshness, or response format. For a 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 with zero waste. It front-loads the purpose and lists specific metadata attributes, 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, no output schema, and 100% schema coverage, the description is minimally adequate. It covers what the tool does but lacks details on behavior, output, or usage context, leaving room for improvement 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?
Schema description coverage is 100%, so the schema fully documents both parameters (token address and chain ID). The description adds no additional parameter semantics beyond what the schema provides, 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.
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 ('all metadata of an ERC20 token') with specific attributes listed (name, symbol, decimals, totalSupply). It distinguishes from siblings like getTokenInfo or getTokenChart by focusing on core metadata, though not explicitly contrasting 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 on when to use this tool versus alternatives like getTokenInfo or getCoinTokenMetadata. The description implies usage for ERC20 token metadata retrieval but lacks explicit context, 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. While 'Gets' implies a read-only operation, it doesn't specify whether this requires network access, has rate limits, returns cached data, or what happens if the token address is invalid. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the tool's purpose without unnecessary words. It's front-loaded with the core functionality and doesn't waste space on redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving token supply data), no annotations, and no output schema, the description is minimally adequate. It identifies the resource but lacks details on behavior, error handling, or output format. The high schema coverage helps, but overall completeness is limited for a tool that likely interacts with blockchain networks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('token' and 'chainId') clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema (e.g., it doesn't explain ERC20 token format or chain ID conventions), so it 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 ('total supply of an ERC20 token'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'getBalance' or 'getBalanceOf', which also retrieve token-related information, 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 that might retrieve related token data (e.g., 'getBalance', 'getTokenInfo'), there's no indication of when this specific tool is appropriate or what distinguishes it from 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 must fully disclose behavioral traits. It mentions creating, minting, and adding liquidity, which implies a complex write operation, but fails to detail critical aspects like required permissions, gas costs, irreversible effects, or rate limits. The phrase 'via ZAMM' hints at a platform but doesn't explain integration specifics, leaving 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.
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 action ('Create a new Coinchan token'). It avoids redundancy and wastes no words, though it could be slightly more structured by separating key components like token creation and liquidity addition for clarity. Overall, it is appropriately concise 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 high complexity of creating a token with liquidity, lack of annotations, and no output schema, the description is insufficient. It omits essential details such as expected return values, error conditions, or post-execution states. Without this context, users cannot fully anticipate the tool's behavior or outcomes, making it 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?
The input schema has 100% description coverage, clearly documenting all 9 parameters. The description adds minimal value beyond this, as it does not elaborate on parameter interactions, dependencies, or usage examples. For instance, it doesn't explain how 'poolSupply' and 'ownerSupply' relate to total minting or the role of 'value' in liquidity provisioning. The baseline score of 3 reflects adequate schema documentation without descriptive enhancement.
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 action ('Create a new Coinchan token'), the resources involved ('mint supplies and add initial liquidity'), and the method ('via ZAMM'). It specifically distinguishes this from sibling tools like 'intentCoinchanMakeHold' and 'intentCoinchanMakeLocked' by focusing on token creation with liquidity, rather than holding or locking mechanisms.
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 specific permissions or native tokens for liquidity, nor does it differentiate from similar tools like 'intentCreateCoinToken' or 'intentCoinchanAirdrop' in the sibling list. This lack of context makes it unclear when this is the appropriate choice.
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 write operation ('Deposit') but doesn't disclose critical behavioral traits: whether it requires user approval (e.g., transaction signing), gas costs, irreversible nature, or typical response format. This is inadequate for a financial transaction tool.
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 action and outcome, making it easy to parse. Every word earns its place by defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., transaction requirements, error cases), doesn't explain the return value, and offers no usage context. This leaves significant gaps for an AI agent to invoke it correctly.
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 ('chainId', 'amount') well-documented in the schema. The description adds no additional parameter semantics beyond implying ETH is deposited and WETH is received, which is already clear from the tool name and description context. Baseline 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 action ('Deposit ETH'), the target ('into the WETH contract'), and the outcome ('receiving WETH in return'). It uses specific verbs and distinguishes this tool from sibling tools like 'withdrawWETH' by describing the opposite operation.
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 ETH balance), compare it to similar tools like 'swap' for token conversions, or specify use cases (e.g., wrapping ETH for DeFi protocols).
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 action ('Get') but doesn't explain what 'current' means (e.g., latest confirmed block), whether it's read-only, if it requires specific permissions, or how it handles errors. 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.
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, making it easy to scan and understand quickly, which is ideal for 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?
Given the tool's low complexity (one optional parameter, no output schema), the description is minimally adequate but incomplete. It lacks details on parameter usage, behavioral traits, and differentiation from siblings, which are needed for full contextual understanding in this server's crowded toolset.
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 one parameter ('chainId') with 0% description coverage, but the tool description doesn't mention parameters at all. Since there's only one optional parameter, the baseline is high, but the description fails to explain what 'chainId' is or when it's needed, missing an opportunity to add value beyond 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 'Get the current block number' clearly states the verb ('Get') and resource ('current block number'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getBlock' or 'getBlockInfo', which likely provide more detailed block information, 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 siblings like 'getBlock' (which might return full block data) and 'getBlockInfo' (potentially similar), there's no indication of this tool's specific context or exclusions, leaving usage ambiguous.
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 this is a read operation ('Returns'), but does not mention rate limits, error conditions, authentication needs, or what happens if the token ID is invalid. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose without any redundant information. It is front-loaded with the core action and resource, making it 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 has no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is insufficient. It does not explain return values, error handling, or behavioral constraints, leaving the agent with inadequate information to use the tool effectively in a complex environment with many sibling tools.
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 50% (only 'tokenId' has a description). The description adds no additional parameter semantics beyond what's in the schema—it does not explain 'chainId' or provide context for 'tokenId' beyond the schema's 'stringified bigint (usually an address)'. With partial schema coverage, the description does not compensate for the undocumented 'chainId' parameter.
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 ('Returns'), the resource ('name, symbol, and URI of a given ERC6909 token ID'), and the source ('from the Coins contract'). It distinguishes itself from siblings like 'getTokenMetadata' by specifying the exact contract type (ERC6909) and source (Coins 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 like 'getTokenMetadata' or 'getCoin'. It does not mention prerequisites, exclusions, or specific contexts where this tool is preferred over others in the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'retrieves' data, implying a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, error handling, or the format of the returned value (e.g., numeric score, timestamp, classification). For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 fluff or redundant information. It is front-loaded with the key action and resource, making it easy to parse quickly. Every word earns its place, and there's no wasted verbiage.
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, 100% schema coverage, and no output schema, the description is minimally adequate. It specifies what data is fetched but lacks details on return format, error conditions, or usage context. For a simple read-only tool, this might suffice, but without annotations or output schema, the agent has incomplete information about what to expect from the response.
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, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate as the description accurately reflects the lack of inputs, though it doesn't explicitly state 'no parameters required,' which would warrant a 5.
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 ('Retrieves') and the specific resource ('current Fear and Greed Index value from Alternative.me API'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools, but given the unique nature of this index among mostly blockchain-related tools, differentiation is somewhat inherent. However, it doesn't explicitly contrast with similar data-fetching siblings like 'getCryptoPrice' or 'getStats', so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like 'getCryptoPrice' (which might fetch other market indicators) or 'getStats' (which could include broader statistics). The agent must infer usage based solely on the tool name and description without explicit 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 but is minimal. It mentions the default interest rate mode (variable, mode 2), which adds some behavioral context. However, it fails to disclose critical traits like permission requirements, potential risks (e.g., liquidation), rate limits, or what the response entails, leaving significant gaps for a mutation tool.
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 two sentences that directly state the purpose and a key default behavior. Every word earns its place, and it's front-loaded with the core action.
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 mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral implications (e.g., effects on collateral, error conditions), response format, or integration with sibling tools like 'getAaveUserData', making it 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 parameters. The description adds minimal value by clarifying the default for 'interestRateMode' (variable, mode 2), but doesn't provide additional semantics beyond what the schema already specifies for other 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 action ('Borrows tokens from Aave') and resource ('using your supplied collateral'), specifying the financial operation. It distinguishes from siblings like 'intentAaveDeposit' or 'intentAaveRepay' by focusing on borrowing, but doesn't explicitly contrast with them in the text.
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 'using your supplied collateral' and mentions the default interest rate mode, suggesting when this tool is appropriate. However, it lacks explicit guidance on when to choose this over alternatives like 'intentAaveWithdraw' or prerequisites such as having sufficient collateral.
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 fetching HTML and extracting main text 'as accurately as possible,' but lacks details on error handling (e.g., for invalid URLs or blocked sites), rate limits, authentication needs, or output format. This is a significant gap for a tool with no structured behavioral 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 two concise sentences with zero waste: the first states the core functionality, and the second adds a key limitation. It's front-loaded with the main purpose and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It misses critical details like error cases, performance limits, output structure, and how 'main text content' is defined. For a web scraping tool with potential complexities, 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?
The input schema has 1 parameter with 0% description coverage, and the description adds value by clarifying that the 'website' parameter is a URL to fetch content from. However, it doesn't specify URL format constraints (e.g., must include http://) or validation rules, so it partially compensates but not fully for the low 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: 'fetch the page's HTML and return the main text content' for a given URL. It specifies the verb (fetch), resource (web page content), and scope (most websites). However, it doesn't explicitly differentiate from potential siblings like 'checkMaliciousWebsite' or other web-related tools, keeping it at 4 rather than 5.
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 with 'Works for most websites,' suggesting it's not universal and may fail on some sites. However, it doesn't provide explicit when-to-use guidance, alternatives (e.g., vs. 'checkMaliciousWebsite'), or prerequisites like URL format requirements, leaving room for improvement.
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 of behavioral disclosure. It adds some context by mentioning 'proper approvals then router call,' hinting at a multi-step process and potential prerequisites (approvals), but lacks details on critical aspects like required permissions, rate limits, error handling, or what the output might look like. This is a moderate effort but leaves significant gaps for a tool with 9 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 extremely concise—a single sentence that efficiently conveys the core action and a key behavioral note ('proper approvals then router call'). It is front-loaded with the main purpose and wastes no words, 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 (9 parameters, no annotations, no output schema), the description is incomplete. It lacks essential context such as output format, error conditions, authentication requirements, and detailed behavioral traits. While concise, it doesn't provide enough information for an agent to fully understand how to use this tool effectively in a real-world scenario.
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 56%, indicating moderate documentation in the schema itself. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain the meaning of 'side' or 'slippageBps' in practical terms). Given the coverage level, the baseline is 3, as the description fails to compensate for the gaps in 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 verb ('swap') and resource ('ERC20 and ERC6909 tokens'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from potential sibling tools like 'getQuote' or 'intentTransfer' that might involve token operations, 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 'getQuote' for price estimation or 'intentTransfer' for simple transfers. It mentions 'proper approvals then router call' as part of the process, but this is more of a behavioral detail than usage context, failing to address when or why an agent should choose this tool 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?
With no annotations provided, the description carries full burden but only states it's a read operation ('Gets'). It doesn't disclose behavioral traits like whether it requires authentication, rate limits, error conditions, or what format the allowance is returned in (e.g., raw amount vs formatted). For a tool 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's front-loaded with the core purpose and uses precise terminology ('ERC20 token allowance'). Every word earns its place.
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 full schema coverage but no output schema or annotations, the description is minimally adequate. It states the purpose clearly but lacks behavioral context and usage guidance. Given the complexity of blockchain allowance queries, more completeness would be 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%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the relationship between owner and spender or chainId behavior. 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 ('Gets') and resource ('ERC20 token allowance between an owner and spender'), distinguishing it from siblings like getBalance, getTokenInfo, or intentApprove. It precisely identifies the exact blockchain concept being queried.
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 getTokenInfo or getBalanceOf, nor does it mention prerequisites such as needing valid Ethereum addresses. 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the default behavior when chainId is omitted (returns gas price for all supported chains), which is useful context. However, it doesn't disclose important behavioral traits like whether this is a read-only operation (implied but not stated), rate limits, authentication requirements, error conditions, or what the return format looks like (especially given the formatGwei 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 each earn their place. The first sentence states the core purpose, and the second explains the key behavioral nuance regarding the optional parameter. There is zero wasted language 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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and the chainId parameter's effect but leaves significant gaps: no information about the formatGwei parameter, no output format description, and minimal behavioral context. For a tool that returns potentially complex data (gas prices for multiple chains), more completeness would be 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 0%, so the description must compensate for undocumented parameters. It explains the chainId parameter's effect (when omitted vs. specified), which adds meaningful semantics beyond the bare schema. However, it doesn't mention the formatGwei parameter at all, leaving half of the parameters without semantic context. The description provides partial but incomplete parameter guidance.
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 ('current gas price'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'estimateGas' or 'getFeeHistory' by focusing specifically on current gas prices rather than estimates or historical data. However, it doesn't explicitly differentiate from all possible gas-related tools in the sibling list.
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 implied usage guidance by stating 'If chainId is not specified, will return gas price for all supported chains,' which helps understand when to use the optional parameter. However, it doesn't explicitly state when to use this tool versus alternatives like 'estimateGas' or 'getFeeHistory,' nor does it provide any exclusions or prerequisites for 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 for behavioral disclosure. While it mentions the default rate mode, it doesn't disclose critical behavioral traits like authentication requirements, whether this is a write operation (implied by 'Repays' but not explicit), potential transaction costs, rate limits, or what happens upon execution. For a financial transaction tool with zero annotation coverage, this represents 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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides important default behavior. There's zero waste or redundancy, and the information is front-loaded appropriately.
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 financial transaction tool with no annotations and no output schema, the description is incomplete. It doesn't address what happens after repayment (success/failure states), doesn't mention authentication or permission requirements, and provides minimal context about the operation's consequences. Given the tool's complexity and lack of structured metadata, the description should do more to guide safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value beyond the schema by mentioning the default for 'rateMode' (2 for variable), but doesn't provide additional context about parameter interactions, format specifics, or edge cases. This meets the baseline expectation 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 ('Repays your Aave debt') and resource ('Aave'), distinguishing it from sibling tools like 'intentAaveBorrow' or 'intentAaveWithdraw'. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 the default rate mode, but it doesn't explicitly state when to use this tool versus alternatives like 'intentAaveBorrow' or other debt management tools. It provides some operational guidance but lacks explicit when/when-not instructions or named alternatives.
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 returns a balance but does not describe error conditions, rate limits, authentication needs, or the format of the return value, which is critical for a read operation 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 a single, efficient sentence with zero wasted words. It front-loads the core functionality and avoids redundancy, 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?
For a tool with 3 parameters, no annotations, and no output schema, the description is minimally adequate but lacks details on behavioral traits like error handling or return format. It covers the basic purpose but does not fully address the complexity given the missing structured data.
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 description adds context by specifying the contract ('Coins contract') and token type ('ERC6909'), which clarifies the purpose of the parameters beyond the schema's descriptions. With 67% schema description coverage, it compensates well for the undocumented aspects, though it could detail parameter interactions more.
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 ('Returns the balance') and resource ('of a given address for a specific ERC6909 token ID from the Coins contract'), distinguishing it from similar sibling tools like getBalance, getBalanceOf, and getAddressCoinBalanceHistory by specifying the exact contract and token type.
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 does not mention prerequisites like network connectivity or compare it to sibling tools such as getBalance or getAddressTokenBalances, leaving the agent without contextual usage instructions.
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 it states what the tool does, it lacks behavioral details like whether this is a real-time or cached price, rate limits, error conditions, data source reliability, or what happens with invalid symbols. For a financial data tool with zero 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 communicates the core functionality without waste. It's appropriately sized for a simple 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description is minimally adequate. It states what the tool does but lacks important context about data freshness, sources, error handling, and how it differs from similar sibling tools. The absence of annotations and output schema means the description should do more to compensate.
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 schema has 100% description coverage for its single parameter, so the baseline is 3. The description adds value by specifying the output unit ('in USD'), which isn't in the schema. However, it doesn't provide additional context about parameter usage beyond what the schema already documents thoroughly.
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 ('Get'), resource ('current price of a cryptocurrency'), and unit ('in USD'). It distinguishes this tool from siblings like 'getBalance' or 'getTokenInfo' by focusing exclusively on price retrieval rather than balances, metadata, or other cryptocurrency 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 like 'getCoin', 'getTokenInfo', or 'getTokenChart' that might also provide price data, there's no indication of when this specific price-fetching tool is preferred or what distinguishes it from other data retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively communicates key traits: it's a non-destructive operation ('will not... change the database'), it doesn't fetch external data ('not obtain new information'), and it has a side effect ('append the thought to the log'). This covers the essential safety and behavioral profile for a logging/thinking tool.
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 efficiently structured in two sentences: the first explains what the tool does and its limitations, the second provides usage guidance. Every phrase adds value with no redundant or unnecessary information, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (single parameter, no output schema, no annotations), the description provides sufficient context: it explains the tool's purpose, behavioral constraints, and usage guidelines. The main gap is the lack of detail about the log format or where thoughts are appended, but for a basic thinking/logging tool, this is reasonably complete.
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 (the 'thought' parameter is clearly documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific details beyond what the schema already provides about the 'thought' parameter, maintaining the baseline score.
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 'think about something' and 'append the thought to the log', which clarifies its function as an internal reasoning/logging mechanism. However, it's somewhat vague about what 'think about something' entails operationally, and it doesn't explicitly differentiate from potential sibling tools (though none appear directly related).
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 it: 'when complex reasoning or some cache memory is needed.' It also explicitly states what it does NOT do ('will not obtain new information or change the database'), which helps distinguish it from data-fetching or mutation tools. However, it doesn't name specific alternative tools or provide explicit 'when-not-to-use' scenarios.
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:

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

Score Badge

Copy to your README.md:

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

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/NaniDAO/agentek'

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