Agent Margin Router

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

Even though readOnlyHint=true is already present, the description adds valuable behavioral context: the default ERC-20 set is stablecoins + WETH and can be overridden, the default chain is Base, and there is a payment/quota model (x402 USDC/USDT on Base, 3 free calls per wallet). These are exactly the kind of non-obvious behaviors an agent needs to invoke 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 compact yet information-dense: it front-loads the core purpose, then lists supported data, then chains, then payment terms. Every clause contributes a capability or constraint; there is no filler or repetition of schema fields.

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 6 parameters, multiple chains, an output schema, and a payment model, the description covers the conceptual return scope, chain coverage, default token behavior, and access/payment rules. The output schema handles detailed return shape, so nothing an agent needs 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 coverage is 100%, so the baseline is 3, and the description adds meaningful nuance beyond the schema: token_contracts defaults to USDC/USDT/DAI/WETH, chain defaults to Base, and passing a wallet address unlocks the free tier. This helps agents make smarter parameter choices without opening 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 gives a specific resource (wallet snapshot) and a full inventory of what it bundles, so an agent can tell it apart from more focused alternatives.

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 explains that this tool replaces 5+ RPC calls, which clearly indicates when an agent should prefer it over fetching individual balances, gas, and token prices. It also tells the agent which chains are supported and how payment/free-call access works. It does not explicitly name sibling exclusions or say 'when not to use this', but the intended context is clear.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, signaling a safe, read-only operation. The description adds value by disclosing the payment model ('Pay per call with USDC or USDT on Base via x402. 3 free calls per wallet'), which is not covered by annotations. It does not mention rate limits or response size, but given the annotations, this is a minor gap.

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

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

The description is concise and front-loads the core functionality ('Search arXiv preprints') followed by the return fields and options. The payment note is placed at the end, which is acceptable. Slightly more could be trimmed, but it is well-structured and efficient.

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

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

The tool has an output schema (which presumably details return format) and 100% schema coverage, so the description need not explain return values. It covers the main purpose, payment, and optional filters. The description is complete enough for an agent to know how to call it, including the free tier and payment requirement, so the slight lack of rate limit info is not critical.

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 description mentions sorting and filtering by category, but the input schema already has detailed descriptions for all 7 parameters, covering the same information (e.g., query='Free-text search query', wallet='Unlocks the free tier'). The description adds a little context by noting the free tier for wallet, but it largely reiterates the schema. With 100% schema coverage, the baseline is 3, and the description does not significantly exceed 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 clearly states the tool searches arXiv preprints and lists the specific returned fields (id, title, authors, abstract, categories, dates, PDF links), which is a specific verb+resource. It also mentions sorting and filtering options, making it easy to distinguish from sibling tools like 'news_search' or 'web_search' which serve different content types.

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 the tool is for searching arXiv preprints and mentions optional filtering by category and sorting. It does not explicitly contrast with siblings, but the specific domain (arXiv) and the detailed output fields give clear context on when to use it. The payment note also clarifies the usage context, though it is more about cost than 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?

The annotations already declare readOnlyHint=true, and the description does not contradict that; it adds behavioral details about charging commission and payment via x402. It also discloses the free tier and the lack of an API key requirement, which are not captured by annotations. This enhances the agent's understanding of the tool's behavior beyond the structured metadata.

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, leading with the core function, then listing response fields and chains, and ending with payment and free-tier details. Each sentence adds value without redundancy. 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?

The description covers the tool's purpose, the data it returns (breakdown fields), the supported chains, and the payment/free-tier mechanism. Given the presence of an output schema and annotations that already cover read-only behavior, the description is sufficiently complete for an agent to call the tool correctly. Minor gaps like rate limits or error handling are not critical given the 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?

The input schema provides full descriptions for all four parameters (chain, wallet, api_key, x_payment), covering defaults, options, and payment details. The description repeats some of this (e.g., payment via x402) but does not add new meaning beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate; the description offers marginal additional context.

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: it queries multiple gas-price sources in parallel and returns the cheapest quote while charging a commission. It distinguishes itself from siblings like gas_fees by focusing on best-price comparison and commission. The specific chains and response fields are enumerated, making the purpose unambiguous.

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

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

The description implies when to use the tool (when you need the best gas price across multiple sources) but does not explicitly contrast it with alternatives like gas_fees or token_price. It does mention usage constraints such as 'No API key' and '3 free calls per wallet,' but these are access conditions, not usage scenarios. Thus, usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint and openWorldHint, lowering the burden on the description. The description adds useful behavioral context: data source (Blockscout), supported chains, the pay-per-call model via x402, and the 3-free-calls per wallet. No contradiction with annotations 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?

Two compact sentences capture the core purpose and the payment model. The first sentence front-loads the metadata categories and supported chains; the second adds essential usage cost information. There is no filler or redundant restatement.

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 rich schema coverage, annotations, and an output schema present, the description does not need to explain return values. It provides enough context around chains, metadata scope, and payment requirements for an agent to call the tool correctly. Minor gaps such as explicit error/cost edge cases are acceptable given the annotations.

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

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

Schema description coverage is 100%, so the schema already documents each parameter, including the wallet unlock behavior and the x_payment payload format. The description reinforces the payment context but does not add significant new parameter-level 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 clearly identifies the tool's resource ('Smart-contract metadata from Blockscout') and lists concrete output categories like verification status, compiler, proxy/implementation, and token details. It does not use an explicit verb like 'get' or 'fetch', but the domain and supported chains are specific enough to distinguish it from sibling tools such as erc20_balance or tx_status.

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

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

