Teardrop

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

With readOnlyHint=true already covering the safety profile, the description adds meaningful behavioral context by stating that the tool returns an agent-branchable verdict with specific values and compact risk summaries. It also reveals the underlying data domains considered, which helps the agent predict what the call will do beyond the annotation alone.

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

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

Two sentences carry the full functional contract: the first defines what the tool assesses and the second defines its machine-consumable output. There is no filler or repetition of annotation/schema fields, and the most decision-relevant information is 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?

Given the tool has a documented input schema, readOnly annotations, and an output schema referenced by the description, the description is largely complete: an agent knows the input, the scope, and the verdict format. The only minor gap is the absence of explicit guidance on when this composite tool should be chosen over the narrower 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?

Schema description coverage is 100%, so the schema already documents wallet_address and chain_ids, including the 'positions and net worth remain all-chain' nuance. The description reinforces that risk assessment spans approvals, liquidation health, and activity history, but it does not add parameter-level detail beyond what the schema already 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 states a specific verb ('Assess'), resource ('counterparty risk for an EVM address'), and scope ('across token approvals, liquidation health, and activity history'). It also names the exact verdict values it returns, making the tool's function unambiguous and distinguishable from sibling tools like get_liquidation_risk or get_token_approvals.

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 clearly implies this is the holistic counterparty-risk assessment tool by enumerating the dimensions it covers, but it does not explicitly say when to prefer it over individual sibling tools such as get_liquidation_risk, get_token_approvals, or get_wallet_history. There are no exclusions or alternative routing conditions, so the usage guidance is mostly implicit.

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 already convey readOnlyHint=true, so the description need not restate read-only. The description adds behavioral context by noting the expression is 'safe' (implying no arbitrary code execution) and explicitly enumerating supported functions and constants, which clarifies what the tool can and cannot evaluate. This goes beyond the schema's simple 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, efficient sentence with a front-loaded action ('Evaluate') and a compact enumeration of supported operations. Every word contributes value, with no redundant or vague 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?

Given that the tool has one parameter, an output schema exists, and the readOnly annotation is provided, the description is sufficiently complete. It covers the tool's domain, safe evaluation, and the full set of supported operations, so an agent can invoke it confidently without needing additional behavioral or return-value details.

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 for the 'expression' parameter covers 100% of the parameter, providing an example. The tool description additionally itemizes accepted operators and functions (+, -, *, /, **, %, sqrt, abs, round, etc.), giving the agent a clearer understanding of valid input format and capabilities beyond 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 uses the specific verb 'evaluate' and clearly identifies the resource as an 'arithmetic expression'. It lists supported operations, making the tool's scope unambiguous and distinguishing it from siblings that deal with currency, stats, transactions, and blockchain 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 implies usage for arithmetic computation by stating 'Evaluate a safe arithmetic expression' and listing supported functions, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No alternative tools are named, and no when-not-to-use guidance 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?

The readOnlyHint annotation already establishes the tool as non-mutating. The description adds that the tool returns both the converted amount and the exchange rate, which is useful context, but it does not disclose any potential caveats such as rate sourcing, latency, or supported currency limitations. With annotations covering the safety profile, this is adequate but not exceptional.

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, compact sentence that efficiently conveys the tool's purpose and output. It avoids unnecessary words and front-loads the key information, making it easy for an agent 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?

For a straightforward converter with a simple parameter set and an output schema, the description covers the essential aspects: what it converts, what it returns, and the types of assets involved. It lacks discussion of edge cases or rate specifics, but these are not critical for a basic read-only tool. The description is complete enough to guide 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?

The input schema provides descriptions for all three parameters (amount, from_currency, to_currency) with examples and constraints, achieving 100% coverage. The tool description does not add further semantic detail beyond what the schema offers, 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 that the tool converts between fiat currencies and crypto assets, using the specific verb 'convert' and naming the resource ('currency' and 'assets'). It also specifies the return values (converted amount and exchange rate), which distinguishes it from price-lookup tools like get_token_price.

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 currency conversion but does not explicitly mention when to prefer it over sibling tools such as get_token_price or get_dex_quote. No exclusions or alternative usage scenarios are provided, leaving the agent to infer the appropriate context from the tool's name and description.

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

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

The readOnlyHint annotation already signals a non-destructive operation. The description adds detail about what the tool returns (word, character, sentence, paragraph stats), giving the agent a clear behavioral expectation. It does not dive into tokenization edge cases or the exact meaning of 'paragraph statistics,' but for a tool of this simplicity, the added context is valuable.

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 directly lists the tool's outputs. Every word earns its place; there is no redundancy or fluff, making it both 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?

Given the low complexity, the presence of a readOnlyHint, and an output schema (which presumably defines return values), the description is complete enough for an agent to select and invoke the tool correctly. It covers the essence without needing to restate schema details.

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: the only parameter 'text' is described as 'Text to summarize,' and the tool description says 'for a given text,' so the parameter's purpose is clear. The description does not add significantly beyond the schema (e.g., formats, length limits), but the schema already handles this 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 specifies a concrete verb ('Return') and enumerates the specific outputs (word count, character count, sentence count, paragraph statistics). It unambiguously identifies a text-analysis tool that is distinct from all sibling tools, which are blockchain/defi/web utilities.

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 explicitly state when to use this tool vs alternatives, nor does it offer any exclusions or prerequisites. However, the purpose is self-evident: when the agent needs text metrics, this is the obvious choice. This makes usage guidelines only implied rather than explicitly articulated.

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 already declare readOnlyHint=true, so the description need not restate safety. It adds value by revealing the default fallback to 4byte.directory when no ABI is given, the specific return fields (status, gas used, block number), and chain support. This exceeds the annotation's minimal safety signal without contradicting it.

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?

