Teardrop

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 valuable context beyond annotations: it explicitly states limitations (not a credit bureau, fraud guarantee, or legal endorsement) and data sources (DeBank indexing, Aave/Compound contract states). This gives the agent realistic expectations without contradicting the annotation. It could go further by mentioning error handling or edge cases, but the provided context is solid.

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 well-structured: a tight opening sentence, then purpose-built sections (Use when, Limitations, Alternatives) that are each one line. No filler, everything earns its place, and the most critical usage guidance 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 readOnlyHint annotation, an output schema, and fully documented parameters, the description covers the essential non-obvious aspects: when to use, limitations, and alternatives. It doesn't explain how to interpret the verdict branches, but the output schema likely handles that. Overall it's complete for an agent to decide and call 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%, and both parameters have descriptions in the schema. The wallet_address description is minimal ('EVM wallet address (0x-prefixed)') but sufficient; chain_ids has a richer description explaining scoping. The tool description itself adds no parameter-level detail beyond what the schema provides, so a 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 opens with a specific verb ('Return') and a precise resource ('decision-ready counterparty-risk verdict for an EVM address'), then enumerates the four possible outcome branches (high_risk, caution, acceptable, insufficient_data). It clearly distinguishes itself from siblings by naming the alternatives at the end, so an agent can differentiate without opening schemas.

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 'Use when' section gives concrete trigger conditions (before sending funds, granting approvals, or interacting with an unknown EVM address) and explicitly limits to cases needing a bounded risk decision. The 'Alternatives' section names three sibling tools, providing clear routing to other specific tools when the general verdict is not needed.

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, and the description adds meaningful behavioral context beyond that: it is arithmetic-only, has no aggregation/unit conversion/financial modeling, and errors return an error field rather than raising. This gives the agent a clear model of what the tool will and won't do. It doesn't describe every edge case, but it covers the important behavioral boundaries.

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 well-structured with clear sections: a one-sentence purpose, a 'Use when' section, a 'Limitations' section, and an 'Alternatives' section. Every sentence earns its place, and the most important information is front-loaded. It is appropriately sized for the tool's complexity.

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

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

Given the tool's simplicity (one parameter, read-only, arithmetic-only), the description is complete. It covers purpose, usage, limitations, alternatives, and error behavior. The output schema exists, so the description doesn't need to explain return values. An agent has everything it needs to decide when to call this tool and how to construct a valid expression.

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 the single 'expression' parameter. The description adds value by listing supported operators/functions and giving an example expression format, which helps the agent construct valid input. It doesn't need to do much more because there is only one parameter and the schema covers it.

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 ('Evaluate'), a resource ('a safe arithmetic expression'), and the outcome ('return the numeric result'). It also lists supported operators/functions and explicitly distinguishes itself from sibling tools by saying it is for derived figures that no tool output already provides. This is a clear, specific purpose that an agent can act on.

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 'Use when' guidance, tells the agent when NOT to use it (do not re-derive pre-computed fields like std_30d or dca_baseline_90d), and names alternatives (get_token_price_historical, get_datetime). This is exactly the kind of when/when-not/alternatives guidance that helps an agent select the right tool.

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 is not required to state that this is a read-only operation. It adds valuable context beyond the annotation: the tool performs spot-rate conversion at request time, has no historical/forward rates, and does not model slippage or fees. It also clarifies that actual swap execution is handled by a different tool, which is useful behavioral disclosure. The only minor omission is whether the rate is live or cached, but this is acceptable given the annotation coverage.

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

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

The description is well-structured with clear 'Use when', 'Limitations', and 'Alternatives' sections. Each sentence serves a distinct purpose, and the most important scoping information (what the tool does) is front-loaded. The text is concise without redundancy, and the alternatives are explicitly named, making it easy for an agent to parse quickly.

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

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

Given that the tool has an output schema (as indicated by 'has output schema: true'), the description does not need to explain return values. The description covers the tool's purpose, usage conditions, limitations, and alternatives, which is comprehensive for an agent to call it correctly. Nothing critical is missing for a currency conversion 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% — all three parameters (amount, from_currency, to_currency) have descriptive names and explanations in the schema itself. The tool description does not add any additional parameter-level meaning, such as accepted formats, examples beyond those in the schema, or constraints. Since the schema fully documents the parameters, a baseline score of 3 is appropriate; the description adds no extra 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 a specific verb ('Convert an amount') with a specific resource (fiat currencies and crypto assets) and explicitly lists the supported asset classes. It names the two sibling tools it is not (get_token_price, get_dex_quote) and explains the difference, making it unambiguous for an agent to select this tool.

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 includes explicit 'Use when' guidance with concrete examples (converting USD portfolio to EUR, fiat to crypto), and explicitly says for prices only use get_token_price, and for actual swap execution use get_dex_quote. It also clearly states limitations (spot-rate only, no historical/forward rates, no slippage/fee modeling), leaving no ambiguity about when to use this tool versus 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?

Annotations already mark this as read-only, and the description adds useful behavioral limitations: pure counting, no language detection, no reading-level or sentiment analysis, and no external retrieval. It does not cover edge cases like empty text or error handling, but for a simple read-only counter with an output schema, the disclosure is adequate.

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 tightly structured with clear labeled sections: what it does, when to use it, limitations, and alternatives. Each sentence earns its place, and the most important purpose 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?

For a simple, read-only counting tool with one fully described parameter and an output schema, the description covers purpose, usage context, exclusions, and alternatives. Nothing needed to invoke it correctly 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?

The single 'text' parameter is fully described in the schema at 100% coverage, giving a baseline of 3. The description adds value by correcting the schema's misleading 'Text to summarize' phrase, clarifying that the text is raw content to be counted rather than semantically summarized. No additional parameter-level syntax is needed for such a simple input.

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 and resource: it returns counts of words, characters, sentences, paragraphs, and average words per sentence. It clearly separates this from semantic work by stating it 'counts only', and it names alternatives, distinguishing itself from web_search and http_fetch.

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 'Use when' section gives concrete examples—validating a summary length contract or comparing document sizes—and explicitly says not to use it for semantic summarization. The limitation note that it does not retrieve external content reinforces when web_search or http_fetch would be better choices.

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, and the description adds useful behavioral context: it uses a supplied ABI when provided, otherwise falls back to 4byte.directory, and notes that 4byte.directory matching can be ambiguous or absent for custom contracts. It also states the one-transaction-per-call limit and supported chains. This goes beyond the annotation 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?