The description implies the use case: query contract metadata for a given address on one of four chains. However, it does not explicitly state when to prefer this tool over alternatives, such as erc20_balance or token_price, nor does it define exclusions. The payment and free-tier notes provide context but not alternative routing.

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 and openWorldHint, so the description adds substantial behavioral context: payment per call via x402, free-tier limits per wallet, data source fallback behavior, and the period summary. It does not detail rate limits or error behavior, but what is disclosed goes well beyond the 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 a single sentence that packs the essential facts—data scope, intervals, limit, summary, payment model, and free tier—without redundancy. It is front-loaded with the core purpose and keeps every clause informative.

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 description correctly avoids repeating return values and instead covers data source, supported intervals, candle limits, payment method, and free calls. It leaves some room for ambiguity around 'major' pairs and exact pricing, but overall an agent has sufficient 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?

The input schema covers all 7 parameters with descriptions, so the baseline is 3. The tool description adds high-level context like 'any major crypto pair' and payment behavior, but it does not clarify individual parameters beyond what the schema already provides. This is acceptable given complete schema coverage.

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

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

The description clearly identifies the resource as 'Historical OHLCV candles' for crypto pairs Brief, names data sources (Binance, Coinbase fallback), and specifies intervals, limit, and summary output. This differentiates it from current-price siblings like token_price or dex_price by emphasizing the historical candle-based nature.

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

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

The description clearly states this is for historical OHLCV data, which sets appropriate context for when to use it, but it does not explicitly mention alternatives or when not to use it. The 'historical' qualifier and candles-focused phrasing give enough context to distinguish from real-time price tools, though explicit exclusions are absent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which align with a read-only, dynamic-rate tool. The description adds useful behavior beyond annotations: ECB reference rates, payment requirement, free tier, and rate date. It doesn't contradict annotations.

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

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

Two sentences pack the core function and payment model efficiently, with the core conversion action front-loaded. No filler or repetition.

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

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

The tool has an output schema (present but not shown) and a moderate number of parameters. The description covers the essential payment requirement and rate source. It doesn't mention update frequency or rate limits beyond the free tier, but these are not critical for invocation.

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

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

Schema coverage is 100%, so all parameters are already documented. The description reinforces the meaning of amount, source, and targets but adds no extra syntax or format details 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 clearly states the tool converts fiat currencies using ECB reference rates, supports multiple target currencies, and returns rates and converted amounts. It distinguishes itself from crypto-focused siblings like token_price and dex_price by specifying fiat conversion.

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 indicates fiat conversion and mentions the payment model (pay per call, 3 free calls per wallet). While it doesn't explicitly say when not to use it vs alternatives, the fiat focus and sibling list make the context clear.

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

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

The annotations already declare readOnlyHint=true, so the description does not need to restate that this is a read operation. It adds meaningful beyond-annotation behavior: pay-per-call via x402 on Base, payment in USDC/USDT, and a 3-free-calls-per-wallet limit. No contradiction with annotations 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 compact and front-loaded with the core purpose, and the payment/free-call sentence earns its place. The first sentence is dense with parenthetical metric lists, which is efficient but slightly hard to parse; still, there is 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?

Given the output schema covers return values and annotations cover read-only safety, the description supplies the remaining essential context: protocol vs. chain modes, the expected metric set, and the billing/free-tier model. It is sufficient for correct invocation, though a brief usage example or explicit alternative routing would make it 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 description coverage is 100%, so all five parameters are already explained in the schema. The description adds domain context such as 'DefiLlama slug' and payment/free-tier details, but it does not substantially clarify parameter semantics beyond what the schema already provides.

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

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

The description states a specific data resource: total value locked for either a DefiLlama protocol slug or a chain, and enumerates the exact metrics returned (TVL, changes, market cap, mcap/TVL, per-chain TVL, protocol counts). This clearly differentiates it from siblings like defi_yields or token_price by focusing on TVL and associated valuation metrics.

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

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

The description explains the two input modes (protocol vs. chain) but gives no guidance on when to choose this tool over alternatives such as defi_yields, token_price, or crypto_ohlcv. There are no exclusions, prerequisites, or explicit 'use this when...' statements, leaving tool selection 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 a billing model (USDC/USDT on Base via x402) and a free-tier quota (3 free calls per wallet), which go beyond the annotations. It also names the external data source (DefiLlama) and confirms the read-only nature via sorted output, with no contradiction to readOnlyHint/openWorldHint.

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?

Four short sentences each carry distinct information: data source and scope, filter and sort behavior, payment method, and free-tier quota. There is 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 a complete input schema and an output schema present, the description adequately covers source, filtering, sorting, and the non-obvious payment/quota model. It does not explain return value structure, but that is covered by the output schema; only minor payment mechanics are left implicit.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a high-level filter list and sort order (by APY), but does not elaborate on individual parameters beyond what the schema already provides.

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

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

The description clearly identifies the resource ('DeFi pool yields'), the source ('DefiLlama'), and the key dimensions (APY, TVL, stablecoin flag). It distinguishes itself from sibling tools like defi_tvl by focusing on yields across chains/protocols with filter and sort behavior.

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

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

The description implies usage context by enumerating filter options and data scope, but it does not explicitly say when to choose this tool over defi_tvl, token_price, or other alternatives. No exclusions or alternative routing are provided.

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

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

Annotations already mark the tool as readOnly and openWorld, so the description only needs to add context. It usefully discloses the pay-per-call model ('Pay per call with USDC or USDT on Base via x402'), the 3-free-calls-per-wallet limit, and the data source (DexScreener), all of which exceed what the annotations declare.

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

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

The description is a single dense sentence that front-loads the core purpose, then adds chain scope, source, and payment model. Every clause earns its place; there is 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?