Three sentences, front-loaded with the core action, and every sentence earns its place. No redundant phrasing or filler. The structure is ideal: purpose, return values, then parameter guidance.

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 there is an output schema (return shape is documented), the description need not enumerate every field. It covers purpose, parameter behavior, fallback logic, and chain support, which is sufficient for a read-only tool with high schema coverage. No critical 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 description coverage is 100%, so the schema already documents all three parameters. The description adds little beyond restating that abi_json is optional and that 4byte.directory is the fallback, which aligns with the schema. This is baseline for high coverage; no additional semantic depth is offered.

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 starts with a specific verb and resource: 'Decode a transaction's calldata into a human-readable function name and arguments.' It clearly distinguishes from sibling tools like get_transaction (raw transaction retrieval) and read_contract (state reads) by specifying the calldata decoding purpose. It also lists supplementary outputs (status, gas used, block number), further clarifying 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 clear context on when to use the optional ABI parameter (for precise decoding) versus relying on the default 4byte.directory. It also states supported chains (Ethereum mainnet and Base). However, it does not explicitly contrast with alternative tools (e.g., when to use get_transaction instead), so it stops short of full 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?

Annotations already indicate readOnlyHint=false and idempotentHint=false, so mutation and non-idempotency are known. The description adds the specific behavioral flow: agent-card discovery, message sending, and result returning. However, it does not warn about potential side effects on the remote agent side or failure modes, which would add useful behavioral context for a non-read-only 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?

Three short, purposeful sentences: what it does, how it does it, and when to use it. No filler or repeated schema 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 description, combined with a fully described schema and an output schema, is nearly complete for correct invocation. It justifies when to use the tool and explains the delegation flow. The main gap is not explicitly addressing remote side effects or cautioning that the target agent may perform actions with consequences, which matters given readOnlyHint=false.

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% and each parameter already has a clear description, including the task_type enum and its telemetry/routing purpose. The tool description adds nothing beyond the schema for parameters, 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 ('Delegate') and identifies the exact resource (a remote A2A-compliant agent), then explains the mechanism: discovers capabilities, sends a message, returns the result. This distinguishes it from sibling tools like discover_agents or web_search, which serve different purposes.

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

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

The description gives a clear usage condition: use when a task requires specialist capabilities beyond your own tools. It does not explicitly name alternatives or state when not to use the tool, but the intended context is well conveyed without ambiguity.

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 already carry the readOnlyHint=true safety profile. The description adds useful scoping context — only opt-in, publicly-registered agents with published reputation are returned — which is genuine behavioral information. However, it does not disclose search semantics, matching behavior, or the nature of the registry being queried.

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 that leads with the verb 'Find' and packs in the resource plus three result attributes with zero filler. Every word earns its place, and the description 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?

The tool has a full output schema, completely documented parameters, and a readOnlyHint annotation, so the description need not explain return values or safety. The essential call context is present. The only gap is usage differentiation from delegate_to_agent, which is minor for a simple discovery 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%: both q (search across agent name, organization slug, or published tool name) and limit (max returns, bounds, default) are fully documented. The description adds no parameter-level 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 uses a specific verb ('Find') with a precise resource ('opt-in remote A2A agents') and enumerates what results include (published tool capabilities, endpoints, public reputation status). This clearly distinguishes the tool from its sibling delegate_to_agent, which is about interacting with an agent rather than discovering 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 states what the tool finds but gives no conditions for when to use it over alternatives. It never references delegate_to_agent or any other sibling, and offers no exclusion criteria or prerequisites — the agent is left to infer the appropriate scenario.

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?

The readOnlyHint annotation already declares the safe read-only behavior. The description adds no additional behavioral context such as limits, prerequisites, or edge cases. It remains consistent with the annotation, but does not enrich it beyond the 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 purpose. 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?

This is a simple read-only tool with an output schema and fully described optional parameters. The description covers the core purpose and identifier types, making it complete for typical use, though it does not mention default chain_id or block_identifier, which is acceptable given schema defaults.

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% for both chain_id and block_identifier. The description mentions 'number, hash, or latest', which is already present in the block_identifier schema description. It does not add new semantics 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 clearly states the tool gets details for an Ethereum or Base block by number, hash, or 'latest'. This is a specific verb+resource with explicit identifier options, distinguishing it from sibling transaction or metrics 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 about when to use this tool versus alternatives like get_transaction or get_chain_metrics. The usage context is only implied by the read operation, with no exclusions or alternative recommendations.

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?

The description adds behavioral detail beyond the readOnlyHint annotation by stating that 'Historical and fee fields fail open when DeFiLlama does not cover a chain.' This discloses important fallback behavior that the annotation does not convey, providing meaningful 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 three sentences, front-loads the core purpose, then gives usage guidance, and ends with a caveat. Every sentence earns its place with no fluff 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?