The description is well-structured with clear sections: what it does, when to use, limitations, and alternatives. It's slightly longer than necessary but every section earns its place, and the core 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?

The description covers the tool's purpose, usage context, limitations, and alternatives. An output schema exists, so return values don't need to be explained. The only minor gap is that it doesn't explicitly state what happens when decoding fails or when no ABI is supplied and 4byte.directory has no match, but the limitations section partially covers this.

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 context about the ABI fallback behavior and chain support, but doesn't add significant new meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: decode a transaction's calldata into a human-readable function name and arguments, plus return status, gas used, and block number. It clearly distinguishes itself from siblings like get_transaction and get_wallet_history by focusing on calldata decoding and transaction explanation.

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 says 'Use when' one known transaction must be explained, and names the alternative get_wallet_history for wallet-wide patterns. It also lists alternatives get_transaction and get_wallet_history, giving clear routing 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 indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and the description adds critical behavior beyond that: it involves real payment, requires allowlisted URL and budget, and notes that remote agent claims are not verified. This goes beyond annotations by warning about payment and unverified capabilities. Slight deduction for not mentioning error handling beyond the specific error_type, but substantial 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?

Description is well-structured with headings 'Use when', 'Limitations', 'Alternatives', making it scannable. It is appropriately sized given the tool's complexity. The opening sentence is concise, and the sections are efficient. Minor redundancy in mentioning 'payment' twice (in opening sentence and limitations), so 4 rather than 5.

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 (involving payment, remote agent, A2A protocol), the description covers key operational aspects: discovery, retry behavior, preconditions. An output schema exists, so return format is not required. It lacks detailed communication protocol expectations, but for a delegation tool, this is sufficient. Strong coverage.

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 all parameters are documented in the schema. The description adds a small note about task_type being for telemetry (echoing schema's 'never include user data'), which aligns but doesn't add new meaning. It doesn't explain how task_description should be formatted beyond natural language, but baseline 3 is appropriate given 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 clearly specifies the action (delegate a task to a remote A2A-compliant agent), the resource (remote agent), and the outcome (return the result). It distinguishes itself from local tools by stating 'only when no local platform tool can fulfil the request', which differentiates it from siblings like http_fetch and web_search.

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 'Use when' conditions, requires calling discover_agents first if URL unknown, and warns against retrying on specific error_type. It also names alternatives (discover_agents, web_search) in the Alternatives section, giving clear guidance on when to use this tool versus 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?

Annotations already declare readOnlyHint=true, and the description reinforces this while adding more: discovery 'does not add an agent to the org allowlist' and 'delegate_to_agent remains authoritative.' This is useful behavioral context beyond the structured 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 compact, with a clear front-loaded purpose followed by labeled 'Use when,' 'Limitations,' and 'Alternatives' sections. Each section earns its place and avoids redundant or filler 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?

Given the output schema exists, the read-only annotation, and the explicit routing to delegate_to_agent, the description is sufficiently complete. It covers purpose, usage timing, side-effect boundaries, and alternatives without needing to explain return values.

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

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

Schema description coverage is 100% for the two optional parameters (q and limit), so the schema already documents parameter meaning. The description adds no additional parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific action ('Find') on a specific resource ('opt-in remote A2A agents, published tool capabilities, endpoints, and public reputation status'). It distinguishes the tool from name/tautology and references its intended role relative to delegate_to_agent.

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 says when to use it: 'before delegate_to_agent when a specialist agent is needed but its URL is unknown.' It also gives an exclusion by noting discovery does not add an agent to the allowlist, and names delegate_to_agent as the alternative.

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 provide only readOnlyHint: true. The description adds valuable behavioral context beyond that: limitations ('One block per call', 'Ethereum mainnet and Base only') and the caveat that historical base fee data depends on RPC node retention. It does not contradict the read-only annotation and covers the key operational constraints.

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

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

The description is well-organized into purpose, usage, limitations, and alternatives. It is front-loaded with the core function and each section earns its place. However, at seven sentences it is slightly longer than strictly necessary; still, no filler or redundancy.

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

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

With an output schema present, return values are already defined. The description covers what the tool does, when to use it, alternatives, and limitations. For a simple read-only block-fetch tool, this is complete enough for an agent to call it correctly without additional information.

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 input schema already explains both parameters (chain_id, block_identifier). The description mentions 'by number, hash, or latest' and 'Ethereum and Base', but these are also present in the schema. It adds no new parameter-level meaning, 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 clearly states a specific verb and resource: 'Get block details' and lists the exact fields (timestamp, gas used, base fee, miner, transaction count) and acceptable identifiers (number, hash, 'latest'). It also frames the purpose with 'Use to anchor events to a point in chain time', distinguishing it from related tools like get_transaction and get_gas_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 includes an explicit 'Use when' section with concrete examples (dating a transaction, checking congestion) and a direct exclusion: 'For current fee levels use get_gas_price instead.' It also lists alternatives (get_transaction, get_gas_price), giving the agent clear direction on when to choose this tool over siblings.

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 annotations only declare readOnlyHint=true, which is minimal. The description adds meaningful behavioral context: it names the third-party data source (DeFiLlama), states that historical and fee fields fail open as null for uncovered chains, and warns that this is not a real-time measure of chain throughput or security. These caveats materially affect how an agent should interpret and trust results.

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 well organized: a compact opening sentence covering the core purpose and metrics, followed by clearly labeled 'Use when,' 'Limitations,' and 'Alternatives' sections. Every sentence contributes meaningful decision-support information, and the most important scoping statement 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 that the tool has no required parameters, has an output schema, and carries only a readOnlyHint annotation, the description covers everything the agent needs: what the tool does, when to use it, what limits apply, and which siblings to fall back on. The additional caveats about null fields and non-real-time data complete the operational picture.

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 input schema already documents all three parameters. The description adds an example of chain filtering and an explanation of omission behavior, but the schema already provides equivalent detail for the chains parameter)SkipTo: 'Optional chain names to compare... When omitted, return highest-TVL chains up to limit.' Thus the description adds no significant semantic value 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 ('Compare') with a clear resource ('blockchain ecosystem health via DeFiLlama') and enumerates the exact metrics returned: current TVL, 7/30-day TVL change, and aggregate fee activity. It also distinguishes itself from get_protocol_tvl and get_dex_volume by naming them directly, so an agent can tell this tool apart from sibling data tools.

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

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