Given the rich output schema and fully described parameters, the description covers all necessary operational context: what data is returned, which chains are supported, how the token is identified, the data source, payment requirements, and free-tier behavior. No critical usage information is missing.

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

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

Input schema coverage is 100%, so the schema already documents all parameters well. The description reinforces the contract-address-or-symbol lookup mode and mentions payment/top-pairs, but it does not add detailed parameter-level semantics beyond what the schema provides. This matches the baseline for high schema coverage.

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

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

The description uses a specific verb ('Live DEX price') and clearly identifies the resource: on-chain token price, 24h change, volume, liquidity, and top liquidity pairs via DexScreener. It also distinguishes itself from CEX-focused tools by explicitly scoping to 'long-tail tokens not listed on CEXs' and naming supported 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 gives clear context for when to use the tool: to look up DEX prices for long-tail tokens by contract address or symbol on a defined set of chains. It does not explicitly name alternatives or exclusion conditions, but the DEX/long-tail framing strongly signals when this tool is appropriate over CEX price 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?

The annotations only declare readOnlyHint and openWorldHint, so the description carries the burden of disclosing payment requirements. It adds valuable behavioral context: calls are paid via USDC/USDT on Base with x402, and each wallet gets 3 free calls. This is meaningful 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?

Two sentences with no fluff. The core DNS-resolution capability is front-loaded, followed by the payment constraint and free-tier note. Every sentence 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?

With an output schema present and full parameter documentation, the description covers supported record types, transport, and payment behavior. The only notable gap is the lack of explicit pricing per call and no direct comparison with sibling tools like dns_whois, but overall the agent has enough 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%, so the schema already documents all parameters. The description mentions record types and free-tier limits, but those are already present in the schema's enum and wallet description. The description adds no significant parameter semantics beyond the schema.

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

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

The description clearly states a specific action ('Resolve any DNS record type'), lists the exact record types, and distinguishes itself via DNS-over-HTTPS and TTL/DNSSEC details. It is not a tautology, but it does not explicitly name or differentiate against dns_whois or domain_rdap.

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

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

The description provides clear context for when to use this tool: resolving DNS records over DNS-over-HTTPS. However, it does not explicitly state when to use an alternative like dns_whois or domain_rdap, so the guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to cover safety. It adds valuable behavioral context: payment via USDC/USDT on Base, 3 free calls per wallet, and the underlying protocols (DNS-over-HTTPS, RDAP). It does not disclose failure modes or rate limits, but the added payment and free-tier details go beyond the annotations.

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

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

Two sentences with no excessive detail. The first sentence lists capabilities, the second covers payment. Information is front-loaded and every word earns its place. There is no fluff or redundancy.

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

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

For a tool with 6 parameters, output schema, and annotations, the description covers the essential aspects: what it returns, payment requirements, and the free tier. It does not explicitly mention alternatives or error handling, but the output schema likely fills that gap. Given the high schema coverage and annotations, this is fairly complete, though a brief note on when to use this over dns_lookup/domain_rdap would make it perfect.

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 has a description. The tool description adds meaning by listing the DNS record types and explaining RDAP/WHOIS data, which clarifies the purpose of record_types and include_whois. It doesn't just repeat schema definitions; it provides the domain context that helps the agent decide on parameter values.

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

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

The description clearly states it provides DNS records (specific types listed) via DNS-over-HTTPS plus RDAP/WHOIS registration data (registrar, dates, status, nameservers, DNSSEC). This distinguishes it from sibling tools like dns_lookup and domain_rdap, which likely offer only one of these. The verb 'provide' and resource scope are explicit.

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

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

The description implies a combined DNS+WHOIS use case but does not explicitly state when to choose this over dns_lookup or domain_rdap. It does mention payment requirements (pay per call, free tier) which is relevant context. However, no exclusions or alternatives are named, so it relies on the agent inferring that this is the combined option.

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 the tool as read-only and open-world; the description adds useful operational context: it is a paid API (USDC/USDT on Base via x402) with 3 free calls per wallet. No behavioral contradictions with the annotations.

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

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

Two concise sentences: the first front-loads the data categories and use cases, and the second covers payment and free-tier mechanics. Every sentence earns its place with no redundancy.

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

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

For a single-required-parameter read-only lookup with a full output schema and complete schema coverage, the description covers purpose, use case, data fields, and payment/free-tier behavior. 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 all parameters are already documented in the schema. The description adds no per-parameter semantics beyond what the schema provides, 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 identifies the resource ('domain registration data') and the method ('via RDAP') and lists concrete fields such as registrar, status, nameservers, and DNSSEC. It is clear about what the tool does, but it does not explicitly distinguish it from sibling tools like dns_whois.

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 states clear use cases ('for availability checks and due diligence') and gives payment/free-tier conditions, giving an agent enough context to decide when to use it. It does not explicitly say when not to use it or which alternative to prefer.

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 (readOnlyHint=true, openWorldHint=true) already establish safety and external data context. The description adds valuable behavioral details beyond annotations: it discloses the payment requirement (Pay per call with USDC/USDT on Base via x402), the free tier (3 free calls per wallet), and the technical mechanism (DNS-over-HTTPS). These are critical for correct usage. No contradictions with annotations.

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

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

