Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden of behavioral disclosure. It reveals that the tool is a cross-chain status check and that it can handle hashes from either chain, but it does not disclose the return format, whether the operation is read-only (though implied), or how errors like 'hash not found' are handled. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose and followed by a clarifying note about the parameter. Every word earns its place—no fluff, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status check with one parameter, the description is mostly complete. It tells the agent what the tool does, what input it accepts, and how it differs from siblings. However, since there is no output schema, a brief note about the expected return values (e.g., status levels, pending confirmation) would improve completeness. The 'section 4.1' reference is cryptic and adds little.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with the txHash parameter already described as 'Transaction hash from source or destination chain.' The description adds marginal value by repeating this in natural language and referencing a section, but it does not go beyond the schema semantics. The baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states "Check cross-chain bridge transaction status" with a specific verb and resource. It distinguishes itself from sibling tools by specifying "cross-chain bridge" and noting that it accepts hashes from either side of the bridge, which sets it apart from single-chain status tools like vechainstats_get_transaction_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by stating that the tool accepts a hash from either the source or destination chain, which tells the agent when to use it (when a bridge transaction hash is available). However, it does not explicitly mention alternatives or exclusions, such as using vechainstats_get_transaction_status for on-chain transactions or xflows_check_status for a different bridge.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses the key behavioral trait: the tool returns transaction data for wallet signing, not actually executing the bridge. However, it omits details about fees, prerequisites, or side effects, which are relevant for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action and the return value. Every word contributes value; there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The absence of an output schema places importance on describing the return value, which it does at a high level ('transaction data ready for wallet signing'). However, for a complex tool with 8 parameters and no workflow context, it lacks depth about prerequisites or integration with other bridge steps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with all 8 parameters documented, so the baseline is 3. The description adds no extra parameter semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a cross-chain bridge transaction using WanBridge API and returns transaction data for wallet signing. This is a specific verb+resource and distinguishes it from sibling bridge tools like bridge_get_quota_and_fee or bridge_check_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear context (WanBridge API) but provides no explicit when-to-use guidance or alternatives. It does not differentiate from similar tools like xflows_build_transaction, leaving decision-making to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for behavioral disclosure. While 'get' implies a read-only operation, it does not state side effects, permissions, rate limits, or return format. The reference to 'section 1.2.3' is opaque and adds no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the core purpose. However, the trailing '(section 1.2.3)' is not actionable for an AI agent and slightly detracts from usefulness, preventing a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a basic sense of what is returned (quota and fees) but lacks details on the response structure or any contextual relationship to other bridge tools. Since there is no output schema, more explanation of the result would be beneficial. The complete schema coverage for parameters helps, but the overall context is still thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional semantics about parameters, merely restating that the tool returns quota and fees. It does not clarify the optional tokenPairID's role beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool retrieves bridge quota (min/max limits) and fees in a single call. It clearly distinguishes this from sibling tools like bridge_get_token_pairs or bridge_check_status, which serve different purposes, making the intent unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing token pairs first), nor does it indicate that this should be called before creating a bridge transaction. The 'in one call' hint implies efficiency but is not explicit advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of signaling side effects. 'Get current' implies a read-only, time-sensitive lookup, which is helpful, but it does not explicitly state safety, return format, or prerequisites. This is adequate but not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the key action and object, then adds context. Every word earns its place; there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless getter with no output schema, the description provides the essential information: what is returned (smgID) and why it is needed (cross-chain operations). It lacks explicit return type details and references an external section ('section 1.4') that may not be available to the agent, but the tool is low complexity and the description is otherwise sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description need not explain parameter syntax. It still adds meaning by naming the returned value (smgID) and its role in cross-chain operations, matching the baseline for parameterless tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and names an exact resource ('current Storeman Group ID (smgID)'), immediately clarifying what the tool returns. It also attaches a clear purpose ('for cross-chain operations'), which helps distinguish it from the many other bridge and vault tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for cross-chain operations' gives explicit context for when to use the tool. It does not mention when not to use it or name alternatives like bridge_get_quota_and_fee, so it falls short of a 5, but the usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It discloses the scale (300+ pairs, 25+ chains) but does not mention behaviors such as pagination, data freshness, filtering semantics, or whether the returned list is complete. For a read-only listing tool, this is minimal 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero wasted words. It immediately conveys the core function and a key data point, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (no required parameters, no nested objects, no output schema), and the description provides the essential purpose and scale. However, in the absence of any annotations or output schema, the description could offer more context about return values or typical use cases, though the minimal design keeps it adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers both parameters with descriptions ('Filter by destination chain type', 'Filter by source chain type'). The description adds no parameter-specific meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get all available cross-chain token pairs' with a specific verb and resource, and provides scale context ('300+ pairs across 25+ chains'). It is distinct from most sibling tools, though it does not explicitly differentiate from the closely named 'bridge_get_token_pairs_hash'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like bridge_get_token_pairs_hash or xflows_get_supported_tokens. The description simply states what it does without explaining typical usage scenarios or when filtering by fromChain/toChain would be appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries the burden of behavioral disclosure. It states what the tool returns (a hash) and its purpose, which is sufficient for a simple stateless operation. No hidden side effects or additional behavior is expected beyond computing a hash.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that is both concise and informative. It contains no filler or redundant details, earning a perfect score for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is nearly complete. It explains what the tool does and why it exists. The only minor omission is a specific format for the returned hash, but that is not critical for understanding or using the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty (zero parameters), so schema coverage is 100%. The description doesn't need to explain parameters, and the baseline for a zero-parameter tool is 4. It correctly avoids adding redundant parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get hash of token pairs data to check if it changed (for caching optimization)'. It specifies the resource (token pairs data), the action (get hash), and the purpose (change detection), which distinguishes it from the sibling tool bridge_get_token_pairs that likely returns the full data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions the intended use case: 'for caching optimization' and checking if data changed. While it doesn't name alternative tools or provide when-not-to-use guidance, the purpose is clear enough for an agent to infer when to call this tool versus fetching the full token pairs list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It implies a read-only check ('Check if') but does not disclose return format, error behavior for nonexistent tokens, or any edge cases. It is minimally transparent but lacks specific behavioral details that would help an agent anticipate outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that clearly states the tool's purpose without unnecessary words. It earns its place and is immediately understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but there is no output schema, so the description should clarify what the tool returns. 'Check if' implies a boolean, but it is not stated explicitly. The description covers the core purpose but omits return value details and edge-case behavior, leaving minor gaps for a low-complexity tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with 'Token ID to check transfer eligibility' already providing adequate meaning for the single parameter. The description's mention of 'StarGate NFT' adds slight context about the token type, but it does not go beyond what the schema already conveys, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Check') and names the resource ('StarGate NFT') along with the condition ('maturity period has ended'), making it clear what the tool does. It distinguishes itself from sibling tools like 'get_maturity_end_block' and 'is_under_maturity_period' by focusing on transfer eligibility rather than maturity timestamps or period status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when one needs to know if an NFT can be transferred, but it does not explicitly state when to use this tool versus alternatives like 'is_under_maturity_period' or 'get_maturity_end_block'. No exclusions or preferred contexts are given, leaving the agent to infer usage from the purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states 'Claim accumulated VTHO rewards for a StarGate NFT'. It does not disclose that this is likely an on-chain transaction requiring gas/signature, that it is irreversible, or what the response contains. The description carries the full burden and falls short for an action-oriented tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence with no redundant words. It is front-loaded with the verb 'Claim' and clearly states the object and target, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-changing claim operation with no annotations, no output schema, and minimal context, the description is incomplete. It omits crucial information such as what the tool returns (e.g., transaction hash), prerequisites like maturity or ownership, and potential side effects. This lack of context makes it harder for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the single parameter 'tokenId' as 'StarGate NFT token ID to claim rewards for'. The description adds no extra meaning beyond the schema, but since schema coverage is 100%, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Claim' and identifies the resource 'accumulated VTHO rewards' for a 'StarGate NFT'. This clearly communicates the tool's function, but it does not explicitly differentiate it from sibling tools like vechainstats_get_account_vtho_info or unstake_stargate_nft.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as NFT ownership, maturity period, or whether rewards must be accumulated, nor does it reference related tools like is_under_maturity_period or get_maturity_end_block.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. The verb 'Calculate' implies a pure off-chain computation without side effects, but it does not disclose the return format, rounding behavior, or that it is deterministic. The schema example for slippagePercent adds some context, but the description itself is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 10 words, fully front-loaded with the core purpose. Every word earns its place, with no redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter calculation tool with complete schema descriptions and no output schema, the description covers the essential purpose. However, it lacks explicit details about the calculation formula, return value type, and rounding behavior, which are relevant for a financial calculation. Still, given the tool's simplicity, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with clear descriptions for both parameters ('Expected output amount' and 'Slippage tolerance percentage (e.g., 0.5 for 0.5%)'). The description text does not add any additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Calculate' and a specific resource 'minimum output amount based on slippage tolerance'. This clearly distinguishes it from siblings like dex_get_swap_quote (which returns quotes) and dex_execute_swap (which executes trades).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no information about when to use this tool versus alternatives, such as after obtaining a quote or to compute the minimum acceptable output before executing a swap. No exclusions or alternative references are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'execute a token swap,' which implies a state-changing transaction, but does not disclose gas costs, wallet authentication, irreversibility, or the role of slippage parameters. This is insufficient 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no superfluous words. It is concise and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex financial transaction tool with no output schema and no annotations, yet the description is only one clause. It lacks essential context about the execution workflow, return values, and side effects, making it inadequate for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% description coverage for all six parameters, so the baseline is 3. The description text itself adds no parameter-specific meaning beyond what the schema already contains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Execute' and identifies the resource as 'a token swap on a VeChain DEX'. This clearly distinguishes the tool from sibling tools like dex_get_swap_quote, dex_calculate_slippage, and dex_get_trade_history, which are read-only or analysis operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as obtaining a quote first, wallet connection, or that this is an on-chain write operation unlike the read-only DEX query tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 'status' but doesn't specify status values, return format, or confirm the read-only nature of the call. This is minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence, front-loaded with the primary purpose, and contains no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description adequately states the core function. However, it doesn't elaborate on the return structure or what 'status' means, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers the optional dexName parameter with 100% coverage, so the description need not repeat it. The description adds no additional parameter context, fitting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as retrieving a list of available DEXes on VeChain, including their status. This specific verb and resource distinguish it from sibling DEX tools like dex_get_swap_quote and dex_execute_swap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for discovering available DEXes, but it provides no explicit guidance on when to use it versus other DEX-related tools. No alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries full responsibility for disclosing behavior. It only says 'Get', which implies a read-only operation, but does not describe what is returned (e.g., raw numbers, decimals), whether addresses or symbols are resolved, or potential failure modes. This is minimal context beyond the tool name itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states what the tool does. There is no fluff, and the structure front-loads the core action and resource. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity and the schema's complete parameter coverage, the description is almost sufficient. The only gap is the lack of return-format information, but for a simple read-only getter this is not critical. The description provides enough for an agent to select the tool correctly and understand its basic purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full descriptions for all three parameters with 100% coverage. The description adds the relation 'token pair' and 'DEX', but this is largely implied by the parameter names and schema. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get liquidity pool reserves for a token pair on a DEX'. It uses a specific verb ('Get') and names the exact resource ('liquidity pool reserves') along with the context ('token pair on a DEX'). This distinguishes it from sibling DEX tools like dex_get_swap_quote or dex_get_trade_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or edge cases. While the input schema defines parameters, it offers no contextual hint about when reserve data is needed (e.g., for slippage calculation) versus other DEX querying tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full behavioral transparency. It only states 'calculates expected output amount', which implies a read-only operation but does not explicitly confirm that the tool does not execute the swap, nor does it disclose any error conditions, fee handling, or whether the quote is simulated without on-chain effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and resource, and the parenthetical adds the key output meaning. Every word earns its place with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 required parameters and no output schema or annotations. The description explains the purpose and the primary return (expected output amount), but it does not detail the output structure, potential additional quote fields (e.g., price impact, route), or prerequisites. It is minimally adequate but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptive parameter definitions (e.g., 'Input token symbol or address', 'Amount to swap (decimal string)'). The tool description adds no additional parameter semantics beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and identifies the resource as 'a quote for token swap on a VeChain DEX', with a clarifying parenthetical 'calculates expected output amount'. It clearly distinguishes from sibling tools like dex_execute_swap (executes swaps) and dex_calculate_slippage (calculates slippage).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to obtain a quote before executing a swap, but it does not explicitly state when to use it versus alternatives (e.g., dex_execute_swap) or mention any exclusions. There is no 'use this instead of X' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden. It merely states the action and data source; it does not disclose any behavioral traits such as pagination, rate limits, response structure, or whether the data is real-time. For a getter, some context is expected but missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded, concise sentence that communicates the essential function and data source without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter getter, the description is minimally adequate. However, since there is no output schema, it could have benefited from a brief mention of the return format or the specific data fields returned, to fully inform the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides a complete description of the single parameter 'address' with a default. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Get') and resource ('DEX trading history for an address'), with the address scope specified. It is sufficiently distinct from most siblings, though it does not explicitly differentiate from the similar vechainstats_get_dex_trades.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given about when to use this tool versus alternatives like vechainstats_get_dex_trades or dex_get_swap_quote. The usage is only implied by the description: when you need DEX trade history for an address.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 implies a read-only operation by saying 'Get balance' but does not explicitly state that it is non-mutating, has no side effects, or requires no special permissions. For a simple read tool this is a minor gap, but the description adds no behavioral depth beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence that conveys the essential function with no unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, and the schema covers the parameters adequately. However, there is no output schema, and the description does not mention what the response format will be or that B3TR is also supported. The missing B3TR mention in the description is a notable gap for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (address and tokenSymbol) are already documented. The description adds no additional parameter context and even mentions only VET/VTHO while tokenSymbol supports B3TR, slightly conflicting with the schema without contradicting it outright.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets VET and VTHO balances for an address, with a specific verb and resource. However, it omits B3TR, which is listed as a valid tokenSymbol in the schema, so the description is slightly incomplete and could mislead about supported tokens.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like vechainstats_get_vip180_balance or vechainstats_get_account_vtho_info. The description gives no context on 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.

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 is a read-only operation by implication, but it does not disclose any specifics such as required network connection, potential latency, or what data fields are returned. No behavioral traits are revealed 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence, which is concise. However, it is under-specified: it omits essential detail about what 'information' is provided, making it less helpful than a concise but complete statement would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should clearly define what the tool returns. It does not mention the type of information, the response format, or any edge cases. A more complete description like 'Returns the chain ID, network name, and latest block number' would be far more suitable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the schema description coverage is vacuously 100%. The baseline for 0 parameters is 4, and the description does not need to explain parameter semantics. It adds nothing beyond the schema, but that is acceptable since there is nothing to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'Get information about the connected blockchain' but does not specify what information it returns (e.g., chain ID, network name, block height). The verb+resource pattern is present, but the purpose is too vague to distinguish it from many sibling tools that also retrieve blockchain-related information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclusions, leaving the agent without context on when this should be called.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only says 'Get all...' which implies a read-only operation, but doesn't state whether the result is an array, whether empty results are possible, or any error/edge-case behavior. There is no added context beyond the core purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the action and target. There is no wasted text or redundant repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter getter, the description is adequate but minimal. There is no output schema, so the return format (e.g., an array of token IDs) is only implicit. It also omits any mention of the StarGate contract or chain, leaving some ambiguity for an agent selecting this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter 'address' is described in the schema. The tool description adds no new meaning beyond 'owned by an address,' so it neither compensates nor hinders. The baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Get all StarGate NFT token IDs') and the target resource ('owned by an address'). It distinguishes itself from generic siblings like nft_get_owned_tokens by specifying the StarGate NFT collection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to prefer this tool over alternatives. It does not mention exclusions, prerequisites, or differences between this and similar ownership-checking tools such as nft_check_ownership or nft_get_owned_tokens.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the burden. It indicates a read operation via 'Get' and specifies the returned data (supply and cap), but does not explicitly state read-only safety, auth requirements, or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, clearly structured, no redundancy. It immediately names the action and data returned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter getter, the description is adequate: it names the level, the data returned, and the schema defines the parameter. However, without output schema or annotations, the agent lacks details on value units/format, but this is not critical for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a well-described levelId parameter (type, min, max). The description adds no additional meaning beyond naming 'specific StarGate level', so it stays at the schema-driven baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves circulating supply and cap for a specific StarGate level, using a specific verb ('Get') and resource. It distinguishes from sibling tools like get_token_supply by specifying 'StarGate' and 'level'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies usage for a given levelId, but does not mention similar tools or exclusions, leaving the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits on its own. It implies a read-only operation (getter) and specifies the NFT domain, but does not state potential outcomes such as errors for invalid token IDs, whether the result is a raw integer, or if any off-chain state is involved. It is adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core purpose. There is zero wasted wording, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter getter, the description covers the essential purpose and expected output ('block number'). It lacks an output schema but the return type is intrinsically clear. However, it could benefit from mentioning related checks like is_under_maturity_period to provide fuller context within the toolset.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the sole parameter (tokenId) with a clear description: 'Token ID to get maturity end block for'. Since schema coverage is 100%, the tool description does not need to repeat parameter details. It adds no extra semantic value beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get the block number when the maturity period ends for a StarGate NFT'. It specifies a precise verb (get), resource (block number), and scope (StarGate NFT), effectively distinguishing it from sibling tools like is_under_maturity_period or get_token_level.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention related tools like is_under_maturity_period or suggest scenarios where this block number is needed (e.g., to compare against the current block). Without any usage context, the agent must infer applicability solely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the behavioral burden, but it only says 'get detailed information.' It does not disclose whether the operation is read-only, whether it returns stake-specific data versus general NFT metadata, or what permissions are required. This leaves significant behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the verb and resource, containing no filler or redundant phrasing. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should clarify what 'detailed information' includes, especially given the tool's name implies stake-specific data. It fails to mention return fields, stake status, maturity, or level, and does not distinguish itself from generic NFT info tools, leaving notable gaps in context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the only parameter, tokenId, with 100% coverage. The description adds only the phrase 'by token ID,' which reinforces but does not extend schema semantics. Baseline 3 applies because the schema handles parameter meaning adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action ('get detailed information') and the resource ('specific StarGate NFT by token ID'), which distinguishes it from list-style siblings. However, it does not explicitly differentiate from generic NFT info tools like get_nft_info or get_nft_metadata, leaving some overlap ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when the user has a specific StarGate NFT token ID, which provides clear context. It does not mention exclusions or alternatives, such as when to prefer get_nft_info or get_user_stakes, so guidance is limited to implied usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. The word 'Get' implies a read-only operation and the description mentions the return content (requirements and rewards), but it does not disclose additional behavioral traits such as response structure, potential sorting, or any side effects. It is minimally adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that states the core function and key output details. There is no unnecessary repetition or filler, making it concise and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one optional parameter, no output schema, no annotations), but the description does not fully cover context like the meaning of categories, default behavior, or how the response is structured. It provides the essentials but leaves room for ambiguity regarding filters and output, so it is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the single parameter 'category' fully described in the schema. The description does not add any meaning beyond the schema, such as explaining the enum values or default behavior. Since the schema already documents the parameter, baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a clear resource ('StarGate staking levels') with additional detail about the content ('requirements and rewards'). This clearly distinguishes it from sibling tools like stake_vet or get_user_stakes, which concern individual staking actions or user-specific data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as get_stake_info or get_token_level. It does not state any prerequisites, use cases, or exclusions, so an agent may be unsure which tool to invoke for a given query about staking levels.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only states the basic read operation and does not disclose any behaviors such as error handling, return format, rate limits, or token availability. The description adds no context beyond what the tool name implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that immediately conveys the operation and input. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does not clarify what 'information' is returned, and it does not differentiate from similar token-info siblings. For a one-parameter read tool, it is adequate but leaves gaps in expected output and selection context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents tokenSymbol with examples. The description repeats the examples but adds no additional semantic meaning, so it is at baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get') and resource ('information about a token') with clear input scope ('by its symbol'), and gives examples. However, it does not distinguish from sibling tools like vechainstats_get_token_info or token_exists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description only states the function, leaving the agent to infer usage. No exclusions or alternative tool references are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for behavioral disclosure. The verb 'Get' implies a read-only operation, but there is no mention of error behavior (e.g., invalid token ID), return format, or potential null results. The description adds no context about what the level ID represents or whether the token must belong to a specific collection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundant information. It is front-loaded with the action and object, making it immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the simple one-parameter tool, the description is incomplete. There is no output schema, and the description does not explain what a level ID is, its format, or what the response will contain. For a successful agent invocation, this lack of return-value context is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for the single parameter, tokenId, with a description 'Token ID to get level for'. The tool description adds no additional semantic value beyond what the schema already states, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('level ID of a StarGate NFT'). It distinguishes itself from sibling tools like get_staking_levels (which lists levels) and get_level_supply (which queries supply for a level) by specifying it retrieves the level ID for a particular token.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., token ownership, existence check) or scenarios where other tools like get_staking_levels would be more appropriate. The name implies a token-level lookup, but explicit usage criteria are absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 says 'Get' but does not explicitly state it is read-only or disclose any limitations. The term 'stakes' in the tool name conflicts with 'all StarGate NFTs owned' in the description, creating ambiguity about whether it returns only staked NFTs or all owned NFTs. This lack of clarity undermines transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, directly front-loaded with the action and resource. It contains no wasted words and is easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should explain what 'detailed information' includes and clarify the relationship between 'stakes' and 'owned'. The ambiguity about scope (staked vs. all owned) makes the description incomplete for an agent to predict the tool's response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the single parameter 'address' with a description. The tool description adds valuable context that the stakes refer to StarGate NFTs, clarifying what the address parameter is for beyond the generic schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and the resource ('all StarGate NFTs owned by an address'), with an added qualifier ('with detailed information'). It distinguishes from generic NFT listing tools by specifically naming StarGate NFTs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: this tool is for fetching StarGate NFTs for a given address. However, it does not explicitly mention when to prefer this over alternatives like get_ids_owned_by or nft_get_owned_tokens, nor does it provide any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state the return format, error conditions, whether a wallet must be connected, or any side effects. It merely restates what the tool name implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short sentence with no wasted words, front-loaded with the verb and object. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter getter, the description is minimally adequate, but it lacks explicit mention of the return value and any prerequisites like requiring a connected wallet. With no annotations or output schema, a bit more context would improve completeness, though the tool's simplicity avoids severe gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing to explain. Baseline 4 applies as there are no parameter semantics to add. The description adds no parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' with a clear resource 'connected wallet address', which precisely states the tool's function. It distinguishes itself from sibling tools like get_balance or transfer_vet by focusing on the wallet address retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, such as needing a connected wallet, or situations where this tool would be preferred over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It only says 'Check', implying a read-only operation, but it does not specify return type, error behavior, side effects, or anything about the maturity period semantics. This is a minimal disclosure, similar to the update_drive example.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the purpose without any fluff. Every word is necessary. It is appropriately sized for a simple predicate tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., a boolean), how maturity period is determined, or what happens for invalid token IDs. The context of 'maturity period' is left undefined, which could be confusing without sibling tool context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for the single parameter (tokenId). The tool description adds no additional meaning beyond what the schema already provides ('Token ID to check if under maturity period'), so it lands at the baseline of 3. No new format, constraints, or nuances are introduced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Check') on a specific resource ('StarGate NFT') with a specific condition ('still under maturity period'). However, it does not distinguish itself from sibling tools like get_maturity_end_block or can_transfer_stargate_nft, so it loses a point for not differentiating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its usage (when you need to know maturity status), but it provides no explicit guidance on when to use this tool versus alternatives such as get_maturity_end_block or can_transfer_stargate_nft. There are no exclusions or alternative mentions, so it only meets the 'implied usage' bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 fails to mention that this is an on-chain state-changing operation that may require a wallet connection, gas fees, or that it updates the NFT's operator approval. The phrase 'approve' hints at permission but does not disclose side effects or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence of 10 words. It is immediately clear and contains no redundant or speculative content, earning full marks for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