The 'Use when' section explicitly states the intended ecosystem-level use cases and gives a concrete exclusion: for a single protocol's economics, use get_protocol_tvl. It also names get_dex_volume as an alternative and explains how the omit-chains behavior differs from passing an explicit chain list. This gives sufficient routing guidance without leaving anything to inference.

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 agent knows this is safe. The description adds valuable behavioral context beyond that: it states 'UTC only — no timezone conversion' and warns that 'An unsupported strftime format silently falls back to the default format instead of erroring.' This discloses failure modes and constraints, which is exactly the kind of context that helps an agent avoid surprises. 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 concise and well-structured. It front-loads the core purpose in the first sentence, then provides 'Use when' guidance, 'Limitations,' and 'Alternatives' in separate labeled sections. Every sentence earns its place; there is no fluff or redundancy. The structure makes it easy for an agent to quickly extract the key decision points.

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 (one optional parameter, no nested objects) and the presence of an output schema (indicated but not shown), the description is fully complete. It covers purpose, usage conditions, exclusions, limitations, and alternatives. There is no missing information an agent would need to correctly invoke 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?

Schema coverage is 100% (the format parameter has a description), so the baseline is 3. The description adds semantic value by explaining the parameter is a strftime format string, reiterating the default behavior, and specifically noting the silent fallback on unsupported formats. This goes beyond the schema's terse description and helps the agent choose an appropriate format.

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

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

The description clearly states the tool's function: 'Return the current UTC date and time as a formatted string and ISO 8601 timestamp.' This is a specific verb (return) with a precise resource (current UTC datetime), and it distinguishes itself from siblings by focusing on datetime retrieval. The added purpose of 'grounding time-relative reasoning' clarifies its intent 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 'Use when' section explicitly enumerates scenarios (computing ages, windows, deadlines, 'as of today') and also provides a critical exclusion: 'The runtime context block already states the date, so call this only when a specific strftime format or a precise timestamp is needed.' This tells the agent exactly when NOT to call it, and it lists alternatives (calculate, get_block) for comparison. The guidance is actionable and prevents unnecessary calls.

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 aligns with that. It adds valuable behavioral context beyond annotations: per-protocol failure isolation, the fact that errors list unavailable protocols, and the warning that Compound v3 only reports a boolean liquidation flag rather than a numeric health factor.

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 longer than minimal but well-organized with labeled sections: use-when, limitations, and alternatives. Content is front-loaded with the core purpose, and each section earns its place, though the repeated 'Use when:' phrase is mildly redundant.

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 annotations covering read-only safety, the description supplies everything else needed: invocation conditions, protocol scope, failure behavior, Compound caveat, and alternative tools. Nothing essential 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%, so the schema already documents wallet_address and chain_id fully. The description reinforces the Ethereum/Base scope but adds no significant new parameter semantics, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: it returns block-accurate DeFi positions for a wallet across Aave v3, Compound v3, Uniswap v3 LP, and Lido. It also enumerates concrete return details like health factor, LP positions, and Lido balances, making the tool's purpose unmistakable and distinct from siblings.

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

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

The description provides explicit 'Use when' guidance, tells the agent to use get_wallet_positions for broad all-chain discovery, and lists alternatives including get_liquidation_risk and get_wallet_portfolio. Limitations such as chain scope and Compound's boolean-only flag further guide correct invocation.

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?

While the annotation readOnlyHint=true already indicates a safe read, the description adds substantial behavioral context: it is a point-in-time quote, should not be cached, returns no_liquidity=true when no pool exists, and provides a per-tier breakdown. It also warns about native ETH and the need to pass WETH. These details go beyond the annotation and help the agent use the tool correctly.

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 organized into clear sections (function, use when, limitations, alternatives) and front-loads the core purpose. However, some redundancy exists: the limitations section repeats the native ETH and point-in-time constraints already mentioned in the first paragraph. A lighter rewrite would tighten it, but the structure is still effective and each section 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 output schema exists (which presumably details the return structure), the description covers all necessary operational aspects: supported chains, fee tiers, input format requirements, caching warning, and alternative tools. Nothing an agent needs to invoke the tool correctly is missing. Even without the output schema, the description would be fairly complete, and with it, it 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 baseline is 3. The description enriches parameter usage with practical examples: it explains raw uint256 and gives common token decimals for amount_in, provides specific WETH addresses for native ETH, and explicitly instructs not to call read_contract for decimals. This substantially improves usability beyond the schema's own descriptions, hence a 4.

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

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

The description clearly states a specific verb+resource: 'Get the best Uniswap v3 swap quote on Ethereum or Base via direct on-chain QuoterV2 calls.' It enumerates the chains, the mechanism (QuoterV2), the fee tiers, and the selection criterion (highest output amount). It also distinguishes itself from siblings by naming alternatives (get_token_price, get_dex_volume) and stating exactly what it returns, so an agent can tell it apart without opening schemas.

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 an explicit 'Use when' section that specifies the intended context: 'when you need a best-execution Uniswap v3 swap quote on Ethereum or Base before executing a trade.' It also lists alternatives and their roles, making clear when to prefer this tool versus get_token_price or get_dex_volume. The guidance is direct and actionable.

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, and the description adds meaningful behavioral context beyond that: data comes from third-party DeFiLlama reporting rather than on-chain truth, coverage gaps may understate smaller protocols, and the 24h share is computed against the unfiltered global total. These caveats materially inform how an agent should interpret results.

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 tightly structured with clear sections: core purpose first, then use cases, limitations, and alternatives. Every sentence earns its place, 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?

For a read-only tool with 3 optional parameters and an output schema, the description covers the purpose, data source, caveats, and alternatives. Nothing an agent needs in order to select and invoke this tool correctly 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%, so the input schema already documents all three parameters. The description adds light context by mapping 'protocols' to filtering and 'lookback_days' to ranking, but it does not provide substantial semantic value beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Compare') with a clear resource (decentralized exchange activity via DeFiLlama) and enumerates the exact metrics returned: 24h/7d/30-day volume, period-over-period changes, and global share. It also distinguishes itself from siblings by naming get_dex_quote and get_chain_metrics, so an agent can tell this tool apart without opening schemas.

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 'Use when' section explicitly identifies the intended landscape questions, and the limitation that executable swap pricing should use get_dex_quote instead provides a clear exclusion. The Alternatives line further reinforces routing, leaving no ambiguity about when this tool is appropriate.

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

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