The description is a single, information-dense sentence that front-loads the core action and then lists specific checks and payment details. Every clause adds value; there is no filler or redundancy. Well-structured for quick parsing.

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 availability of an output schema and annotations, the description covers the essential aspects: what the tool does, the payment requirement, and the free tier. It does not mention error handling or failure outcomes for payment, but these are not strictly necessary given the output schema describes return values. The description is sufficiently complete for an agent 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 description coverage is 100%, so parameters are well documented. The description adds overall context (e.g., deliverability score and verdict) but does not provide additional detail on individual parameters beyond what the schema already offers. It does not explain how parameters interact once the payment flow is triggered, but the schema descriptions are sufficient. Baseline of 3 is appropriate.

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

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

The description clearly identifies the tool's purpose with a specific verb (Validate), a specific resource (email address), and enumerates concrete checks (RFC syntax, MX/A records, disposable detection, etc.). It clearly distinguishes from all sibling tools, none of which handle email validation. No ambiguity.

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

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

The description 'Validate an email address' provides clear context for when to use the tool, but it does not explicitly state when not to use it or mention alternatives. Given that no sibling tool overlaps with email validation, the context is sufficient for an agent to select it appropriately, though it lacks explicit exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a read-only operation with potential external interactions. The description adds crucial behavioral context: payment via USDC/USDT on Base through x402, a free tier of 3 calls per wallet, and the on-chain nature of the calls. This exceeds the annotation baseline and is not contradictory.

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

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

The description is two sentences, front-loaded with the core purpose. It efficiently communicates the main function and the payment/free-tier caveat without any redundant phrases. Every sentence adds value, and the structure is clean and scannable.

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

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

Given that an output schema exists, the description does not need to explain return values. It covers the essential operational context: what the tool does, the payment mechanism, and the free tier. It omits potential error handling or rate limits, but these are not critical for a typical agent call. Overall, it is complete enough for an agent to decide and invoke the tool correctly.

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

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

The input schema covers all 5 parameters with descriptions, so the schema itself provides the baseline. The description adds a bit of context by mentioning typical text records (url, com.twitter, avatar) and that the wallet unlocks the free tier, but these are already implied in the schema descriptions. No additional parameter-specific meaning is provided beyond the schema.

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

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

The description clearly states the verb 'Resolve' with the resource 'ENS name' and specifies the outputs: Ethereum address plus text records. It is specific enough to distinguish from sibling tools like dns_lookup or wallet_balance, even without explicit comparison. The mention of on-chain calls and payment adds functional clarity.

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

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

The description does not explicitly state when to use this tool versus alternatives or when not to use it. It implies usage by its name and function, but lacks exclusions or alternative routing. For example, it doesn't say 'use this for ENS resolution, not for DNS.' This is adequate but not explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful context: Multicall3 batching, supported chains, the x402 payment mechanism, and the 3-free-calls-per-wallet limit. There is no contradiction between the description and the annotations.

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

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

Two sentences are packed with high-signal information: return contents, token scope, multicall batching, supported chains, payment options, and free tier. The core purpose is front-loaded and no filler is present.

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 essential calling context: what is returned, how many tokens, which chains, and how to pay. Since an output schema exists, return-value details are handled structurally; the only slight gap is explicit when-to-use/alternative routing among the many balance- and price-related siblings.

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 documents all six parameters with 100% coverage, so the description does not need to compensate. It reinforces useful constraints like 1-20 contract addresses and one-wallet scope, but it does not clarify the distinction between 'wallet' and 'wallet_address' beyond what the schema already says.

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 ('Balances') and names the exact resource: up to 20 arbitrary ERC-20 tokens for one wallet, including raw and decimal-formatted balances, decimals, and symbols. Saying 'arbitrary ERC-20 tokens' and 'one wallet' clearly distinguishes it from sibling tools like wallet_balance or token_price.

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

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

The description clearly implies use for batched ERC-20 balance checks for a single wallet in one multicall round-trip, and it adds payment/free-tier context. It does not explicitly say when not to use it or name alternatives such as wallet_balance or token_price, so it stops just short of full 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds valuable behavioral context beyond annotations: it discloses the Apify (JS-rendered) with direct-fetch fallback behavior, the pay-per-call model with USDC/USDT on Base via x402, no API key/signup requirement, and the 3-free-calls-per-wallet limit. This is exactly the kind of context that helps an agent anticipate side effects (cost) and prerequisites.

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

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

Three sentences with zero waste. The core function is front-loaded, followed by the optional filter, then the rendering/fallback mechanism, then payment/free-tier details. Every sentence earns its place and no information is repeated from the schema.

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 is complete for a read-only extraction tool with an output schema present. It covers the core behavior, the optional filtering, the rendering mechanism, and the payment model. The only minor gap is that it doesn't describe the output format in detail, but the output schema exists and the description names the extracted fields. The payment/free-tier context is a strong addition that most tool descriptions lack.

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 6 parameters. The description adds meaning by explaining the `schema` parameter's effect ('keeps only the listed top-level keys') and the `wallet` parameter's role in unlocking the free tier. It doesn't repeat parameter names verbatim but adds behavioral context that the schema lacks. Baseline 3 is exceeded because the description clarifies the two most important parameters' semantics.

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

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

The description states a specific verb ('extract'), a specific resource ('clean page extraction from any public URL'), and enumerates the exact fields returned (title, meta description, main text, JSON-LD, language). It also distinguishes itself from siblings by mentioning the optional `schema` filter and the Apify/fallback mechanism. An agent can tell this apart from html_to_markdown, web_crawl, and url_status 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 clearly states when to use it: for clean page extraction from any public URL, with optional schema filtering. It doesn't explicitly name alternatives or exclusions (e.g., 'use html_to_markdown for raw HTML'), but the context is clear enough that an agent can infer the use case. The payment/free-tier info also helps the agent decide whether to call it.

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 openWorldHint=true, so the description doesn't need to restate those. It adds valuable behavioral context about payment requirements (USDC/USDT on Base via x402) and the 3 free calls per wallet, plus the external data source. This goes beyond annotations without contradicting 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?