As a mutation tool with no annotations and no output schema, the description should clarify the on-chain effect and likely return value (e.g., transaction hash). It also omits important context such as ownership requirements and the typical approval-before-transfer flow. The tool may be simple, but the description remains under-specified for safe agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%—each parameter (tokenId, operator, contractAddress) has a clear description. The tool description adds no new semantic information beyond referring to 'another address' and 'specific NFT,' which the schema already covers. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Approve'), identifies the resource (a specific NFT), and states the beneficiary (another address). This clearly distinguishes it from sibling tools like nft_transfer (which actually moves the NFT) and nft_mint (which creates one).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention typical workflow prerequisites (e.g., that approval is often a prerequisite for a transfer by another address). It simply states what it does without any contextual usage hints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. 'Burn (destroy)' communicates that the action is destructive and irreversible, but it does not mention ownership/approval requirements, on-chain transaction implications, gas fees, or confirmation behavior, leaving notable gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short, front-loaded sentence: 'Burn (destroy) an NFT token'. Every word is meaningful and there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple 2-parameter mutation with no output schema and full schema coverage for parameters, so the description only needs to convey the core action and any critical prerequisites. It conveys the core action ('burn/destroy') but omits ownership prerequisites and what happens after execution, making it minimally complete rather than thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% description coverage for both required parameters (tokenId and contractAddress). The description adds no parameter-level detail, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Burn' with parenthetical 'destroy' and clearly identifies the resource as 'an NFT token'. It distinguishes this tool from siblings like nft_transfer, nft_mint, and nft_approve by describing the destructive action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as token ownership or approval. The only implied usage comes from the tool's name and the verb 'Burn'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden of behavioral disclosure. 'Check who owns' clearly implies a read-only operation, and the schema identifies the required inputs. However, it does not disclose the exact return format (e.g., owner address), potential edge cases (e.g., burned tokens), or any side effects. This is minimal but not misleading, earning a 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short sentence that directly conveys the tool's purpose without any filler. It is appropriately sized for the tool's simplicity, front-loaded with the key verb 'Check', and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, with two well-described parameters and no output schema. The description is sufficient to understand what it does, but it lacks comparison with similar sibling tools and does not clarify what the response will contain. Given the abundance of NFT-related siblings, this minimal context is barely adequate, hence a 3.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage: 'tokenId' is described as 'Token ID' and 'contractAddress' as 'NFT contract address'. The description adds no extra semantics beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Check who owns a specific NFT token' – a specific verb ('check') plus resource ('ownership' of an NFT token). However, it does not explicitly distinguish itself from sibling tools like nft_get_owned_tokens or vechainstats_get_nft_holders, which could also provide ownership-related information, so it misses the full mark for sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention any unique use case, prerequisites, or exclusions. Given the large sibling list with similar NFT tools, the lack of usage context makes it hard for an agent to decide if this is the right tool for a given task.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the word 'Get' implies a read-only operation, the description does not mention potential pagination, rate limits, or the exact shape of the response. For a simple getter this is minimally acceptable, but it adds little 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the core function and the data source in under 10 words. Every word contributes value, with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is sufficient for an agent to understand what it returns: a list of all NFT collections. It does not explain what fields are returned, but for a zero-parameter read tool, this is not a critical gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing to explain. The description appropriately omits parameter details. Baseline is 4 for zero-parameter tools because schema coverage is effectively complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('all NFT collections') with a specific scope ('on VeChain'), making the purpose obvious. It also mentions the data source (VeChainStats API). However, it does not explicitly distinguish this from the similar sibling 'vechainstats_get_nft_list', so it loses a point for lack of sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description only says it uses the VeChainStats API, but does not state when to prefer this over other NFT-related tools like 'nft_get_collection_info' or 'vechainstats_get_nft_list'. No exclusions or alternative recommendations are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 simply restates the tool's name ('Get detailed information') and offers no information about side effects, safety (e.g., read-only nature), required permissions, error cases, or return format. This is essentially a tautology and provides zero transparency beyond what the name implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the action and resource. It has no wasted words. However, it is almost identical to the tool name, so while efficient, it doesn't add much value beyond the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an info-retrieval tool with no output schema and no annotations, the description is quite sparse. It does not specify what 'detailed information' includes (e.g., name, symbol, total supply, floor price), nor does it clarify the distinction from nft_get_metadata or vechainstats_get_nft_info. The description is minimally adequate for a simple get tool but lacks the depth needed for an agent to confidently choose it among many similar NFT tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage of the single parameter, collectionId, with a clear description ('NFT collection ID or contract address'). The description adds no additional meaning or context about the parameter. Given the high schema coverage, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get detailed information about an NFT collection' clearly states the action (get) and the resource (detailed information about an NFT collection). It distinguishes from sibling tools like nft_get_owned_tokens (tokens owned by a user), nft_get_metadata (metadata for a specific token), and vechainstats_get_nft_info (NFT-level info) by focusing on the collection-level scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios where this tool is preferred over nft_get_all_collections, nft_get_metadata, or vechainstats_get_nft_info, nor any exclusions. The agent is left to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description must carry the full burden of behavioral disclosure. It does not state that this is a read-only operation, nor does it mention rate limits, caching, possible errors, or any side effects. The only added context is the VeChainStats data source, which is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with a useful parenthetical source note. It is front-loaded with the key verb and resource, contains no filler, and every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool, the description is reasonably complete: it names the return scope (floor price and market data), the required identifier, and the data source. However, it could be stronger with a note on the output shape or usage constraints, especially since no output schema is provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents collectionId with type and description ('NFT collection ID or contract address'). The description adds no new meaning beyond reaffirming that the tool operates on an NFT collection, so it does not improve on the 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (get), the resource (floor price and market data for an NFT collection), and distinguishes it from siblings like nft_get_collection_info by focusing on pricing data. The verb 'Get' plus the specific resource makes the purpose immediately obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to choose this tool over alternatives such as nft_get_collection_info, nft_get_metadata, or vechainstats_get_nft_info. The only implied usage context comes from the tool name and the phrase 'NFT collection,' but no explicit when-to-use or when-not-to-use information is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses only the basic read operation ('Get metadata') but does not mention return format, potential errors, token ownership requirements, or any other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the core purpose with no unnecessary words. It is front-loaded and highly readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is low complexity with fully described parameters and no output schema. The description adequately states the basic action, but lacks any additional context such as chain-specific details or behavior when the token doesn't exist, making it merely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (both tokenId and contractAddress are described). The description adds no extra parameter semantics beyond the schema, which meets the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'metadata for a specific NFT token'. It is specific enough to distinguish from sibling tools like nft_get_collection_info or nft_get_floor_price, as it targets a single token's metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: when you need metadata for a single NFT token. However, it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or contextual hints beyond the basic purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. 'Get' implies a read-only operation, which is transparent, but it does not disclose potential pagination, response format, or error behavior. It adds some context (ownership filtering) but lacks richer behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is front-loaded and contains no filler. Every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool, the description is adequate but not complete. It does not mention the return type or any limitations, and there is no output schema to fill that gap. Given the low complexity, a score of 3 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both 'address' and 'collectionAddress'. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all NFTs owned by a specific address' uses a specific verb and resource, and clearly specifies the scope (owned by an address). This distinguishes it from sibling tools like nft_get_metadata or nft_get_transfer_history, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. While the purpose implies its use, there is no explicit direction for selecting it over similar tools like vechainstats_get_nft_list or get_ids_owned_by.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 an external dependency (VeChainStats) but omits important behavioral traits such as pagination behavior, return format, potential rate limits, or whether the history is restricted to a specific network. The verb 'get' implies a read-only operation, but richer context is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the primary action and scope. Every word contributes value, and there is no unnecessary detail or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description should explain more about return values, pagination, or usage constraints. It does not mention what the transfer history contains, how pages work, or how this tool relates to sibling tools. This is a minimal description that leaves out key context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% since both parameters ('address' and 'page') have descriptive text. The description adds no additional meaning beyond 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: 'Get NFT transfer history for an address'. It is specific and action-oriented. However, it does not differentiate from the closely named sibling tool 'vechainstats_get_nft_transfers', which likely serves a similar or overlapping purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as vechainstats_get_nft_transfers or nft_get_owned_tokens. The note 'uses VeChainStats' hints at an external dependency but does not clarify the intended use case or how it differs from similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits directly. It does disclose an important authentication requirement (minter role). However, it does not mention that this is an irreversible on-chain transaction, likely incurring gas costs, nor does it describe the expected response or failure modes. It adds some context but lacks a fuller disclosure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently states the action and a key prerequisite in parentheses. It contains no fluff and every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema provides complete parameter documentation, and the description gives a clear purpose and a minter-role requirement. However, as a blockchain write operation with no output schema, the description omits important context such as the transaction nature, gas requirements, and return value expectations. It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter descriptions already fully document each parameter. The tool description adds no additional parameter-specific meaning, keeping it at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Mint' with a clear resource 'new NFT token', making the action unambiguous. The parenthetical 'requires minter role on contract' adds a relevant constraint. This clearly distinguishes it from sibling tools like nft_burn, nft_transfer, and nft_approve.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly defines when to use the tool (to create a new NFT) and provides a clear prerequisite: the minter role. However, it does not explicitly contrast with alternatives or state when not to use it. The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior, but it only states the basic action. It fails to mention that ownership changes, that prior approval may be required, that the transfer is irreversible, or that the 'safe' parameter affects execution. This is a significant transparency gap for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero waste. Every word contributes to identifying the tool's purpose, and it is appropriately sized for the simplicity of the operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is too sparse for a state-changing tool. It does not explain expected return values, failure modes, ownership preconditions, or the significance of the 'safe' flag. An agent would likely need additional context to use this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage with descriptive parameter explanations ('Recipient address', 'Token ID to transfer', etc.). The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Transfer') and resource ('an NFT to another address'), clearly distinguishing it from siblings like nft_burn, nft_mint, and nft_approve. It accurately captures the tool's primary action without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like nft_approve or transfer_token. It does not mention prerequisites such as ownership or approval requirements, nor does it exclude cases where other transfer methods should be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of disclosing behavior. It merely restates the operation without mentioning the signature output format, whether it is read-only, or any side effects like user approval requirements. For a wallet action, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short, focused sentence with no filler or redundant information. It is optimally concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the tool has only one parameter, the lack of an output schema means the description should at least hint at the return value (e.g., a signature string). It also does not clarify whether signing is a safe, read-only operation or requires user interaction. With no annotations, the description is incomplete for an agent to fully understand the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the single 'message' parameter as 'Message to sign,' achieving 100% schema coverage. The tool description adds no additional parameter semantics, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Sign a message with the wallet.' It uses a specific verb and resource, and it is distinct from sibling tools like transfer_vet or vechainstats_get_block_info. However, it lacks details on the type or scope of signing, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool vs. alternatives, but signing is a unique operation among siblings, so usage is implicitly clear. The description does not mention prerequisites such as wallet connection or consent, nor does it note any situations where this tool should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions the main action (stake and mint) but omits crucial details like lock-up period, maturity, reversibility, or the need for a VET balance. Sibling tools like get_maturity_end_block suggest such aspects, but the description doesn't address them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the verb and outcome. Every word earns its place, and it avoids unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a staking/minting transaction, the description is too sparse. It doesn't explain what happens to staked assets, how to unstake, or any lock/maturity conditions. With no annotations or output schema, the description alone is inadequate for a complex action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for both parameters (levelId and autoDelegate) with descriptions. The tool description adds no additional semantics, such as how level names map to levelId range or the effect of autoDelegate, so it stays at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool stakes VET to mint a StarGate NFT, listing specific NFT levels. This distinguishes it from sibling tools like unstake_stargate_nft and get_staking_levels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a user wants to stake VET to mint an NFT, but provides no explicit when-to-use guidance or exclusions. It doesn't mention alternatives or prerequisites, relying on the uniqueness of the action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 says 'check if exists' without specifying the return format (e.g., boolean, status code), error behavior for invalid/missing tokens, or whether this involves a network call. The absence of any such details leaves significant ambiguity about the tool's runtime behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, six-word sentence that is extremely concise and front-loaded. Every word earns its place, and it avoids any extraneous detail, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple existence check with one required parameter and no output schema, the description is adequate but not fully complete. It doesn't state what the return value represents (e.g., does it return 'true'/'false' or a 200/404 status?) or any error conditions. Given the absence of an output schema, the description should have clarified the response format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single parameter (tokenId) with a clear description. The tool description adds no additional semantic value beyond what the schema provides, so the baseline score of 3 applies. There is no need for further compensation given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Check') and resource ('if a StarGate NFT token exists'), clearly stating the tool's exact purpose. It distinguishes itself from sibling tools like nft_check_ownership or nft_get_metadata by focusing purely on existence rather than ownership, metadata, or other attributes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention use cases, prerequisites, or why one would choose this over nft_check_ownership or vechainstats_get_nft_info. Users are left to infer the intended context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full behavioral burden. It only states the action without disclosing that this is a blockchain transaction, may require signing/authentication, may fail due to insufficient balance, or may be irreversible. The return value and side effects are also undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 9 words, front-loaded with action and resource, no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a transfer tool with four required parameters, no output schema, and no annotations, the description is under-specified. It omits crucial context about the transaction lifecycle, potential failure modes, prerequisites, and return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover all four parameters, so baseline is 3. The tool description reinforces the tokenSymbol examples and confirms the 'to' parameter is an address, but adds no new syntax, dependencies, or format details beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (Transfer), the resource (VIP-180 tokens), and the destination (another address). The inclusion of example tokens (VTHO, B3TR) distinguishes it from native VET transfer and NFT transfer siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies the target asset class (VIP-180 tokens), which implies the primary use case and differentiates from transfer_vet (native VET). However, it does not explicitly state when not to use this tool or name alternatives, so it falls short of a full usage guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not mention irreversibility, signing requirements, transaction fees, or side effects, which are critical for a fund-transferring mutation. The description is functionally a tautology of the tool's purpose, providing no additional 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the key action and resource, with no wasted words or redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple, fully documented parameter schema, but the description lacks behavioral context (e.g., on-chain execution, irreversibility, output format). Without annotations or output schema, the description is minimally viable but leaves important operational details unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with clear parameter descriptions ('to', 'amount' in VET, optional 'memo'). The description adds no extra parameter meaning, but the schema already documents all fields, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Transfer') and resource ('VET'), explicitly noting 'native VeChain tokens' to distinguish from token transfers like VIP180. This clarity differentiates it from siblings such as transfer_token and nft_transfer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide when-to-use guidance, exclusions, or alternatives. It only states the action, leaving the agent to infer the appropriate context. There is no mention of prerequisites like sufficient balance or that this tool is for native VET only, unlike transfer_token.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and explicitly discloses the key destructive effect: 'burn it'. It also specifies the reward (retrieve staked VET). However, it omits other behavioral details such as ownership requirements, maturity locks, or failure conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single 12-word sentence, front-loaded with the action, and contains no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter state-changing tool, the description states the core effect and purpose clearly. However, it lacks context about when to invoke it (e.g., after maturity) and what conditions must hold, making it minimally viable rather than fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents tokenId as 'Token ID to unstake', and the description adds no additional parameter semantics beyond restating the action. Baseline 3 applies due to 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Unstake' with the resource 'StarGate NFT' and clearly states the result 'burn it and retrieve the staked VET'. This distinguishes it from sibling tools like nft_burn (generic burn) and get_user_stakes (read-only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage—for exiting a StarGate NFT stake—but lacks explicit guidance on when to use it versus alternatives like claim_vtho_rewards or can_transfer_stargate_nft. It does not state prerequisites or when-not-to-use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 via the word 'check', but does not disclose return format, error behavior, or any side effects. The added context about B3TR funds and rewards pool is helpful but does not explain what the agent should expect from the call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no wasted words. It is 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one parameter, no output schema, and a simple read operation. The description tells the agent what it does and which parameter to supply, but it does not explain what the response will contain (e.g., the fund amount). Given the simplicity, it is adequate for basic selection and invocation, but it leaves the return value to the agent's inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (appId is described as 'VeBetter App ID'). The tool description adds minimal extra meaning by clarifying that the appId refers to the app for which funds are checked, but this does not significantly go beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Check'), a clear resource ('available B3TR funds in the rewards pool'), and scope ('for an app'). This clearly distinguishes it from sibling tools like vebetter_claim_rewards or vechainstats_get_balance, making it evident what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool or how it compares to alternatives. It does not mention prerequisites (e.g., the app must exist) or exclusions, only implying usage through its purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not mention that claiming likely involves an on-chain transaction, potential gas costs, or irreversibility. The minimal description leaves significant behavioral unknowns for a state-changing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately communicates the action and object. There is no redundant or filler content, and it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool performs a claim action, which is likely a transaction with side effects, yet the description lacks information about prerequisites (e.g., having available funds), return values (e.g., transaction hash), or any required authentication. With no annotations and no output schema, the description should provide more context but does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters ('appId' and 'amount'), so the schema already defines their meaning. The description adds no extra parameter context, which is acceptable given the high schema coverage, but it doesn't provide format or source details beyond the basic schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Claim'), the resource ('accumulated B3TR rewards'), and the context ('from a VeBetter app'). This distinguishes it from the sibling tool 'claim_vtho_rewards' by token type and source (VeBetter app).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when there are accumulated B3TR rewards from a VeBetter app, but it does not explicitly state when to use this tool versus alternatives like 'claim_vtho_rewards' or 'vebetter_check_available_funds'. No exclusions or related-tool guidance are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Get example submissions', which implies a read-only operation but does not mention response format, pagination, rate limits, or any side effects. For a no-parameter tool, the risk is low, but the absence of any behavioral context leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for the tool's simplicity and does not repeat any schema or annotation information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the tool is simple with no parameters and no output schema, the description does not explain what the example submissions contain, how they are formatted, or how they might be used. There is no output schema to fill this gap, so the description alone is insufficient for a complete understanding of the tool's return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema definition reflects that with an empty properties object. Since there are no parameters to document, the baseline score is 4. The description does not need to add parameter-level detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves example submissions for sustainable actions. The verb 'Get' and resource 'example submissions' make the function explicit. It distinguishes from the sibling 'vebetter_submit_action' which submits actions, but it does not explicitly reference that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention any related tools like vebetter_submit_action or vebetter_get_impact_categories, nor any prerequisites or context for use. The usage context must be inferred solely from the name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for behavioral disclosure, but it only says 'Get information' with no details on return format, side effects, read-only nature, or error handling. This gives the agent no insight into what the tool actually does beyond the implied get operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence and thus concise, but it is under-specified and merely expands the tool name without adding value. The sentence does not earn its place because it repeats information already contained in the tool name, lacking any substantive content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, no annotations, and a description that provides no information about return values, usage examples, or behavior. An agent cannot determine what data will be returned or how to handle the response. This is extremely incomplete for even a simple get operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for its single parameter 'appId', described as 'VeBetter App ID'. The description does not add further meaning to this parameter, but the schema already provides sufficient semantic context. Since schema coverage is complete, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get information about a VeBetter app' essentially restates the tool name 'vebetter_get_app_info' without adding any specificity about what 'information' entails. It does not differentiate from other get-type tools beyond naming the resource, which is already present in the tool name. This borders on tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (like having an appId), what scenarios call for this tool, or any exclusions. There is no context distinguishing it from sibling tools that also retrieve data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does disclose the primary behavior (returns a list of valid categories) and implies read-only via 'Get.' However, it does not mention dynamic behavior, authentication, or any other side effects, which is acceptable for such a simple getter but not particularly rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the tool's function without any filler. It is front-loaded and every word contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description is complete. It tells the agent exactly what is returned (a list of valid impact categories) and the context (for VeBetter submissions), which is sufficient given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the input schema already reflects this with empty properties. Since there are no parameters to explain, the baseline of 4 applies, and the description does not need to add parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: it gets a list of valid impact categories for VeBetter submissions. The verb 'Get' and the resource 'list of valid impact categories' are specific, and the context 'for VeBetter submissions' distinguishes it from sibling tools like vebetter_submit_action or vebetter_claim_rewards.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when needing to know valid impact categories for a submission, but it does not explicitly say when to use it or mention alternatives. There are no exclusions or when-not-to-use instructions, so it falls short of clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing side effects. It fails to mention that this likely creates an on-chain transaction, involves fees, or requires any approval/vetting process, leaving major behavioral aspects undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action, and contains no filler or redundancy. It is appropriately concise for the information it conveys.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a submission/write tool with 6 parameters, no output schema, and no annotations, the description omits critical context: return values, success/failure behavior, error conditions, and any setup steps. It is too sparse to be fully usable without additional clues from sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage with descriptions for all parameters, so the baseline of 3 is appropriate. The description adds no additional meaning beyond the schema's already explicit parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Submit a sustainable action') and the target ('to a VeBetter app'), with the purpose ('for rewards'). This distinctly differentiates it from sibling tools like vebetter_claim_rewards or read-only VeBetter tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., checking available funds) or contrast with claim/submission-related tools like vebetter_example_submissions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not mention any constraints (e.g., date must be historical), the effect of the 'expanded' parameter, or the shape of the response. As a read tool it likely doesn't have side effects, but the description provides no details 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded with the action and resource. The trailing 'etc.' is slightly vague but the overall structure is efficient. Every word earns its place, though more precision could be added without bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain what data is returned, any date range limitations, and how 'expanded' changes the response. It does none of that. For a data-returning tool with these gaps, the description is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'date' and 'expanded' are already documented in the schema. The description adds example stats (new accounts, active accounts) but does not add any parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Get daily statistics for accounts' with examples of the statistics (new accounts, active accounts). This is a specific verb+resource, but it doesn't explicitly differentiate from sibling tools like vechainstats_get_block_daily_stats or vechainstats_get_network_stats, though the name 'account' provides some distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. There are no explicit when-to-use or when-not-to-use statements, and no mention of alternatives. The description simply states what it does, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states what data is returned, not any side effects, failure modes, permissions, or the meaning of the 'expanded' flag. For a read tool this is minimal but not misleading, so a low score is warranted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the resource and key included data without filler. It earns its place by being brief yet informative enough to convey the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description needs to explain what the tool returns. It mentions balances and transaction count, but 'and more' is vague and does not clarify whether it includes staking, VTHO, or other account attributes. The tool is simple, but the ambiguity around 'comprehensive' and 'expanded' leaves gaps for an agent deciding whether to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema for 'address' and 'expanded'. It mentions 'balances, transaction count, and more' but does not clarify what 'expanded' changes, leaving parameter semantics to the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as retrieving 'comprehensive account information' with specific content ('balances, transaction count'), which is a specific verb+resource+scope. It implies broader coverage than sibling tools like get_balance or vechainstats_get_account_vtho_info, but does not explicitly name alternatives, so it falls just short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the word 'comprehensive' and the tool name, suggesting it is the general-purpose account info endpoint. However, there is no explicit guidance on when to use this tool versus specific siblings (e.g., get_balance, vechainstats_get_vip180_balance), nor any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not state that this is a read-only operation, whether an address must exist, or any side effects. The mention of data types gives some insight but not enough to fully understand tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, direct and front-loaded with the action and resource. No unnecessary words or redundancy, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple but lacks an output schema and usage guidance. The description gives useful examples of the returned data, but it does not clarify what the 'expanded' flag changes, nor does it distinguish this tool from similar account stats tools. With no annotations, some gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters with descriptions, providing a baseline of 3. The description adds context about VTHO details (generation rate, accumulated), but it does not explain the 'expanded' parameter beyond the schema's minimal 'Include expanded details', so value added is moderate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets detailed VTHO information for an account, with specific examples (generation rate, accumulated). This distinguishes it from sibling tools like get_account_info, which would cover broader account details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when VTHO info is needed but does not explicitly discuss alternatives or when not to use. It lacks a clear 'use this when' or exclusion statement that would help an agent decide between similar account-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 disclosing behavioral traits. The description only restates the tool's function ('Get carbon emissions') without mentioning whether it is read-only, what data is returned, any authentication/rate limits, or how the multiple optional parameters interact. This is a minimal disclosure with no added context beyond the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and front-loaded with the action. It provides both function and context without any redundant text. The phrase 'perfect for VeBetter sustainability tracking!' is short and adds usage context, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description must compensate by explaining the tool's behavior and parameter selection. It fails to clarify how the optional parameters relate (e.g., address vs txid vs blocknum) or what the response contains. For a tool with four optional parameters, this is insufficient guidance 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all four parameters (txid, address, blocknum, timeframe). The tool description adds no additional parameter meaning or usage guidance, so it does not elevate beyond the schema baseline. The baseline of 3 applies because the schema already documents the parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action: 'Get carbon emissions (CO2e) for an address'. This distinguishes it from sibling tools like vechainstats_get_transaction_emissions and vechainstats_get_network_emissions by specifying the address scope. The added use-case of 'VeBetter sustainability tracking' provides clear context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: for address-based emissions, as opposed to transaction or network emissions. It also mentions a specific use case (VeBetter sustainability tracking). However, it does not explicitly name alternatives or provide exclusion criteria, but the address scope is clear from the first sentence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 says 'Get prices' but does not disclose potential response size, pagination, rate limits, price freshness, or any side effects (though likely none). The lack of any detail about the returned data format or operational characteristics 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that is immediately informative. It avoids filler words and clearly communicates the tool's purpose and differentiating feature ('in one call').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple no-parameter tool, but without an output schema or annotations, the description should at least hint at what 'prices' means (e.g., currency, format, or whether it includes all known tokens). The description is minimally adequate but leaves out details that could affect an agent's expectations, such as potential large payload or price time reference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and the schema description coverage is 100% (vacuously). The description does not need to add parameter semantics, and the baseline for a zero-parameter tool is 4. The description adds no extra parameter info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get'), the resource ('all VeChain tokens'), and the scope ('in one call'), which distinguishes it from the sibling tool vechainstats_get_token_price that presumably handles a single token. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'all VeChain tokens in one call' strongly implies this is the batching alternative to the singular get_token_price, giving clear context for when to use it. However, it does not explicitly name the alternative or provide an exclusion condition, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for disclosing behavioral traits, but it discloses none. It lacks any mention of response format, pagination, rate limits, or data freshness. The description only restates the 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no wasted words. It conveys exactly what the tool does in one line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (no parameters, no output schema), the description is adequate for an agent to understand its purpose. It could mention the return format, but that is not essential for a simple list getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema is vacuously fully covered. The description does not need to add parameter details, and the baseline for 0-parameter tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get list') and the resource ('authority nodes (validators) on VeChain'). It is specific enough to distinguish from sibling tools such as vechainstats_get_current_block or vechainstats_get_node_token_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage—when the agent needs a list of authority nodes—but it does not provide explicit when-to-use/when-not-to-use guidance or mention any alternatives. No exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral transparency. It only describes the input format and does not disclose what the block data contains, whether it is a full vs. summary representation, or any error/edge-case behavior. Minimal context is added beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the key information (action, resource, identifier format). No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and no output schema, so a brief description may suffice. However, without annotations or return-value details, the description is somewhat thin but adequate for a straightforward getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% because the only parameter 'blockref' has a description matching the tool description. While the parameter semantics are clear from the schema, the description adds no new meaning beyond restating the required format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get block'), the specific resource ('block'), and the distinct lookup method ('by block reference'), which is an 8-byte hex string. This distinguishes it from sibling tools like get_block_by_timestamp and get_block_info, which use different identifiers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where another block-lookup tool would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 a high-level action without mentioning return format, whether the block is exact or closest match, error behavior on invalid timestamps, or that it is a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately minimal for a simple tool, but it loses a point because the lack of detail makes it under-specified for an agent needing behavioral context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, no output schema, and no annotations, the description must compensate by explaining return values and edge cases. It fails to do so, leaving major ambiguities about what the returned block contains, how timestamps are matched, and what the agent can expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the parameter blockts clearly defined as a Unix timestamp. The tool description adds no extra parameter meaning beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Find' with resource 'block' and lookup criterion 'by timestamp', clearly stating the core function. It distinguishes from siblings like get_block_by_reference and get_current_block by specifying the timestamp lookup method, though it doesn't describe what block details are returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a clear use case—retrieve a block when you have a Unix timestamp—but offers no explicit guidance, alternative comparisons, or prerequisites. It leaves the agent to infer when this tool is preferred over other block-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 lists some returned content (gas used, transaction count) but omits details like whether the data is cached, how the 'expanded' parameter changes behavior, or any permissions/rate limits. The read-only nature is implied but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the action and resource. It is appropriately brief for a simple tool, though the trailing 'etc.' is a bit vague. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations, and one undocumented parameter, the description is insufficient for fully understanding behavior and return structure. It gives a high-level summary but leaves key specifics (e.g., exact stats included, expanded effect) to inference, making it incomplete for a tool in a large family.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%: 'date' is documented, but 'expanded' has no description. The tool description does not explain what 'expanded' controls, so parameter semantics are incomplete. The description adds no value beyond the date field already defined in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Get' + 'daily block statistics', with examples of content (gas used, transaction count). The 'daily' qualifier distinguishes it from sibling tools like get_block_info (specific block) and get_network_stats (network-wide), so the purpose is specific and non-misleading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case: when you need daily aggregate block statistics for a given date. However, it does not explicitly state when to use this tool over alternatives like get_block_info or get_network_stats, nor are there any exclusions or alternative references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior, but it only says 'detailed information' without specifying what fields are returned, whether any permissions are needed, or any quirks. It adds minimal behavioral context beyond the tool name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single terse sentence with no filler, making it easy to parse. It could be more informative without sacrificing brevity, but as written it is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter lookup tool, the description conveys the core purpose, but it does not describe return values or usage context, and there is no output schema to fill the gap. This is adequate but leaves the agent uncertain about what 'detailed information' will be returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.