Given the tool's moderate complexity, the presence of an output schema, and readOnlyHint annotation, the description is complete. It covers purpose, usage patterns, default behavior (highest-TVL), and a key edge case (fail-open), leaving no major 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%, so the schema already explains each parameter. The description adds value by illustrating usage of the chains parameter with an example and clarifying the limit behavior ('omit chains to inspect the highest-TVL ecosystems'). However, it doesn't add detail about the days parameter, so 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 starts with a specific verb and resource: 'Compare blockchain ecosystem health using DeFiLlama current TVL, 7-day and 30-day TVL changes, and aggregate fee activity.' This clearly distinguishes it from sibling tools like get_protocol_tvl or get_dex_volume, which focus on different metrics.

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 usage contexts: 'Pass chains such as [...] for a focused comparison, or omit chains to inspect the highest-TVL ecosystems.' While it doesn't explicitly name alternatives or exclusion cases, it effectively communicates when and how to use the tool, earning a 4 rather than 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?

The annotation readOnlyHint=true already declares the safe read-only nature. The description adds the important context that the time is in UTC, which is a meaningful behavioral detail. No other behavioral traits are disclosed, but none are expected for such a simple 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 concise sentence that front-loads the core function and mentions the optional parameter. 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?

Given the low complexity, presence of an output schema, and the read-only annotation, the description is complete. It does not need to explain return values because the output schema covers that.

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 the 'format' parameter with a default and description (100% coverage). The description only says 'Optional strftime format parameter' which adds little 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 uses the specific verb 'Return' with the resource 'current UTC date and time', clearly stating the tool's function. It distinguishes from sibling tools as the only datetime-related tool among crypto-focused 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?

No guidance is given about when to prefer this tool over alternatives. Since there are no obvious alternatives, this is a minor gap, but the description does not explicitly state 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?

Beyond the readOnlyHint annotation, the description discloses detailed behavior: only reads data, returns specific Aave/Compound/Uniswap breakdowns, includes Lido balances on Ethereum, and isolates per-protocol failures so other protocols still return results. This is comprehensive and adds significant value beyond the annotation.

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 information-dense but not bloated. Four sentences cover purpose, return details, chain-specific behavior, and error isolation—every sentence earns its place and the main purpose is 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?

Given the high complexity of aggregating multiple protocols, the description is complete: it covers chains, protocols, return contents for each protocol, chain-specific extras, and failure handling. The output schema exists, and the description still provides additional useful context, making it fully 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%, and the schema already explains both parameters (wallet_address and chain_id). The description restates chain_id values but adds minimal new meaning beyond the schema, 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 ('aggregate') and identifies the exact resource ('DeFi positions for a wallet') plus the protocols and chains covered (Aave v3, Compound v3, Uniswap v3 LP, Ethereum/Base). It clearly distinguishes from sibling tools like get_wallet_portfolio by naming the precise protocols and 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 clear context on what the tool does (aggregating multiple DeFi protocols), so an agent can infer when to use it. However, it does not explicitly name alternatives or state when NOT to use it, falling short of the highest level of 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?

The description enriches the readOnlyHint annotation with critical behavioral details: it queries four fee tiers in parallel, returns the best tier plus a breakdown, reports no_liquidity=true when no pool exists, and returns a block_number for point-in-time quotes. It also cautions against caching. This goes well beyond the annotation's safety signal.

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, information-dense paragraph. Every sentence contributes unique value: purpose, mechanism, input formats, native ETH caveat, no-liquidity behavior, and point-in-time nature. There is no redundancy or fluff.

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

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

Given the tool's complexity (multi-chain, four fee tiers, specific input constraints), the description covers all essentials: supported chains, parallel tier queries, output choice, no-liquidity handling, and freshness caveat. It even warns against caching. The presence of an output schema means return values need not be fully described, and the description is complete enough for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, so the schema already thoroughly documents token_in, token_out, amount_in, and chain_id. The description adds a brief note about raw uint256 amounts and EIP-55 addresses, but this largely duplicates schema content. Since the schema handles parameter explanations, the description adds minimal additional semantic value.

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

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

The description clearly states the tool's function: obtaining the best Uniswap v3 swap quote on Ethereum or Base. It specifies the method (direct on-chain QuoterV2), the resource (Uniswap v3), and the scope (chain_ids 1 and 8453). This distinguishes it from sibling tools like get_token_price or get_dex_volume.

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: it is for on-chain swap quotes, explicitly lists supported chains, and explains that native ETH is not quoted directly (use WETH). It also warns against caching due to point-in-time quotes. While it does not explicitly name alternative tools, the intended usage is unmistakable given the specific inputs and behavior.

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?

The readOnlyHint annotation already covers the safety profile, and the description adds meaningful behavioral detail: it lists the exact metrics returned (24h/7d/30d volume, period-over-period changes, share of global volume) and the source. It does not contradict the annotations or hide any obvious side effects beyond what a read-only tool 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 two tight sentences: the first front-loads the primary purpose, and the second enumerates the key metrics and filtering/ranking options. Every phrase earns its place with 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?

With a read-only annotation, a fully documented 3-parameter schema, and an output schema present, the description provides sufficient selection and invocation context. It names the data source, return metrics, filtering options, and ranking window, leaving no obvious gaps for an agent to misuse 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 already provides 100% coverage of all three parameters with clear descriptions, so the description does not add significant meaning beyond the schema. It restates the filtering/ranking semantics, but the schema already documents limit, protocols, and lookback_days accurately, warranting the baseline score.

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 opens with a specific verb ('Compare') and resource ('decentralized exchange activity from DeFiLlama'), making the tool's purpose immediately clear. It also distinguishes itself from siblings like get_dex_quote and get_protocol_tvl by focusing on volume comparison metrics.

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 clearly establishes when to use the tool (when comparing DEX activity from DeFiLlama) and how to tailor it via protocol filters and lookback windows. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion 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?