Two sentences with zero waste: the first states the primary function and outputs, the second covers payment and free-tier details. Information is front-loaded and every word earns its place.

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

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

With an output schema present (not shown) and annotations covering the read-only nature, the description supplies the essential context: data source, payment method, free tier, and time range. Nothing an agent needs to correctly invoke this tool 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 (limit, wallet, api_key, x_payment) are already documented with descriptions. The tool description adds no additional parameter 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 the tool returns the daily Fear & Greed index (0-100) with classification, 1d/7d change, and up to 90 days of history from alternative.me. This specific resource and its outputs distinguish it from sibling market tools like crypto_ohlcv or token_price.

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

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

The description gives clear context that this is for crypto market sentiment, which is distinct from other market data tools. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral details beyond that: the pay-per-call model (USDC/USDT on Base via x402), the 3-free-calls-per-wallet rule, and the common-path fallback behavior. It does not mention rate limits or cancellation/reversibility, but the added cost and fallback disclosures go beyond the 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 exactly two sentences: the first front-loads the purpose and method, the second conveys payment terms. No filler or redundancy. Every sentence 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 tool's simplicity, the description covers the core discovery action, fallback behavior, and payment requirements. An output schema exists, so return values need not be described. It does not address edge cases like what happens when no feed is found, but that is likely covered by the output schema and is a minor gap for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already fully documents all parameters. The description's mention of the fallback path gives behavioral context for the 'url' parameter but does not add meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function with a specific action ('Find') and resource ('RSS/Atom feed URLs for a website'), and it explains the method (HTML link tags with a common-path fallback). This distinguishes it from sibling tools like rss_feed, which likely handles feed retrieval rather than discovery.

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

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

The description implies when to use the tool (when you need to locate feed URLs) and provides payment/free-tier context, but it does not explicitly name alternatives or state when not to use it. No exclusions are given, but the usage context is reasonably clear.

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

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

Annotations already mark the tool as read-only and open-world. The description adds meaningful operational context beyond those annotations: data source is public RPC nodes, no API key is required, calls are paid via x402 with USDC/USDT, and each wallet gets 3 free calls. It does not address cache/max-age behavior, but the schema covers the parameter.

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

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

The description is two dense sentences that front-load the core output, then add operational and billing essentials. There is no fluff or repetition, and every clause 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?

An output schema exists, so return-value details are covered separately. The description supplies the chains, fee tiers, transaction types, payment mechanism, and free-tier threshold, leaving no critical invocation context 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 all five parameters. The description adds chain and billing context but does not significantly deepen 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 clearly identifies the resource and outputs: live EIP-1559 gas fees across tiers and USD costs per transaction type for five chains. The domain is specific enough to distinguish it from sibling market/price tools, though it lacks an explicit verb like 'returns' or 'fetches'.

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 case is inferable from the gas-fee focus and listed transaction types, but the description gives no explicit when-to-use guidance, exclusions, or alternatives. An agent must infer that this is the tool for current gas fee estimates rather than, say, historical price data.

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

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

The description discloses several behavioral traits beyond the annotations: results are cached for 24 hours, the service is paid via USDC/USDT on Base through x402 with a free tier of 3 calls per wallet, and data comes from OpenStreetMap Nominatim under ODbL. These add significant context about cost, reliability, and licensing, which the annotations (readOnlyHint, openWorldHint) do not cover.

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

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

The description is two sentences long, with the core function front-loaded in the first sentence and additional operational details (caching, payment) in the second. Every phrase carries meaning, and there is no 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 tool has seven parameters, an output schema, and annotations for read-only/open-world behavior, the description covers the essential operational context: the core transformation, data source, caching, and payment model. It does not describe error handling or output structure, but the output schema addresses that. It is sufficiently complete for an agent to decide when and how to invoke it.

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

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

The input schema documents all seven parameters with descriptions and defaults, achieving 100% coverage. The description does not elaborate on any parameter specifics, and the operational details it mentions (caching, payment) are not parameter-related. Per the baseline for high schema coverage, a 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 states a specific verb ('Turn') and a clear resource ('a place name or address into coordinates, bounding box, address parts and OSM type') using OpenStreetMap Nominatim. It also names the data license (ODbL) and caching, making the function unambiguous. No sibling tool appears to offer geocoding, so it is clearly differentiated.

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

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

The description implies when to use it (when you need to convert a place name or address to coordinates) but does not explicitly mention alternatives or when-not-to-use cases. Since there are no competing geocoding tools among the siblings, the lack of explicit exclusion is acceptable, but it could be more explicit about the use case.

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 openWorldHint=true, establishing that the call is safe and side-effect-free. The description adds important behavioral context beyond annotations: it discloses the pay-per-call model (USDC/USDT on Base via x402), the free tier (3 free calls per wallet), and the specific data categories returned. This goes beyond the structured hints and gives the agent critical information about cost and access requirements.

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

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

The description is three concise sentences with zero fluff. The first sentence front-loads the core purpose and data fields, and the subsequent sentences address payment and free tier. Every sentence earns its place, and the most critical information (what the tool does) is presented first.

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 geolocation tool with an output schema present, the description covers the essential aspects: what data is returned, the payment model, and the free tier. It does not elaborate on error handling or rate limits beyond free calls, but annotations (readOnlyHint, openWorldHint) and the output schema cover safety and return structure. Given the tool's complexity, the description is quite complete.

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

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