Annotations only include readOnlyHint, so the description carries the burden of behavioral disclosure. It discloses the output format (normalized by decimals, symbol), the limitation of one token per call, the need for a contract address (no symbol lookup), and the lack of USD valuation. It does not contradict the readOnlyHint. Slightly more could be said about error handling, but the core behavior is well covered.

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 structured into sections (purpose, use when, limitations, alternatives) and front-loads the core function. While it's longer than a single sentence, each section adds distinct value and there is no redundancy. It earns its length without being verbose.

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 read-only tool with an output schema and 100% parameter coverage, the description covers the key operational context: when to use, limitations, and output characteristics. It does not mention potential error conditions or rate limits, but for a simple balance check, these are minor. The description is sufficiently complete for an agent to call it correctly.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds the clarification that token_address must be a contract address and cannot be a symbol, and mentions the supported chains (Ethereum/Base). This is a modest enhancement over the schema, which already labels the token_address as a contract address. Baseline 3 is appropriate.

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

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

The description clearly states the verb (Get), the resource (on-chain ERC-20 balance of a wallet for one token contract), and adds specific detail (normalized by decimals, returned with symbol). It explicitly differentiates from sibling tools like get_wallet_portfolio (multi-asset) and get_eth_balance (ETH), so an agent can select it correctly.

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 'Use when' guidance with a concrete example (confirming funds before approval/transfer), explicitly says when not to use it (multi-asset portfolio → get_wallet_portfolio), and lists alternatives at the end. This is fully actionable.

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 important behavioral constraints: native ETH only, Ethereum mainnet and Base only, EIP-55 checksummed address requirement, and block-accurate on-chain exactness. This gives the agent safety and compatibility information that annotations alone do not provide.

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 heading-based structure is clear and front-loaded, but there is some redundancy: the fact that get_wallet_portfolio already includes native ETH appears twice, and 'Use when:' is followed by 'Use when'. Minor repetition keeps it from being a 5.

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 read-only tool with an output schema present, the description covers purpose, usage timing, limitations, and alternatives. Nothing essential is missing for an agent to decide whether to call this tool and do so 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%, so the baseline is 3, but the description adds meaningful parameter context by requiring an EIP-55 checksummed address and clarifying chain support (Ethereum vs Base). It also explains the output units in wei and ether, which helps the agent interpret results.

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 and resource: getting the exact on-chain native ETH balance of an address on Ethereum or Base, in wei and ether. It explicitly distinguishes itself from get_wallet_portfolio and get_erc20_balance, so an agent can immediately tell which tool fills this niche.

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?

It gives explicit when-to-use guidance for gas-availability checks and standalone balance verification, and clearly instructs not to call it after or alongside get_wallet_portfolio. It also names the alternative tools for portfolio and ERC-20 balances.

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 indicates this is a safe read; the description goes beyond that by adding the 10-second cache, the point-in-time/change-every-block caveat, and the rough-heuristic limitation on USD figures. That is meaningful context an agent needs before acting on the output. A small deduction because the description does not explicitly mention rate limits or error behavior, but those are not critical for a read-only gas price call.

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

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

The description is tight and front-loaded: the first sentence states what the tool returns, the second gives use guidance, and the third lists limitations and alternatives. Every sentence earns its place; there is no filler or redundant restatement of the tool name.

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

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

For a read-only tool with only two optional parameters, a 100%-coverage schema, and an output schema present, the description is complete enough: it covers purpose, usage timing, cache behavior, limitations, and alternatives. The only small gap is the absence of explicit error/edge-case behavior (e.g., unsupported chain handling), which is minor and not essential for correct 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 schema already explains both parameters. The description adds value by clarifying how include_usd_estimate is used (rough heuristics at 21k/150k gas) and by stating the cache implication (repeated calls are wasteful), which goes beyond simply restating 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 names a specific resource (EIP-1559 gas fees on Ethereum/Base) and identifies the concrete data returned: base fee, priority fee, next-block estimate, and congestion thresholds. It also explicitly scopes the tool by chain (Ethereum and Base only) and by what it is not (an execution quote). This distinguishes it from the sibling tools get_block and get_dex_quote without needing to inspect their schemas.

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 when-to-use guidance ('Use before advising a transaction') and when-not-to (calls are pointless within the 10-second cache). It also names the alternatives (get_block, get_dex_quote) to divert the agent appropriately. No exclusion is left to inference.

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

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

With only readOnlyHint=true in annotations, the description carries the behavioral burden and does so thoroughly. It discloses the errors list behavior, the point-in-time nature of rates, the 'empty rates with empty errors' transient RPC condition, and the protocol scope limitation. This goes well beyond what annotations convey and does not contradict them.

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

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

The description is well-structured with clear sections ('Use when', 'Limitations', 'Alternatives') and the core purpose is front-loaded in the first sentence. Every sentence adds either usage guidance, behavioral context, or routing information, with no filler or repetition of schema details.

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

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

For a read-only query tool with an output schema present, the description covers purpose, selection criteria, limitations, error-reporting expectations, and alternatives. It is complete enough for an agent to invoke it correctly, including edge cases like empty errors and per-block rate changes, without needing additional context.

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

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

Schema coverage is 100%, so each parameter (assets, chain_id, protocol) is already documented with type, defaults, and constraints. The description adds context about per-asset snapshots and protocol-specific yield comparisons, but it does not materially extend the parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Get'), a precise resource ('on-chain lending supply/borrow APYs'), and explicit scope ('Aave v3 reserves and Compound v3 markets on Ethereum or Base'). It distinguishes this tool from get_yield_rates by naming it directly, so an agent can tell them apart without opening schemas.

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 'Use when' section gives explicit conditions ('protocol-specific lending-rate questions... Prefer over get_yield_rates when protocols are known'), provides a fallback rule ('use get_yield_rates for broad pool discovery'), and instructs the agent to report errors rather than falling back to web_search. Alternatives are also listed at the end, leaving no ambiguity about tool selection.

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 explicitly warns that this is a 'View-only scan... not a liquidation simulation or guarantee', discloses that Compound v3 only exposes a boolean flag, and notes that duplicate addresses are silently removed. It also reveals per-protocol failure isolation and hardcoded market addresses, which are material behavioral details an agent could not infer from annotations or schema.

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

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