The annotation readOnlyHint=true already signals this as a safe read operation, and the description adds little beyond the return data hint ('including symbol and decimals'), which is also covered by the output schema. No additional behavioral context such as chain support limitations, error conditions, or rate limits is provided.

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. Every word contributes to stating the tool's purpose, making it appropriately concise.

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 simple nature of the tool, the detailed schema, the read-only annotation, and the presence of an output schema, the description is sufficient. It could mention that chain_id defaults to Ethereum, but that is already in the schema, so no major gaps exist.

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?

All three parameters (chain_id, token_address, wallet_address) are fully described in the schema with clear descriptions, so the description adds no new meaning. The schema coverage is 100%, so 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 clearly states the tool's function: retrieving an ERC-20 token balance for a given wallet, with the added detail of returning symbol and decimals. While it is specific and distinguishes from generic balance tools, it does not explicitly differentiate from sibling tools like get_eth_balance or get_wallet_portfolio.

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 use for querying ERC-20 balances but offers no explicit guidance on when to choose this over alternatives, nor any exclusions or prerequisites. The use case is inferred from the tool name and description rather than 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?

The readOnlyHint annotation already discloses that this is a safe read operation. The description adds useful context by mentioning the portfolio overlap, but does not go deeper into behaviors like return format, error handling, or network specifics beyond schema. With annotations carrying the safety profile, this is adequate but not rich (consistent with the calibration 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 exactly two sentences. The first sentence states purpose, the second provides a critical usage note. No redundant words, no filler. Every sentence earns its place, and the note about get_wallet_portfolio is essential for correct tool selection.

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 read-only tool with an output schema, the description covers what it does, when to use it, and which sibling to avoid. The existence of an output schema means return-value details are not required in the description. It is complete within the context of the tool's complexity.

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

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

Schema description coverage is 100%: both address and chain_id are fully described in the input schema. The description adds nothing new about the parameters themselves, only reinforcing the Ethereum/Base chain support. Baseline of 3 applies because the schema does the heavy lifting.

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'), a clear resource ('native ETH balance'), and a scope ('Ethereum or Base address'). It explicitly distinguishes itself from get_wallet_portfolio, which is a sibling tool, by noting the balance is already included there. This is a precise, non-tautological purpose statement.

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 explicit guidance on when to use the tool ('only call get_eth_balance when you need a standalone ETH balance without a full portfolio scan') and names the alternative (get_wallet_portfolio). This is a clear usage vs. alternative distinction, exceeding mere implied 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?

Beyond the readOnlyHint annotation, the description adds valuable behavioral details: results are cached for 10 seconds per chain, gas_used_ratio thresholds for congestion are defined, and optional USD estimates are explained. This gives the agent a comprehensive understanding of data freshness and interpretation, complementing the annotation.

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 three sentences, with the primary purpose front-loaded in the first sentence. Each sentence provides distinct value: purpose, core outputs and congestion interpretation, and optional extras/caching. No fluff or repetition, 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?

Given the tool's simplicity (two optional parameters, output schema present), the description is complete. It covers the purpose, key output fields, congestion thresholds, optional USD estimates, and caching. The agent has sufficient context to select and invoke the tool correctly without unmet informational needs.

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 full descriptions for both parameters, achieving 100% coverage. The description adds minimal extra meaning, such as clarifying that USD estimates include rough transfer and swap costs. This is a baseline 3 where the schema does the heavy lifting, and the description offers marginal additional semantics.

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 current EIP-1559 gas fees on Ethereum or Base, with a specific verb and resource. It distinguishes itself from sibling tools like get_token_price or get_block by focusing on gas fees and listing specific outputs. The first sentence is explicit 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 description provides clear usage context: it is useful for timing transactions and network congestion assessment via gas_used_ratio. However, it lacks explicit alternatives or when-not-to-use guidance, though no sibling tool directly competes for this purpose. A 4 reflects strong context without explicit 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?

Annotations already declare readOnlyHint=true, so the description adds value by disclosing the return format: 'per-asset APY snapshots and Compound utilization where available.' It also includes the caveat 'where available,' which clarifies behavior when data may be incomplete. No contradictions with annotations.

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

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

Three sentences, each with a specific purpose: what it returns, return details, and a use-case example. No fluff or redundant information. Front-loaded with the primary action ('Get current on-chain lending supply/borrow rates').

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 an output schema, so return values need not be explained, but the description still mentions APY snapshots and utilization, which helps. The description covers the protocols, chains, and a concrete use case, making it complete for a read-only list-style tool with well-documented parameters and annotations.

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% (all parameters have descriptions), so the baseline is 3. The description adds context about protocol and chain coverage ('Aave v3 reserves and Compound v3 markets on Ethereum or Base') but does not add meaning for the assets filter or chain_id beyond what the schema already provides. The description does not compensate for any parameter gaps because there are none.

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') with a clear resource ('on-chain lending supply/borrow rates') and explicitly scopes it to 'expanded Aave v3 reserves and Compound v3 markets on Ethereum or Base.' It also distinguishes from siblings like get_yield_rates by emphasizing protocol-specific lending rates, not general yields.

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 indicates when to use this tool: 'Useful for protocol-specific stablecoin yield comparisons (e.g., USDC on Aave vs Compound).' This provides clear context, but it does not explicitly mention sibling tools as alternatives or state when NOT to use it. No exclusions 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?

Annotations already mark readOnlyHint=true, and the description reinforces with 'View-only (eth_call)' plus adds valuable behavioral details: per-protocol failure isolation, silent duplicate removal, and hardcoded addresses. These go beyond the annotation and give the agent confidence about side-effect-free operation and error handling.

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?

Three sentences, front-loaded with purpose, then output summary, then edge-case behaviors. No fluff; every sentence contributes value and the structure is logical.

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 an output schema present, return types are already documented. The description adds failure isolation, deduplication, and the full tier list, covering edge cases. No major 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 coverage is 100% with descriptions for both chain_id and wallet_addresses. The description repeats the max 50 and chain IDs but doesn't add new parameter-level meaning beyond the schema. Baseline of 3 is appropriate since the schema already does the heavy lifting.

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 with a specific verb and resource: 'Assess DeFi liquidation risk for up to 50 wallets across expanded Aave v3 and Compound v3 coverage.' It names the chains, protocols, and output types, distinguishing it from sibling tools like get_defi_positions or get_lending_rates.

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 for liquidation risk assessment, but it doesn't explicitly state when to prefer this tool over alternatives or mention exclusions. It mentions expanded coverage, which hints at comprehensiveness, but lacks direct comparison such as 'for alternative, use X instead.'

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 declare readOnlyHint=true; description does not contradict. Adds beyond annotations by describing batch vs single-protocol response differences (compact summary vs detailed chain/history), revenue_error_type, and that historical series is optional. No mention of rate limits or auth, but readonly annotation covers safety.

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?

Description is 4-5 sentences, front-loaded with purpose and key outputs. Each sentence adds value (supported protocols, batch behavior, error type). Could be slightly tightened but no 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?

With 4 optional params, no output schema, and moderate complexity, the description covers return values, batch vs single differences, historical option, fees/revenue when available, and error identifier. Provides comprehensive context for an AI agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% (4 params all described in schema). Description adds significant context: explains slug format with examples, distinguishes 'aave' vs 'aave-v3', clarifies days usage only when include_historical=True, and describes batch mode behavior. Greatly exceeds 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 gets TVL data for DeFi protocols from DeFiLlama, specifying returned metrics (current TVL, 7/30-day change, chain breakdown, optional historical, fees/revenue). It differentiates from sibling tools like get_dex_volume or get_lending_rates by being protocol-level TVL specific.

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?

Provides explicit usage guidance: slug format, batch mode via protocols=[...], auto-correction of aliases, and context for when to use single vs batch. Lacks explicit when-not-to-use or comparisons to alternatives, but purpose is narrow enough that it's 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?

Beyond the readOnlyHint annotation, the description discloses default behavior (returns non-zero approvals from tracked-asset registry and curated protocol spenders) and output semantics (flags unlimited approvals with risk levels). It also provides network limitations, giving substantial 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 concise, front-loaded with the primary purpose, and each sentence adds value: purpose, defaults, risk flags, use cases, and network restrictions. 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?

Given the output schema exists and all parameters are described, the description fully covers the tool's behavior, use cases, and limitations. No critical information is missing.

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% as all four parameters have detailed descriptions in the schema. The description adds minimal extra meaning, mostly reinforcing defaults (e.g., 'shared tracked-asset registry' vs schema's 'platform tracked token list'). No significant new parameter semantics 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 the tool's purpose with a specific verb ('Audit') and resource ('ERC-20 token allowances for a wallet address'). It distinguishes itself from sibling tools by focusing on approvals/allowances and risk flagging, rather than balances or transactions.

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 explicit usage scenarios: 'Use before swaps to verify approval state, or after security incidents to detect active exploit vectors.' It also states an exclusion: 'Ethereum mainnet and Base only,' clarifying when the tool is not applicable.

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 only provide readOnlyHint true. The description goes beyond by explaining unknown symbol auto-resolution against 'the full CoinGecko coin list', the unsupported nature of 'Bare 0x contract addresses', and the batch cap. These are meaningful behavioral details not present in the annotation.

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?

Six sentences, each carrying specific information: purpose, accepted input forms, resolution behavior, batch limit, address limitation, and reuse guidance. No filler or redundant phrasing; the main purpose is 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?

With an output schema present, return-value documentation is unnecessary. The description covers input flexibility, resolution behavior, batch constraints, and a reuse recommendation, making it comprehensive for a token-price lookup tool. There are no obvious missing behavioral expectations.

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 parameter descriptions already present, so the baseline is 3. The description adds value by revealing that full token names are accepted and that unknown symbols resolve automatically, which the schema does not mention. This enriches parameter understanding.

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

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

Description states 'Get current price, 24h change, market cap, fully-diluted valuation, and volume for one or more crypto tokens' — a specific verb and resource, clearly distinguishing it from siblings like get_token_price_historical by emphasizing 'current'. The tool's scope is 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?

Explicitly instructs 'If get_wallet_portfolio already returned price_usd/value_usd for a held token, reuse that value instead of calling get_token_price again', providing a clear when-not-to-use alternative. It also spells out accepted identifier types (symbols, names, CoinGecko IDs) and the 50-token batch limit, offering concrete selection 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?

Annotations declare readOnlyHint=true, but the description adds substantial context beyond that: it explains how dca_baseline_90d is computed (weekly samples over preceding 90 UTC days, excluding latest observation), notes dca_baseline_90d_partial identifies incomplete history, and warns that metrics are pre-computed and should not be re-derived with calculate. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose, then compactly enumerates return metrics and usage guidance. Every sentence serves a distinct function—purpose, output details, edge-case identifier, use cases, alternative, and optimization. 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?

The tool is complex with multiple precomputed metrics, but the description covers all key aspects: return value composition, granularity caveats, partial history handling, and guidance on avoiding re-derivation. An output schema exists, so return values need not be exhaustively spelled out, yet the description still provides a rich overview.

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 a small amount of semantic value by clarifying when stats_only is useful ('when the daily series is unnecessary'), but most parameter meaning is already fully documented in the schema. No significant gap to compensate.

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 verb+resource ('Get historical price data for crypto tokens') and details the exact outputs (period statistics, daily price series, high_30d, std_30d, dca_baseline_90d). It distinguishes from siblings like get_token_price and web_search by focusing on historical time windows and time-comparative analysis.

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?

Explicit use cases are given ('Use for period comparisons (month-over-month, YTD), trend analysis, and price charts'), with a direct alternative ('Prefer over web_search for time-comparative financial queries') and a conditional optimization ('Pass stats_only=true when the daily series is unnecessary'). This is textbook usage 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?

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: it includes specific fields like bounded calldata and normalized event logs, and notes the fee is included 'when available', indicating conditional behavior. This goes beyond merely restating annotations.

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

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

Two tightly packed sentences with no filler. Each clause adds value: the first defines the core action and scope, the second lists key return fields and conditional behavior. Excellent structure for quick comprehension.

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 covers the purpose, scope, and key output details, and the output schema exists to define return structure. It lacks error behavior or prerequisites, but for a simple read tool with full annotations and an output schema, it is sufficiently complete to guide an 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?

Input schema covers 100% of parameters with descriptions (tx_hash format, chain_id with Ethereum/Base values). The description provides no additional parameter-level semantics beyond what the schema already states, so it rests at the baseline for full 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'), a specific resource ('details and receipt for an Ethereum or Base transaction by hash'), and enumerates distinctive outputs (bounded calldata, normalized event logs, transaction index, effective gas price). This clearly distinguishes it from siblings like decode_transaction.

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 have a transaction hash and need details/receipt) but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions. The sibling decode_transaction could benefit from a note, but the context is not misleading.

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 already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral context about the return contents (spenders, USD exposure, protocol attribution, and hacked/abandoned flags) and the broader scope relative to the sibling. No destructive behavior is implied, and no contradiction exists.

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 core purpose, then return highlights, then a comparative pointer. Every sentence earns its place with no redundancy or fluff.

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 an output schema present, return values are documented. The description covers what the tool does, its chain scope, the parameters (implicitly), the type of data returned, and its relationship to a key sibling. This is complete for an agent to select and call 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 already describes both parameters with 100% coverage. The description adds no additional parameter-level detail beyond tying 'wallet' and 'chain' to the context. Baseline 3 applies because the schema carries the semantics.

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 inspects a wallet's ERC-20 token authorization exposure on a specific chain, with a specific verb ('inspect') and resource. It also immediately distinguishes itself from the sibling get_token_approvals by noting it is broader, so an agent can differentiate.

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 a clear alternative by comparing to get_token_approvals and characterizing it as 'curated block-accurate', implying when the narrower tool is appropriate. However, it doesn't explicitly state 'use this when' or 'do not use when', leaving some inference 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?

Annotations include readOnlyHint=true, so the safety profile is covered. The description adds important behavioral details beyond annotations: it reveals that the tool returns 'decoded' transactions with categories and metadata, and explains the pagination mechanism using next_cursor. This transparency is helpful and goes 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?

Two sentences, front-loaded with the primary purpose, followed by return details and pagination guidance. Every sentence earns its place, and 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?

The tool is moderately complex (4 params, output schema present). The description clearly covers what the tool returns, the scope of chains, and how to page through results. It is complete and actionable without needing to explain return values due to the output schema.

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 all parameters, so baseline is 3. The description adds value by explaining how start_time relates to the returned next_cursor for cursor pagination, which provides practical semantic meaning not fully captured in the parameter description 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 states the tool's function: 'Get one page of decoded transaction history for an EVM wallet across DeBank-supported chains.' It specifies the resource (wallet history), the scope (one page, EVM, DeBank-supported chains), and includes return categories, distinguishing it from sibling tools like get_transaction or get_wallet_approvals.

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 usage instruction for pagination: 'Use the returned next_cursor as start_time to page backward.' It implies when to use this tool (for browsing transaction history) but does not explicitly state when not to use it or name alternatives among siblings. Still, the pagination guidance is actionable and valuable.

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?

Despite having readOnlyHint annotation, the description adds valuable context: it lists asset categories, chain coverage, sorting by USD value, a hard limit of 20 holdings, and the inclusion of native ETH. This goes well beyond the annotation to set expectations about the returned data.

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?

Three sentences, each providing distinct information: overall function, coverage/scope, and a usage caveat. No wasted words, and the most important detail is 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?

With an output schema present and read-only annotation, the description fully covers the tool's behavior, including limits, sorting, and coverage. It provides enough context for an agent to decide when to call 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?

Both parameters have detailed descriptions in the schema (wallet address, chain_id with chain IDs). The description reinforces the chain coverage but does not add new parameter-specific information, so schema carries the burden.

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 aggregated token holdings with USD values') and clearly identifies the resource (wallet address). It also distinguishes from siblings by noting that native ETH balance is included, making a subsequent get_eth_balance call redundant.

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 warns against calling get_eth_balance separately, which is a clear exclusion. It also implies this tool is for broad portfolio views across supported chains, though it doesn't enumerate all alternatives.

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?

The readOnlyHint annotation already establishes safety, and the description adds meaningful context: it returns protocol-level positions, asset/debt/net values, optional all-chain net worth, and complete cross-chain token lists when requested. It also notes that include_token_balances adds a billable provider request (though part of that is in the schema). No contradiction with annotations.

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

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

Three focused sentences deliver the core purpose, return contents, key parameter behavior, comparison to an alternative, and usage boundary. Every sentence earns its place with 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?

The tool is moderately complex (cross-chain DeFi positions), but the description plus a rich input schema and output schema fully cover scope, return types, optional parameters, tool differentiation, and important exclusions. The agent has enough context to select and invoke this tool correctly.

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

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

Schema coverage is 100% with clear parameter descriptions, so the baseline is 3. The description reinforces include_token_balances behavior and mentions optional net worth, but adds little beyond what the schema already states. It does not provide unique semantic value for wallet_address 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 clearly states the tool gets a wallet's DeFi positions across all DeBank-supported chains and protocols. It explicitly distinguishes itself from the sibling get_defi_positions by noting it covers substantially more protocols and chains, 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?

Provides explicit guidance: use this for broad DeFi position retrieval, and use raw-RPC tools for liquidation, swap quotes, or transaction-critical questions. It also names the alternative get_defi_positions and explains the difference, giving clear when-to-use and when-not-to-use 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?

Adds rich behavioral detail beyond the readOnlyHint annotation: describes return fields, the 50-pool cap, symbols_any whole-token matching and per-symbol ranking, the note field for unmatched symbols, and the effect of stable_only and max_apy on ranking and filtering. This gives the agent a strong mental model of the tool's behavior.

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

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

The description is front-loaded with a clear purpose, then provides dense, high-value guidance on filtering and edge cases. It is longer than average, but every sentence adds information relevant to using the tool correctly, and it maintains a logical flow from what it does to how to use specific parameters.

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 8 optional parameters, an output schema, and only a readOnlyHint annotation, the description fully compensates: it covers use cases, parameter interpretation, edge-case behavior, and client-side filtering instructions. The tool's behavior is thoroughly specified, leaving no significant ambiguity for 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?

Even though the schema already covers all parameters, the description adds meaning beyond schema entries: it explains that symbols_any returns the highest-ranked pool per requested symbol and notes missing symbols in the note field, clarifies stable_only's ranking change, and recommends max_apy=30 to exclude leveraged pools. These details are not in the schema and materially improve parameter understanding.

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 DeFi yield pool rates from DeFiLlama, covers 1,000+ protocols across chains, and returns pools sorted by APY with specific fields. It includes example queries that make the purpose and scope unambiguous, and its focus on yield rates with protocol/chain filters distinguishes it from sibling tools like get_lending_rates and get_defi_positions.

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?

Provides explicit when-to-use guidance via example questions and specific strategies like 'Call once per query unless a genuinely disjoint filter is required' and 'filter on the client side by inspecting symbol rather than re-calling'. However, it does not explicitly name alternatives or state when not to use this tool in favor of a sibling, so it falls short of a perfect 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?

The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context by stating that it 'extracts main text content' and 'returns cleaned text, not raw HTML,' which sets expectations for the output. It does not disclose potential failures like JS-dependent pages or redirects, but the annotation lowers the burden.

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 short sentences that are front-loaded with the core purpose, then provide a use case and output format. Every sentence adds value and there is no redundancy or padding.

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 two-parameter tool with an output schema, a read-only annotation, and a clear description of behavior and output format, the description is complete. The cleaned-text return behavior is explicitly stated, and schema details cover the rest.

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 descriptions cover 100% of the parameters, providing details on URL format and max_chars bounds/defaults. The description itself adds no extra parameter semantics beyond the schema's coverage, 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 uses a specific verb ('Fetch') and resource ('a web page') and clearly states the operation ('extract its main text content'). It also differentiates from sibling tools like web_search by focusing on fetching a given URL rather than searching, and notes the output is cleaned text, not raw HTML.

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 clear use cases: 'reading articles, documentation, and web resources.' However, it does not explicitly mention alternatives or when not to use this tool (e.g., 'use web_search when searching for pages'), so it stops short of full exclusion 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?

Beyond the readOnlyHint annotation, the description discloses that state-changing functions are rejected, that historical queries are supported, and that calls use a bounded RPC timeout and rate-limit retry policy. This adds meaningful behavioral context about safety and reliability that is not available from annotations alone.

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

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

The description is concise at five sentences, front-loaded with the core purpose. Each sentence adds value, covering safety, historical queries, caller context, and RPC policy. It is slightly longer than necessary but remains efficient and well-structured.

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

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

Given the tool's complexity (8 parameters, output schema, readOnlyHint), the description covers key functional aspects: arbitrary view/pure calls, ABI requirements, rejection of state-changing functions, historical block support, caller context, and timeout/retry behavior. It does not explain return formatting, but the output schema covers this, and not all parameter semantics are repeated, which is acceptable.

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 descriptions cover 100% of parameters, so the description adds little extra information. It mentions providing the ABI fragment and block_identifier, but these are already well-documented in the schema. The description does not clarify ambiguous parameters like args vs args_json, so it remains at the 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 clearly states the tool calls any view/pure function on a smart contract and returns the result. It specifically distinguishes itself by noting state-changing functions are rejected, making it distinct from sibling tools that perform specific reads or transactions.

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 it is for view/pure functions, explicitly excluding state-changing functions for safety. It also mentions support for historical queries and caller_address, which guides when to use these features. However, it does not explicitly mention when to prefer sibling tools like get_erc20_balance for specific token reads.

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?

The description says 'record,' which strongly implies a write operation, while the annotation readOnlyHint=true declares the operation as read-only. This is a direct contradiction. No other behavioral context is provided.

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

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

Two sentences, front-loaded with the purpose, then usage instruction. Every word is necessary, with 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?

The description gives basic usage but leaves the side-effect ambiguity unresolved due to the contradiction between 'record' and readOnlyHint. A single nested object parameter and an output schema exist, yet the description fails to clarify whether or how data is persisted, making it 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 already describes the 'predictions' parameter with 100% coverage. The description adds meaningful format guidance: 'exact machine-readable prediction' and separating the human-readable report, which enriches the parameter's intended use 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 uses a specific verb ('record') with a clear object ('complete structured prediction document') and purpose ('for downstream evaluation'). It clearly distinguishes this tool from siblings, which are mostly read-only getters or calculations.

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 explicit usage instructions: call once with the exact machine-readable prediction, and provide the human-readable report separately. It does not name alternative tools, but no sibling appears to serve the same recording function, making context 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?

Annotations already declare readOnlyHint=true, so the description adds value by disclosing additional behavior: reverse lookup capability, avatar text record availability, and the mainnet-only restriction. It does not contradict annotations and goes beyond basic safety hints, but stops short of describing edge cases like unregistered names or error handling.

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

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

Two sentences, each with clear purpose. The core resolution is stated first, followed by the avatar addition and network constraint. No fluff or repetition; it is both 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?

For a single-parameter tool with an output schema, the description covers all essential aspects: the input formats (name/address), the output direction (address/primary name), the avatar record, and the network (mainnet). The presence of an output schema means return value details are already provided, so the description is fully 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%, so the parameter is already fully documented in the schema. The description essentially restates the same info ('ENS name' or 'Ethereum address') without adding new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description uses a specific verb ('resolve') and clearly defines the resource (ENS names/addresses). It covers both forward and reverse resolution, which distinguishes it from sibling tools like balance checkers and transaction fetchers. The mention of avatar records and mainnet-only adds specificity 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 implies its use case by explaining exactly what it does, and the 'Mainnet only' constraint provides a clear exclusion. However, there is no explicit 'use this when' statement or mention of alternatives, though no sibling tool directly overlaps with ENS resolution.

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?

Beyond the readOnlyHint annotation, the description discloses that it uses DeFiLlama metrics, historical TVL drawdown charts, and token price stability, and that it returns one of four verdicts. This gives useful behavioral context without contradicting the annotation.

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 long, front-loads the action, and includes the key output contract. Every sentence contributes necessary information with 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?

With one well-documented parameter, an output schema, and readOnlyHint annotation, the description is complete enough for an agent to select and invoke the tool correctly. It covers the input, the analytical approach, and the expected verdict 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 documents pool_id, including an example UUID, so schema coverage is high. The description adds no additional parameter-level detail, which is acceptable given the baseline of 3 for high 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 ('Assess') with a clear resource ('economic sustainability and liquidity risk of a DeFi yield pool') and states the output as a branchable verdict plus structured risk factors. It is distinct enough from siblings like assess_counterparty_risk and get_yield_rates.

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 makes the context clear: use this tool when a DeFi yield pool needs sustainability and liquidity-risk assessment. It does not explicitly name alternatives or state when not to use it, but the intended scenario is evident.

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 already declare readOnlyHint=true, so the description does not need to restate that. It adds valuable behavioral context by noting that search_depth='advanced' incurs higher cost and that topic='news' or 'finance' narrows results, insights not present in the annotations. This goes beyond the structured data, though it does not mention potential rate limits or pagination, which could be useful.

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 three sentences, front-loaded with the primary purpose, followed by parameter guidance. Every sentence adds distinct value, with no filler or redundancy. It is appropriately concise while covering purpose, use cases, and parameter nuances.

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 moderate complexity, full schema coverage, and read-only annotation, the description supplies all essential information: what it does, when to use it, and how to tailor parameters. The presence of an output schema means return value details are unnecessary, so the description is fully sufficient for agent selection and 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%, so the baseline is 3, but the description enriches parameter meaning by linking search_depth to complex research queries and cost, and topic to specific content domains (news, finance). These usage-oriented hints help the agent make better parameter choices than the bare schema descriptions 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 a real-time web search via Tavily, stating its purpose for current events, fact-checking, and research. This distinguishes it from the sibling tools, which are specific data lookups or calculations, leaving no ambiguity about what this 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 clear use cases (current events, fact-checking, research) and practical guidance on when to adjust parameters (search_depth for complex queries, topic for news/finance). However, it does not explicitly compare with alternatives like http_fetch or delegate_to_agent, so it lacks explicit exclusionary guidance, earning a 4 rather than a 5.

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