Schema description coverage is 100%, with each parameter (ip, wallet, api_key, x_payment) already documented in the schema. The description adds minimal parameter-specific detail beyond mentioning payment and free calls, which maps to the wallet and x_payment parameters. Since the schema carries the heavy lifting, the description adds only marginal value, fitting the baseline 3.

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

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

The description states a specific verb ('geolocation') and resource ('IP'), and enumerates the exact data fields returned (country, region, city, coordinates, timezone, ASN, ISP/org, EU flag, private-range detection). This clearly distinguishes it from sibling tools like dns_lookup or domain_rdap, which handle DNS/domain data rather than IP location. The purpose is unambiguous and highly specific.

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

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

The description gives context that it's an IP geolocation tool and mentions payment requirements, but it does not explicitly state when to use this tool versus alternatives (e.g., dns_lookup for DNS records, or geocode for physical addresses). There are no exclusions or comparisons with siblings. An agent can infer usage from the purpose, but explicit guidance is lacking.

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 annotations (readOnlyHint and openWorldHint), the description discloses payment requirements (USDC/USDT on Base via x402), the 3-free-calls-per-wallet allowance, and the restriction to public repositories. These are meaningful operational details an agent needs before invoking the tool.

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

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

Two dense sentences: the first captures the tool's output and scope, and the second covers payment and free-tier policy. Every clause earns its place, with no filler or repetition.

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

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

The description is complete given the rich annotations and fully covered schema and output schema. It tells the agent what the tool returns, that only public repos work, how payment works, and the free-tier conditions. Nothing essential is missing 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 description coverage is 100%, so the parameters are already fully documented. The description adds output-level detail such as 'language split (%)' and '5 most recent commits,' but does not need to explain individual parameters because the schema already covers them.

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 concrete action ('one-call overview') with a specific resource ('any public GitHub repository') and enumerates the exact data returned: description, stats, language split, license, README excerpt, and recent commits. This clearly differentiates it from broader Internet tools like web_crawl or 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?

The description gives clear context: it is the right tool for pulling a single overview of a public GitHub repository, and it clarifies the public-repo scope. It does not explicitly name alternative tools or exclusion cases, but no near-sibling requires routing. It also adds cost/free-tier guidance with wallet-based 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?

While annotations indicate readOnlyHint and openWorldHint, the description adds useful context about local computation, payment requirements, and a free tier. However, it doesn't disclose potential limitations like rate limits beyond the free tier or security implications of exposing text, but it does exceed the baseline given 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 succinct, two sentences, with the core purpose front-loaded. It efficiently conveys essential information about algorithms, payment, and free tier without fluff.

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

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

The tool has an output schema, so return values are covered. The description covers usage context, payment, and free tier. Missing is explicit mention of output format (e.g., hex string) but that's in output schema. Also lack of note on hash collision or security, but that's minor.

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 description explains the default algorithm (sha256) and how to specify multiple algorithms, adding value beyond the schema's parameter descriptions. It also clarifies the meaning of wallet and x_payment in the context of payment and free tier, enriching the schema.

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

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

The description clearly states the tool computes cryptographic hash digests of arbitrary text, listing supported algorithms (MD5, SHA-1, etc.), which differentiates it from siblings like uuid or text_stats. The verb 'compute' and resource 'hash digests' are specific.

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

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

The description explains the key-less, local computation nature and mentions payment options, but does not explicitly contrast with alternative tools or state when not to use it. However, the context is clear for a hashing utility, so it's a minor gap.

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

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

The annotation readOnlyHint=true already indicates this is a safe read operation. The description adds the 'Free' note, which is useful context about cost. It also specifies what the tool returns (service status, provider health, cache metrics), which adds behavioral context beyond the annotation. However, it doesn't disclose details like rate limits, response format specifics, or what 'health' means in terms of potential error states.

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

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

The description is a single sentence that is concise and front-loaded. It states the key facts: free, returns service status, provider health, and cache metrics. Every word earns its place, and there is no fluff or repetition.

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

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

For a zero-parameter, read-only tool with an output schema, the description is fairly complete. It tells the agent what the tool does and that it's free. The output schema likely describes the return structure, so the description doesn't need to. The only minor gap is not explaining when to use this over other monitoring tools, but given the tool's simplicity, this is adequate.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). The description doesn't need to explain parameters since there are none. The baseline for 0 params is 4, and the description appropriately doesn't add unnecessary parameter information. It does clarify the scope of what the health check covers, which is useful.

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: it returns AMR service status, provider health, and cache metrics. The verb 'returns' and the specific resources (service status, provider health, cache metrics) make the purpose clear. It doesn't explicitly differentiate from siblings, but the name 'health' and the specific metrics make it distinguishable from the other 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 description implies usage context: it's a free health check tool, likely to be used when checking service status or monitoring. However, it doesn't explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools. The 'Free' note is a small usage hint but not a full guideline.

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

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

Annotations (readOnlyHint=true, openWorldHint=true) already cover read-only and open-world behavior. The description adds the payment model (pay per call via x402 with USDC/USDT on Base, 3 free calls per wallet) and the sort/tag options, which are behavioral details beyond the schema. No contradictions with annotations.

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

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

The description is concise, with the core purpose first, followed by return fields, sorting, tags, and payment info. It is front-loaded and free of redundant language, though it could be tightened slightly by merging the payment sentence. Overall well-structured.

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

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

With an output schema present, return values are covered. The description explains purpose, main features, sorting, and payment, which is sufficient for a search tool. Missing explicit usage guidance and any note on error behavior, but these are minor given the simplicity of the operation.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description mentions sort_by and tags but does not add new semantics beyond the schema's own descriptions. It reinforces the free-tier detail for the wallet parameter, but that is behavioral rather than parameter-specific. 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 it searches Hacker News stories and comments, lists the returned fields (title, URL, author, points, etc.), and specifies sorting and tag filters. It is specific to HN and distinct from siblings like news_search or reddit_search by naming the exact resource and API.

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

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