The description is organized into clear labeled sections (summary, use when, limitations, alternatives) with no filler sentences. The core capability is front-loaded, and every subsequent sentence adds decision-relevant information, though there is minor repetition between the 'Use when' and 'Alternatives' sections.

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 tool with output schema and readOnly annotation, the description covers all necessary selection and invocation context: exact protocols/chains, batch size, aggregate output, sibling routing, and important limitations. Nothing critical is missing for an agent to decide whether and how to call this tool.

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

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

Schema description coverage is 100%, so the description need not repeat parameter details. It does restate the 'Ethereum or Base' chain choices and the 50-wallet/duplicate-removal constraints already present in the schema, but adds no new parameter-level detail such as address format or default-chain behavior beyond what the schema states.

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 opening sentence names a specific verb ('Assess'), a precise resource ('DeFi liquidation risk'), and scoping constraints ('up to 50 wallets', 'Aave v3 and Compound v3 on Ethereum or Base'). The description also enumerates concrete outputs (health factor, tiered risk classification, overall_tier), making it immediately distinguishable from portfolio or position tools.

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

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

The 'Use when' section gives an explicit condition ('multi-wallet batch risk assessment (2+ wallets)') and names the correct alternative for single-wallet analysis (get_defi_positions). It also provides a clear decision rule for assess_counterparty_risk, and repeats the route in the 'Alternatives' section.

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 this is third-party DeFiLlama analytics rather than on-chain truth, explains that upstream revenue failures surface as revenue_error_type, and warns that null economic fields are data gaps to never fabricate. It also describes batch-versus-single response differences, adding 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 well-structured and front-loaded: capability, usage guidance, limitations, alternatives. Every sentence carries useful information, and the use of short labeled sections makes the guidance easy to scan without 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 absence of an output schema, the description sufficiently explains what the tool returns: current TVL, historical series, fees/revenue, per-chain breakdown, and batch versus single response shapes. It also covers protocol slug format, alias behavior, and data-quality caveats, so an agent has enough context to 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%, but the description goes further by explaining the protocols=[...] batch mode, the compact batch response versus detailed single-protocol response, the meaning of include_historical and days, and the auto-correction of common aliases. This materially helps an agent choose and populate parameters correctly.

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 action and resource: 'Get Total Value Locked for one or many DeFi protocols from DeFiLlama' and enumerates concrete outputs like current USD TVL, 7/30-day change, fees, revenue, and per-chain breakdown. It also distinguishes itself from siblings by framing the tool for 'protocol-level economic questions' rather than ecosystem-level chain comparisons.

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 'Use when' section explicitly states when to use this tool, when to batch, when to set include_historical=true, and when to choose get_chain_metrics instead. The 'Alternatives' line further reinforces routing by naming related sibling tools.

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

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

Annotations only declare readOnlyHint=true, but the description adds extensive behavioral context beyond that: the audit is block-accurate, flags unlimited approvals by risk level, covers only tracked assets/curated spenders, does not inspect NFT or Permit2 approvals, and uses an error field to mark incomplete results rather than returning a clean bill of health. No contradiction with the readOnly annotation 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 denser than necessary and has slight redundancy ('block-accurate' appears twice, and 'use get_wallet_approvals instead' appears in both the Use-when and Alternatives sections). However, the labeled sections — Use when, Limitations, Alternatives — make it scannable and every sentence adds useful selection or behavioral detail.

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, the description covers what the tool audits, when to use it, what it misses, and how errors are signaled, while the output schema handles return-value structure. All parameter meanings and defaults are available in the schema, and the limitations are explicit. An agent has everything needed to invoke it correctly.

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

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

The schema already documents all four parameters (100% coverage), and the description goes further by adding useful semantics: curated spender names, the risk-level classification, max allowances of 50 tokens and 20 spenders, and the exclusion of untracked tokens/custom spenders. This materially helps an agent choose correct values beyond the raw 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 opens with a precise verb+resource: 'block-accurate audit of ERC-20 allowances for a wallet across curated DeFi spenders.' It names the exact protocols, chains, and risk classification behavior, and explicitly contrasts itself with the sibling get_wallet_approvals, so an agent can distinguish it without opening schemas.

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?

It gives concrete triggers ('Use before swaps or after security incidents'), a direct 'Use when' statement, and an explicit alternative: 'For broad all-chain spender discovery... use get_wallet_approvals instead.' The 'Alternatives' section reinforces routing with assess_counterparty_risk. This leaves no ambiguity about when to select this tool.

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 safety, and the description goes beyond it by disclosing the data source (CoinGecko spot data), the point-in-time nature, the fact that it is not an executable swap quote, and the resolution behavior for unknown symbols and bare 0x addresses. It stops short of a 5 because it omits rate-limit or freshness disclosures, but it adds substantial behavioral context the annotation alone would not provide.

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 organized into clearly labeled sections — overview, Use when, Limitations, Alternatives — and every sentence carries decision-relevant information. The core purpose is front-loaded, and the scoping/exclusion guidance is compact and immediately actionable. Length is justified by the volume of distinct behavioral constraints conveyed.

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 two-parameter tool with a rich output schema and a readOnlyHint annotation, the description covers all an agent needs to call it correctly: what it returns, accepted inputs, batch limits, when to prefer siblings, when not to call, and known failure modes (unresolvable addresses). The existence of an output schema means return-value documentation is not the description's job, and nothing essential 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it reveals that full names are accepted (schema only says 'symbols or CoinGecko IDs'), that unknown symbols resolve automatically, and that batch size caps at 50. The vs_currency parameter is also implicitly disambiguated by the 'Reuse price_usd/value_usd' guidance. These additions lift it above the bare 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 opens with a specific verb-resource pair — 'Get current price, 24h change, market cap, FDV, and volume for one or more crypto tokens' — and explicitly names sibling alternatives (get_token_price_historical, get_wallet_portfolio, get_dex_quote). It also states the accepted input forms (tickers, full names, CoinGecko IDs) and batch capacity, leaving no ambiguity about what the tool is and is not.

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 'Use when' section gives explicit positive conditions ('spot pricing of named tokens — including batched multi-token queries') and explicit exclusions ('Do not call for tokens whose price get_wallet_portfolio already returned, or for address-only unknown tokens'). It also routes historical needs to get_token_price_historical and lists an Alternatives section — exactly the when/when-not/alternative guidance an agent needs.

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 annotations include readOnlyHint=true, so the safety profile is already known. The description adds value beyond that by disclosing the 1–365 day window, daily downsampling granularity, CoinGecko coverage limitation, and the partial dca_baseline_90d caveat. It stops short of describing error conditions (e.g., unknown token symbols), which keeps it from a 5.

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 well-structured with clear sections (output summary, use-when, limitations, alternatives) and front-loads the key capability. It is slightly longer than strictly necessary — the use-when section partly repeats the opening paragraph — but every sentence earns its place, and the repetition is pedagogically useful.

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 100% schema coverage, the output schema, and the readOnly annotation, the description covers the remaining semantic ground: when to prefer this tool, what its limits are, and how to avoid misusing the partial DCA baseline. A fully complete description would also mention handling of invalid token symbols or the exact meaning of 'downsampled', but these are minor given the rich 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 coverage is 100%, so per the rubric baseline is 3. The description earns an extra point by explaining when stats_only matters and by adding the usage semantics for the days parameter (1=5-min, 2-90=hourly, 91+=daily) — though that granularity note actually lives in the schema, the description's guidance on stats_only and the DCA baseline caveat adds meaning 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 names the specific resource (historical crypto prices), the action (get), and enumerates the concrete outputs (period stats, daily series, high_30d, std_30d, dca_baseline_90d). It explicitly contrasts with get_token_price and web_search, so an agent can distinguish this tool from its siblings without opening schemas.

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 when-to-use guidance ('time-comparative financial questions — month-over-month, YTD, volatility, or DCA baselines'), a preference rule ('Prefer over web_search'), and a performance tip ('Pass stats_only=true when the daily series is unnecessary'). It also warns against re-deriving stats with calculate, naming the alternative tool directly.

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=true annotation already covers the safety profile, lowering the burden. The description builds on it with genuinely useful behavioral notes: one transaction per call, pending transactions may not resolve yet, and calldata is returned bounded rather than decoded. No contradiction with the annotation — 'Get details' is consistent with a read-only operation.

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

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