The description implies usage for HN searches but does not explicitly contrast with alternatives or state when not to use it. It lacks guidance like 'use for HN content; for general news use news_search.' The context is clear enough that an agent could infer it, but explicit exclusions are absent.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful operational context: no API key needed, USDC/USDT payment on Base through x402, a free-call allowance, and the exact output fields (names, nationwide flag, sub-region counties). No statement contradicts the annotations.

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

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

Two short sentences with purpose and source front-loaded, followed by payment and free-tier details. No redundant filler; every clause contributes to the agent's understanding.

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

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

Together with the rich schema, output schema, and annotations, the description is sufficient for an agent to know what to call, which parameters matter, and what operational constraints apply. It could only marginally benefit from explaining x402 mechanics or error conditions, but these are not required 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?

The input schema describes all five parameters (100% coverage), so the baseline applies. The description reinforces 'country and year' and explains wallet/x_payment economics, but it does not add detailed format constraints beyond the schema. Thus a 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 identifies the resource (official public holidays for a country and year) and the source (Nager.Date), though it lacks an explicit imperative verb like 'fetch' or 'retrieve'. It is distinct from all listed siblings, none of which target holidays, so an agent can identify the tool without ambiguity.

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

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

The description gives concrete invocation context: country and year, key-less access, payment via x402, and a 3-free-calls-per-wallet tier. It does not explicitly name alternatives or exclusion conditions, but no holiday-related alternative exists among the siblings, so the context is sufficient for 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?

The description goes well beyond the readOnlyHint and openWorldHint annotations by disclosing the extraction pipeline (Trafilatura with markdownify fallback), the filtering behavior (boilerplate/nav/ads removed), SSRF guarding, the 3 MB limit, and the payment/free-tier model. This gives the agent strong expectations about side effects, constraints, and costs.

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

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

Three dense, front-loaded sentences: purpose and output, extraction behavior and constraints, then payment terms. Every sentence adds distinct and necessary information with no filler.

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

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

Given the tool has an output schema and six parameters, the description covers the essential operational context: input URL type, output format, content filtering, fallback behavior, size cap, payment requirements, and free-tier usage. Nothing critical for invoking 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 all six parameters are already documented in the input schema. The description adds high-level context about optional links/images and payment, but it does not materially go beyond what the schema already states for any 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 uses a specific verb and resource ('Convert any public web page into clean, LLM-ready Markdown'), then elaborates exactly what is preserved and removed. This clearly distinguishes the tool from siblings like web_search or pdf_text by its output format and extraction-only scope.

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

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

It clearly says when to use the tool: when you have a public web page URL and want clean Markdown. It also states exclusions such as 'public' pages and a 3 MB HTML limit, but it does not explicitly name alternatives or say when to prefer extract_clean or web_crawl instead.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the payment model (per-call with USDC/USDT on Base via x402, no API key, 3 free calls per wallet) and the data source limitation (ticker/volume, no full order book). These are important behavioral traits not captured in annotations.

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

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

Two sentences, front-loaded with the tool's purpose and outputs, followed by the payment model. Every sentence adds value; no fluff.

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

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

The description covers the core purpose, payment model, and data source limitation. Since an output schema exists, return values are covered elsewhere. It doesn't explicitly mention the required parameters or the default quote, but these are in the schema. Overall, it provides sufficient context for an agent to decide whether to use it, though it could mention the free-tier wallet requirement explicitly (though it's in 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?

The schema covers all parameters with descriptions, so the baseline is 3. The description doesn't add additional meaning beyond what's in the schema; it merely refers to 'given trade size' which aligns with size_usd. No extra semantic guidance is provided.

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

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

Clearly states it computes cross-exchange crypto spread from live tickers, listing specific outputs (gross spread, fees, slippage, transfer cost, net edge in bps) and the trade size input. It also specifies it's ticker/volume based, not full order book, distinguishing it from potential siblings like dex_price or 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 clear context that this is for cross-exchange spread analysis and notes the limitation of being ticker/volume based (no full order book), which helps an agent decide when to use it. However, it doesn't explicitly name alternative tools or state when not to use it.

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

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

Annotations already indicate readOnlyHint and openWorldHint, which fit the description (creating a new output without modifying input). The description adds valuable behavioral context beyond annotations: payment via USDC/USDT on Base, x402, no API key, and a 3-free-calls-per-wallet limit. This helps the agent plan for cost and authentication.

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

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

Two sentences with no wasted words. The main operation, input, output, and cost model are all stated efficiently. The essential info 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 tool has 6 parameters, but only 2 are required; the schema covers all. Output schema exists, so return structure is handled. The description covers the core function, payment, and free tier, and specifies the input must be a public URL. It could mention file size limits or supported codecs, but that's minor given the schema and output schema.

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

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

Schema description coverage is 100%, so all parameters are already described in the schema. The description repeats the two required params (url, target_format) and gives example formats, but adds little that isn't in the schema. With full coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool converts/transcodes public media files via FFmpeg and returns a public output URL. It names the resource (audio/video/image), the action (convert/transcode), and the result. Among siblings (mostly unrelated checks and lookups), it is unique and instantly recognizable.

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

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

The description gives clear context for when to use it (converting a public file) and mentions the payment model and free tier. It does not explicitly contrast with alternatives, but no sibling is closely related, so the usage is effectively unique. The 'public' aspect and format list add practical direction.

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 readOnly/openWorld annotations, it discloses SSRF-guarding and the payment model (USDC/USDT on Base via x402, 3 free calls per wallet), which materially affects invocation. No contradiction with annotations; failure/error behavior is not discussed but that is minor given the existing 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?

Four tight sentences, front-loaded with the core result set, followed by use cases, safety, and payment terms. Every sentence carries information an agent needs, with no 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?

Between the full field enumeration, explicit use cases, payment/free-tier terms, and the existing output schema plus annotations, an agent has enough to select and invoke the tool. It lacks only a direct comparison to a sibling tool, which is supplied by the 'Ideal for...' usage cue rather than an explicit alternative.

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 all four parameters. The description adds minimal parameter context: it ties wallet to the free tier and x_payment to Base payments, but does not explain api_key or add format/nuance 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?

States a specific verb-resource ('Structured metadata for any public page') and enumerates exact returned fields: title, meta description/keywords, canonical URL, lang, charset, favicon, full OpenGraph and Twitter-Card sets. The 'in one call' and 'Ideal for link previews/unfurling' framing distinguishes it from sibling content-extraction tools like html_to_markdown or seo_check.

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?

Gives explicit intended contexts ('Ideal for link previews / unfurling and agent research') and scope ('any public page'). It does not name sibling alternatives or state when not to use it, so it stops short of full exclusion guidance.

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

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

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds valuable non-obvious behavior: payment is required (USDC/USDT on Base via x402), there is a 3-free-calls-per-wallet tier, and it specifies the GDELT source and per-article output fields. This goes beyond annotation defaults without contradicting 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?

Two sentences with no filler: the first packs scope, returned fields, and filters; the second covers the billing model. It is slightly dense but all content is relevant to invoking the tool correctly.

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 presence of an output schema means return-value details aren't needed. The description covers the essential non-obvious operational context—billing, free tier, language coverage, and source API—so an agent has enough to decide whether and how to call it.

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

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

Schema description coverage is 100%—every parameter already has its own description, including defaults like 'en' and '10' and constraints like max_results 1-50. The description reinforces the timespan and language examples but doesn't add meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('search') and precise resource ('global news article'), identifies the underlying API (GDELT DOC 2.0), and enumerates exact return fields (title, URL, source domain, publication time, language, country). This makes it clearly distinguishable from sibling search tools like arxiv_search, reddit_search, 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?

It provides clear context that this is a news-specific, multi-language search with time-window and language filters, which helps an agent select it over generic web or domain-specific siblings. It doesn't explicitly mention when not to use it or name alternatives, but the news-domain framing is sufficient for most routing decisions.

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

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

The description adds meaningful behavioral context beyond annotations by disclosing the payment model: 'Pay per call with USDC or USDT on Base via x402' and the free-tier limit of 3 calls per wallet. The readOnlyHint and openWorldHint annotations already cover safety and dynamic results, so the description's extra cost-related transparency is valuable. No contradiction with annotations 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 compact: two sentences, with the core value prop and returned fields front-loaded, followed by the payment model. The opening phrase 'npm package intelligence' somewhat echoes the tool name, but the rest of the first sentence earns its place by enumerating useful outputs and the target use case.

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 an output schema exists and the input schema fully documents parameters, the description covers the remaining essentials: what data is returned, the intended use case, and the payment/free-tier requirement. Nothing critical appears missing for an agent deciding whether and how to call this tool, though the description could be slightly more explicit about alternatives.

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 every parameter. The description mentions the free-tier wallet behavior, but this is redundant with the 'wallet' parameter's schema description. No additional parameter-level meaning is supplied beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the resource (npm packages) and enumerates the specific data returned: version, license, repository, maintainers, dependency count, publish dates, and weekly downloads. It differentiates from the sibling pypi_package by naming npm explicitly, but it lacks an explicit action verb like 'get' or 'fetch', relying on the noun phrase 'package intelligence' to imply retrieval.

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

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

The description gives a clear use case: 'ideal for dependency vetting by coding agents.' This tells an agent when to invoke the tool, though it does not explicitly name alternatives or state when not to use it. The npm-versus-PyPI distinction is implied by the ecosystem label rather than stated as an exclusion.

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 explicitly states 'Free', which is valuable behavioral context beyond the readOnlyHint annotation. It also discloses what the tool returns and its purpose. It does not mention rate limits or error behavior, but for a simple read-only lookup tool with a single parameter, 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 a single sentence that front-loads the most important fact ('Free') and then states the resource, the specific fields, and the purpose. Every word earns its place; 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?

For a simple one-parameter read-only tool with an output schema, the description is nearly complete. It tells the agent what it returns and why to use it. The only minor gap is that it doesn't describe the output schema structure, but the output schema itself is present in the context, so the description need not repeat it.

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

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

Schema coverage is 100% and the parameter description already explains the tool name and gives an example. The description adds context by explaining that the returned requirements are for constructing an x402 payment, which clarifies why the parameter matters. The enum list is exhaustive, so the agent has full information.

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

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

The description states a specific verb ('Returns'), a specific resource ('x402 payment requirements'), and enumerates the exact fields returned (price, USDC/USDT contract, pay-to wallet, network). It also states the purpose ('so an agent can construct an x402 payment'), which distinguishes it from sibling tools that perform the actual paid operations.

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

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

The description clearly indicates when to use this tool: when an agent needs to construct an x402 payment for a given tool. It implies this is a prerequisite step before calling a paid tool, and the parameter description reinforces that the tool name should match tools/list. However, it does not explicitly state when NOT to use it or name alternatives, so it falls short of a 5.

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