The description is well-organized into Use when / Limitations / Alternatives sections, and the core function is front-loaded in the first sentence. It is slightly repetitive (decode_transaction is cited three times), but each section earns its place with distinct information rather than 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?

An output schema exists, so return values needn't be restated. With 2 params (one required, 100% schema coverage), a read-only annotation, and a description covering scope, limitations, and alternatives, nothing essential for correct invocation is missing. It is complete for a moderately complex lookup 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%, so the schema already documents both tx_hash (0x… hash) and chain_id (1=Ethereum, 8453=Base) with defaults. The description reiterates the Ethereum/Base scope and hash-based lookup but adds only marginal parameter detail beyond the schema. Baseline 3 is appropriate since the schema carries the parameter documentation.

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

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

The description states a specific verb + resource ('Get details and receipt for one Ethereum or Base transaction by hash') and enumerates concrete outputs (bounded calldata, normalized event logs, transaction index, effective gas price). It explicitly disambiguates from siblings by naming decode_transaction and get_wallet_history as different tools, so an agent can select it without opening schemas.

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?

An explicit 'Use when' section states the exact triggering condition (verifying one known transaction's status/outcome) and gives direct alternatives: decode_transaction for calldata meaning, get_wallet_history for wallet-wide activity, and get_block in the Alternatives list. This is above-and-beyond guidance with no 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 only provide readOnlyHint: true, so the description carries the burden of behavioral disclosure. It adds valuable context: results are third-party analytics that may be stale, it covers only token approvals (not NFT or Permit2), and each chain consumes a separate billable provider call. No contradiction with annotations; it enriches the safety profile beyond the bare read-only hint.

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 structured with clear sections (purpose, use-when, limitations, alternatives) and is front-loaded with the primary purpose. Every sentence earns its place; no filler. Length is appropriate for the tool's complexity and the need to differentiate from a sibling.

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 an output schema exists (so return format need not be detailed), the description covers the essential aspects: what it inspects, what it returns (discovered spenders, exposure, protocol attribution, flags), limitations (staleness, scope, billable calls), and alternatives. Nothing an agent needs to decide and invoke correctly 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 coverage is 100% with descriptive parameter titles and examples, so the baseline is 3. The description adds usage-level semantics by noting 'Call once per chain' and implying the need for multiple calls for cross-chain screening, which clarifies the chain_id's role. It also frames wallet_address as an EVM address, matching the schema. This modest addition justifies a 4.

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

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

The description opens with a specific verb-resource pair: 'Inspect a wallet's current ERC-20 token authorization exposure on one DeBank-supported chain.' It clearly distinguishes from the sibling tool get_token_approvals by stating it is broader than that curated tool. The purpose is unambiguous and immediately actionable.

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 states when to use this tool ('when broad spender discovery or cross-chain security screening is needed') and when not to ('Use get_token_approvals for a free, block-accurate Ethereum or Base scan'). It also instructs to call once per chain because DeBank requires a chain_id, covering both usage context and constraints.

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 provide readOnlyHint=true, and the description goes well beyond that by disclosing the 20-entry per call limit, potential staleness of data, and semantic limitations around execution prices and transfer semantics. It also explains the cursor-based pagination behavior ('Use the returned next_cursor as start_time to page backward'), which is not visible 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 well-structured with distinct sections for purpose, usage, limitations, and alternatives. It is front-loaded with the core action and every sentence carries useful information; even the alternative references are justified by giving selection criteria.

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 moderate complexity, 100% schema coverage, output schema presence, and a read-only annotation, the description is complete. It covers what the tool does, when to use it, its limitations, pagination mechanics, and alternatives, so an agent has enough context to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context by linking the start_time parameter to the returned next_cursor and clarifying page_count's maximum, which helps an agent use pagination correctly. This goes slightly beyond the schema's own parameter descriptions.

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

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

The description states a specific verb ('Get one page of decoded transaction history') with a clear resource ('EVM wallet across DeBank-supported chains') and scope (send, receive, approval categories). It also names sibling alternatives, so an agent can distinguish it from get_transaction and decode_transaction without opening their schemas.

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 includes an explicit 'Use when' section covering wallet activity discovery, protocol interaction history, exchange exposure, and gas analysis责任人. It also provides explicit routing guidance: use get_transaction or decode_transaction when a known transaction needs block-level details, and clarifies the tool is not a complete ledger or PnL engine.

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 declare readOnlyHint=true, so the description carries the burden of behavioral disclosure. It adds useful detail beyond the schema: results are sorted by USD value, limited to 20 holdings, include native ETH, and are restricted to a fixed asset set. This goes beyond what annotations provide, though it could still be more explicit about response 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 organized into useful sections (Use when, Limitations, Alternatives) and front-loads the core action, but it contains redundancy: the native ETH redundancy warning and the 20-holding limit are each stated twice. Tightening those repetitions would make it more 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?

For a two-parameter read-only portfolio tool with a full input schema and output schema, this description is complete. It covers when to use it, how to use it across chains, what it does and does not capture, and how it relates to sibling tools, leaving no critical gap for 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds contextual color about Ethereum/Base and native ETH inclusion, but does not fundamentally expand on the schema's parameter meanings. A score of 3 is appropriate when the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Get aggregated token holdings with USD values for a wallet address.' It also adds concrete scope details (chains, asset types, sorting, cap of 20) that clearly distinguish this tool from siblings like get_eth_balance 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?

The description includes an explicit 'Use when' section, states the per-chain calling pattern for cross-chain comparisons, and lists alternatives. It also communicates when the tool is insufficient via limitations like 'Tracks a fixed set of major assets per chain, not arbitrary tokens.'

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

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

The description goes well beyond the readOnlyHint annotation by disclosing that data is third-party analytics, may be stale, may have long refresh delays, is EVM-wallet oriented, and does not prove current liquidation or execution state. It also transparently notes that include_token_balances triggers a separate billable provider request. There is no contradiction with the readOnlyHint 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 longer than average, but it is highly structured with clear sections: core capability, use cases, limitations, and alternatives. Every section earns its place, and the most important scoping differentiators are front-loaded. No redundant or filler sentences appear.

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, four parameters, many sibling tools, and an existing output schema, the description is complete. It covers what the tool returns, when to use it, when to avoid it, parameter consequences, limitations, and alternatives. Nothing needed for correct invocation 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?

Though the schema descriptions cover all four parameters, the tool description adds meaningful behavioral semantics: include_token_balances=true returns DeBank's complete cross-chain token list, while include_token_lists=false gives a compact balance/debt summary without nested tokens. It also clarifies that token lists only change response detail while token balances adds a billable request, which an agent needs to make informed decisions.

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 names a specific verb ('Get') and resource ('a wallet's DeFi positions across all DeBank-supported chains and protocols'), and specifies what is returned: protocol-level positions, asset/debt/net USD values, token lists, aggregate exposure, and all-chain net worth. It also explicitly differentiates from the sibling get_defi_positions by noting this tool covers substantially more protocols and chains.

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?

It has a dedicated 'Use when' section listing concrete use cases: broad wallet discovery, portfolio allocation, protocol exposure, and cross-chain position questions. It also explains when to toggle include_token_balances and include_token_lists, and explicitly directs users to get_defi_positions for block-accurate Aave/Compound/Uniswap/Lido snapshots. This is exemplary 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 only provide readOnlyHint=true; the description adds substantial behavioral context beyond that: third-party DeFiLlama analytics, a hard 50-pool cap, a client-side filtering caveat for the symbol field, and a warning that reward APY is reward-dependent and spot APY should not be presented as durable. This meaningfully exceeds what the annotation conveys.

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 organized into labeled sections (main purpose, Use when, Limitations, Alternatives) that make it scannable and front-loaded. Each sentence earns its place: scope, invocation guidance, caveats, and routing are all distinct and non-redundant, and nothing is wasted.

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 tool with 8 optional parameters, an output schema, and minimal annotations, the description covers purpose, filtering strategy, output limits, symbol-field semantics, and yield-durability caveats. The output schema covers return values, and no material gap remains for an agent to call this correctly.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented in the schema; the description adds only marginal parameter-level value (e.g., sorting behavior and the stable_only ranking emphasis). Per the baseline rule for high coverage, 3 is appropriate — the schema carries the semantic load.

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?

Uses a specific verb+resource ('Get DeFi yield pool rates from DeFiLlama') and precisely enumerates what is returned (APY-sorted pools with TVL, base/reward APY, 7d/30d mean APY) and how results can be filtered. It also names get_lending_rates as the protocol-specific sibling, so an agent can immediately distinguish this tool from related ones without opening schemas.

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 'Use when' section explicitly states the tool is for broad cross-protocol yield discovery, instructs calling at most once per request with filters applied in a single call, and directs protocol-specific questions to get_lending_rates. The Limitations and Alternatives sections reinforce routing, leaving no ambiguity about when to use this tool vs siblings.

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 annotations provide readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it blocks private/cloud-metadata addresses, re-validates redirect hops, returns cleaned text rather than raw HTML or binary, and warns about JS-heavy pages. This gives the agent a strong safety and expectations model.

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 well-structured with clear sections for purpose, use cases, limitations, and alternatives. Every sentence adds value, with no filler or repetition, and the most important scope 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?

For a tool with an output schema, full input schema descriptions, and a readOnly annotation, the description covers everything an agent needs: what it returns, when to use it, safety restrictions, and behavioral limitations. Nothing critical 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%, so the input schema already explains both 'url' and 'max_chars'. The description does not add parameter-level details, but it also doesn't need to; the schema carries the burden and 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 names a specific verb ('Fetch'), a specific resource ('web page'), and the exact deliverable ('main text content, cleaned of markup'). It also distinguishes itself from sibling tools like web_search and get_token_price by framing when URL-based retrieval is appropriate.

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 states when to use the tool ('known URL's content is needed and structured tools cannot answer') and provides alternatives with routing guidance ('prefer web_search' for general lookup, 'get_token_price' for token prices). This is clear, actionable, and leaves little to inference.

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 discloses behavior beyond the readOnlyHint annotation: it explicitly rejects state-changing functions, supports historical reads via block_identifier, and explains caller_address supplies msg.sender without signing. It also states network constraints (Ethereum mainnet and Base) and bounded RPC timeout/retry, giving a full safety and operational picture.

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 well-structured with distinct sections (functionality, usage, limitations, alternatives) and is front-loaded with the core action. Every sentence earns its place; there is no fluff or redundancy. It is appropriately sized for an 8-parameter tool.

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

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

Given the tool's complexity and the presence of an output schema and annotations, the description covers purpose, usage, limitations, and alternatives comprehensively. It specifies supported networks, rejected function types, and the non-transactional nature of caller_address. Nothing essential for correct invocation 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%, so all parameters are already documented. The description adds context about using block_identifier for historical reads and caller_address for msg.sender-dependent views, which mirrors schema descriptions. It does not introduce new semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb ('Call'), a clear resource ('any view/pure function on a smart contract'), and the output ('decoded result'). It explicitly distinguishes itself from higher-level tools by naming purpose-built alternatives, so an agent can immediately tell when this low-level tool is appropriate.

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 an explicit 'Use when' condition (protocol questions not covered by higher-level tools) and instructs to prefer purpose-built tools (get_defi_positions, get_lending_rates) for supported protocols. It also lists limitations (network, ABI requirement, rejected function types) and names alternatives, leaving no ambiguity about when to invoke this tool.

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 contradicts the annotations: it says to 'record', 'persist', and 'store' a prediction document, implying a state-changing write operation, while annotations declare readOnlyHint=true. This is a serious inconsistency that would mislead an agent about the tool's side effects. The added notes about no validation and no deduplication are useful but cannot overcome the contradiction.

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 well-structured with explicit sections and front-loaded purpose. It is slightly repetitive ('Call once...' and 'Call exactly once') but every section adds usable guidance. Overall it is concise for the amount of context it provides.

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

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

For a one-parameter tool with a rich schema and output schema, the description covers usage, limitations, and parameter semantics well. However, the contradiction with the readOnlyHint annotation creates unresolved confusion about whether the operation mutates state, and the description does not clarify the discrepancy. This prevents the definition from being fully complete.

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

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

Schema coverage is 100%, so the schema already documents the single parameter. The description adds meaningful nuance beyond the schema: the prediction should be the exact machine-readable document, and the human-readable report is deliberately separate. This helps the agent understand what value to place in the parameter.

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 ('record'), a specific resource ('complete structured prediction document'), and a clear purpose ('for downstream evaluation'). It also separates this tool from caller-facing marketplace tools and names a sibling alternative, so an agent can distinguish it from the large sibling list.

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 when-to-use guidance ('at the end of a scheduled analysis run'), the exact call pattern ('exactly once', 'never partially or repeatedly'), and a stated alternative ('get_datetime'). It also clarifies the tool's intended internal role.

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 the operation is safe, and the description adds genuinely useful behavioral context: mainnet-only support, reverse records being optional, and avatar text records being returned only when available. This goes beyond what annotations provide.

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 well-structured with clear 'Use when', 'Limitations', and 'Alternatives' sections, and the core purpose is front-loaded. Every sentence adds value, and the exclusion advice is placed immediately after the purpose.

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

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

With a single required parameter, a complete schema description, a read-only annotation, and an output schema, the description covers the important edge cases: mainnet-only behavior, optional reverse records, and the directive to skip resolution when unnecessary. Nothing essential 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%, and the schema already explains that `name` accepts either an ENS name or an Ethereum address for reverse lookup. The description does not add parameter-level semantics beyond the schema except for noting the avatar text record, which is return-value context rather than parameter meaning.

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

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

The description states a clear verb and resource: resolving an ENS name to an Ethereum address and reverse-resolving an address to its primary ENS name. It adds scope ('Mainnet only') and a concrete example ('vitalik.eth'), making the tool's purpose unmistakable and distinct from the sibling 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?

It gives an explicit usage rule: use only when no 0x address is available, and avoid resolution entirely when a 0x address is already present. It also names alternatives and lists limitations, which is strong when-to-use 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 this is a heuristic economic assessment based on DeFiLlama and CoinGecko, and explicitly lists what it does not audit. It also tells the agent what kind of output to expect (a branched verdict with supporting evidence), which is rich behavioral context that the annotation alone does not provide.

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 well-structured with front-loaded purpose, followed by Use when, Limitations, and Alternatives. Every sentence adds distinct value, and the section headers make the information easy to scan for an agent. There is no repetition of schema or annotation details.

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

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

Given one parameter, a fully descriptive schema, an output schema, and readOnlyHint annotation, the description supplies the remaining operational context: when to delegate the check, what the verdict branches are, what evidence sources back it, and what it cannot guarantee. Nothing essential is missing for an agent to decide whether and how to invoke this tool.

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

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

The input schema already fully describes pool_id as a DeFiLlama yield pool UUID with an example, and schema_description_coverage is 100%. The description adds some contextual framing that pool_id refers to a DeFi yield pool or staking opportunity, but it does not substantially extend the parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and outcome ('Return a decision-ready yield-opportunity verdict') and names the exact decision branches: sustainable, caution, unsustainable, or insufficient_data. It clearly distinguishes this from sibling data-fetching tools like get_yield_rates and get_protocol_tvl by framing it as an independent decision check rather than a raw data lookup.

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 'Use when' section gives an explicit trigger: before deploying capital when an independent sustainability and liquidity decision is needed. The 'Alternatives' section names the relevant sibling tools, giving the agent concrete routing options, and the 'Limitations' section implicitly tells the agent what this tool should not be used for, such as auditing smart contract bytecode or governance.

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, and the description adds beyond this by disclosing that the tool returns web snippets rather than raw page bodies, that results depend on Tavily coverage, that advanced depth increases cost, and that it should not replace on-chain tools. These behavioral details are not redundant with 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 organized into clear purpose, use-when, limitations, and alternatives paragraphs, allowing an agent to parse key decisions quickly. Every sentence earns its place, and the most important information about what the tool does 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?

For a simple search tool with an output schema and a read-only annotation, the description covers all relevant decision factors: purpose, use cases, limitations, cost implications, and alternatives. Nothing needed to select or invoke the tool correctly 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%, so the schema already fully documents all four parameters. The description adds a marginal selection rule for using search_depth='advanced' on complex queries and topic='news' or 'finance' for headlines or market information, but this largely restates the schema's own descriptions, so no significant semantic value is added.

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?

States a specific verb and resource: real-time web search via Tavily for current events, fact-checking, and research. It clearly differentiates from sibling on-chain and utility tools by emphasizing external, current information, and explicitly says it is not a substitute for 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?

Provides an explicit 'Use when' section naming the conditions for selection: current, external, factual information not available from on-chain or local data, with concrete examples like news, prices, documentation, and fact-checking. It also names alternatives (get_token_price, http_fetch) and states limitations, giving the agent clear routing guidance.

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