crypto-web-data-api

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely non-obvious behavior: 3-second caching, tolerant fan-out to exchanges that respond, profit net of taker fees, and a per-call price with x402 payment rails (USDC on Base or Solana). What it does not cover is failure behavior (what happens if payment is missing or no exchange answers) or how the paid call is authenticated beyond the schema's tx note.

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 tight sentences: capability, mechanics, then operational constraints (cache, cost). Front-loading is good and every sentence carries information. The opening clause largely restates the title, so a small amount of duplication exists.

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?

No output schema exists, so the description carries the burden of indicating return content; it describes the computation (best pair, estimated profit) but not the response shape, timestamps, or which exchange fields come back. For a single-optional-parameter read tool this is close to adequate, but the return contract remains underspecified.

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?

With one optional parameter and 100% schema description coverage, the schema already explains tx as an alternative to the X-Payment-Tx header, so the baseline is 3. The description corroborates this by mentioning the x402 payment mechanism, which gives the tx parameter context. It adds no syntax or format detail of its own.

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?

Names a concrete, narrow resource (BTC/USDT spread across five named exchanges) and a concrete verb chain: compare best bid/ask, pick the best buy/sell pair, estimate profit after taker fees. This is far more specific than a generic 'price' tool, so an agent can tell it apart from siblings implicitly. It stops short of explicitly contrasting itself with price/prices/market_overview, which keeps it at 4 rather than 5.

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

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

Usage is implied by the framing: use this when you want a cross-exchange spread and net-of-fee profit rather than a single price. There is no explicit when-to-use/when-not statement and no named alternative (e.g. price for a single-exchange quote). The 'every exchange that answers' wording does tell the agent to expect partial coverage, which is useful 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 cost and latency details here are genuinely additive: 30 s caching, $0.010 per call, and x402 payment in USDC on Base or Solana. That is exactly the kind of operational context an agent needs before calling a paid endpoint. It falls short of a 5 because it never explains what happens when payment is absent or how the X-Payment-Tx header/`tx` parameter interacts with billing.

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

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

Three sentences, front-loaded with what the tool returns, then computation window, then cache/price/payment. No filler. The opening sentence duplicates the title verbatim, which costs a little, but the rest is dense and useful.

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

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

For a read-only, single-resource data endpoint with four simple parameters, this covers the essentials an agent cannot get from the schema: exchange, indicator window, caching, and price/payment rail. The main remaining gap is the return shape (array of candle objects with field names), which has no output schema to cover 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 75%, with `limit` and `interval` already documented and `symbol` covered by a pattern and example but no prose. The description adds the exchange scope (Binance spot) and confirms indicators are computed over the most recent 200 candles, which contextualizes the limit ceiling, but it adds no per-parameter meaning beyond that. 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 names the resource precisely (OHLCV candles) and lists the exact indicator set (RSI14, SMA20, SMA50, ATR14, volatility, trend), which separates it from a plain quote tool like price or prices. However, it never names a sibling or states the distinction explicitly, so the differentiation is inferred from the content rather than declared.

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

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

There is no when-to-use or when-not-to-use guidance: nothing says to pick this over price, token_price, or market_overview when an agent needs technical indicators versus a spot quote. Usage is only implied by the returned data. The 'last 200 candles' note is a scope constraint, not selection guidance.

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

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

The annotations already establish readOnlyHint=true and openWorldHint=true, so the description's job is added context — and it does supply real value: a 6-hour cache window, a $0.010 per-call price, and the x402 payment rail (USDC on Base or Solana). What it omits is failure behaviour: what happens for an unresolvable or parked domain, which fields are nullable when schema.org markup is missing, and whether a cached response still bills the same. Those gaps matter for an open-world paid lookup.

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 resource and its outputs, followed by the commercial and payment terms. The only waste is the first clause, which restates the title verbatim before the more informative 'Enriches a company or project domain in one call'. The field list is dense but each item earns its place because no output schema exists.

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 no output schema, describing the return payload is essential, and this description does it thoroughly, covering enrichment sources (schema.org, MX, RDAP) as well as fields. It also surfaces pricing and caching, which the annotations do not carry. Missing only edge-case behaviour on empty or unenrichable domains, which prevents a 5.

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 both 'domain' (format and example stripe.com) and 'tx' (alternative to the X-Payment-Tx header) documented in the schema itself. The description reinforces that the input is a bare domain, not a URL, via the phrase 'from a domain', but adds no constraints, normalisation rules, or examples beyond what the schema already states. 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 names a specific verb and resource ('Enriches a company or project domain in one call') and enumerates exactly which fields come back: name/description, logo, socials, emails/phones, address, founding date, technologies, MX provider, RDAP age. That field-level enumeration is what distinguishes it from near neighbours like 'domain' or 'email_check'. It stops short of explicitly naming which sibling to prefer, which keeps it at 4 rather than 5.

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

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

It offers use cases ('For lead research, due diligence and KYB'), which implies when the tool is appropriate. But there is no guidance on when NOT to use it, no mention of the sibling 'domain' tool or of cheap alternatives if only one field is needed. With a paid per-call tool, an explicit 'use this only when you need multiple fields at once' rule would be valuable and is 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?

Beyond readOnlyHint and openWorldHint, the description discloses the data source (DefiLlama), the ordering (by APY), the returned fields (base vs reward APY, 30-day mean, IL risk, TVL), outlier removal, a 15-minute cache, and the exact cost and payment rail ($0.010 via x402 USDC on Base or Solana). These are material traits an agent cannot get from 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?

Four dense sentences with the core purpose and filters front-loaded, followed by result contents and then cost/caching. The opening restates the title almost verbatim, which is the only real waste.

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

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

For a read-only, no-output-schema tool with 7 optional parameters, the description covers data source, sort order, returned metrics, caching and payment requirements well. Minor gaps remain around default result size, pagination, and what happens on payment failure.

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 86%, so the schema already carries most parameter meaning. The description echoes chain, symbol, stablecoin and min TVL filtering but says nothing about the 'project' or 'limit' parameters, and adds no format or interaction detail beyond the schema.

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

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

The description names a concrete resource and verb-like action: 'Top DeFi pools from DefiLlama filtered by chain, token symbol, stablecoin-only and minimum TVL, sorted by APY.' That is specific enough for an agent to distinguish it from siblings like token_price or token_risk, though no sibling is named explicitly.

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

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

Usage is implied by the listed filters and the 'sorted by APY' behavior, so an agent can infer this is the yield-shopping tool. However, there is no explicit when-to-use/when-not guidance and no pointer to an alternative such as arbitrage or token_report for related questions.

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, and the description adds genuinely new behavioral facts beyond them: results are cached for 1 hour and each call costs $0.005, payable via x402 in USDC on Base or Solana. It stops short of describing error behavior, e.g. what is returned for an unregistered domain or a lookup timeout, so it is strong but not complete.

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 payload is front-loaded into a single dense sentence that lists the returned data, followed by short cache and price notes. Every clause carries information, though the mid-sentence enumeration runs long and could be split for faster scanning.

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

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

With no output schema, the description must convey what comes back, and it does so thoroughly across WHOIS, DNS, SSL, and risk flags. Payment and caching are covered; only failure/edge-case behavior is left unstated.

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

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

Schema description coverage is 100%, so both parameters (name and tx) are already documented in the schema, which sets the baseline at 3. The description adds only indirect meaning by mentioning the x402 payment path, which loosely explains the tx parameter, but gives no extra syntax or format guidance for the domain name beyond the schema's pattern.

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 resource (domain) and enumerates exactly what is checked: WHOIS/RDAP registrar and dates, A/AAAA/MX/NS/TXT records, SPF/DMARC, HTTPS certificate, and risk flags such as a very young domain. This is clearly distinguishable from the other lookup siblings (email_check, evm_address, token_risk) because the resource and its return contents are named outright.

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

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

Usage is only implied: an agent can infer this is the tool for domain registration/DNS/certificate reconnaissance and phishing screening. There is no explicit when-to-use or when-not, and no sibling alternative is named for overlapping needs (e.g., email_check for a mailbox on that domain).

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, the description discloses genuinely useful operational traits: no SMTP probing, a 1-hour cache, and a concrete price ($0.005) with the x402 payment mechanism (USDC on Base or Solana). These are exactly the details an agent needs before calling a paid third-party lookup.

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?

Roughly three sentences, front-loaded with the check list, followed by the exclusion, caching, and pricing details in order of decision relevance. Every clause carries information; nothing is 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?

Cost, caching, payment method, and the set of checks are all covered, which is strong for a paid external lookup. However, with no output schema, the description does not indicate the shape of the result (e.g., booleans per check vs. a score), leaving the return contract underspecified.

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?

With 50% schema coverage, the `email` parameter is described only by examples and length constraints, and the description adds no format guidance for it. The payment line implicitly contextualizes the `tx` parameter, but the description never explains the tx field or its relationship to the X-Payment-Tx header, so it only partially compensates for the coverage gap.

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

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

The description names a specific resource (email address) and enumerates exactly the checks performed: syntax, MX, disposable list, role accounts, and free providers. No sibling tool overlaps this domain, and the scope is unambiguous from the first line.

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 states the applicable context (validating an email for deliverability signals) and explicitly bounds it with 'No SMTP probing,' which tells the caller what it will not do. There are no alternative tools to route to, so the lack of explicit exclusions is a minor gap rather than a real deficiency.

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/openWorldHint annotations, the description discloses Ethereum-mainnet-only scope, a 10-minute cache, and a per-call price of $0.002 with x402 payment via USDC on Base or Solana — genuinely actionable context an agent cannot get from annotations. It does not describe failure behavior for unresolvable names or unverified reverse records, leaving a modest 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 definition is compact and front-loaded: direction, network, record types, input rule, caching, then pricing. The opening clause largely duplicates the title, which is a minor waste, but the remaining sentences each add distinct information.

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

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

With no output schema, the description carries the burden of describing returns, and it does so by enumerating the profile text records returned (avatar, url, description, email, socials). Combined with the cost and caching disclosures, an agent has enough to call this correctly; only the response envelope shape and no-result behavior remain unspecified.

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 only 33% (only `tx` is documented, and thinly), so the description must compensate — and it does by explaining that `name` drives forward resolution and `address` drives reverse resolution, and that one or the other should be given. The `tx` payment parameter is left to the schema's one-line note and the x402 mention, so the payment flow is only partially clarified.

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

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

The description names a specific verb (resolve) and resource (ENS names/addresses) and explicitly spells out both directions: forward name -> address and verified reverse address -> primary .eth name, plus text-record retrieval. This is more than the title restated and makes it clearly distinct from siblings like evm_address or domain. It stops short of naming a sibling to contrast against, which keeps it at 4.

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?

'Give either name or address' establishes that one of the two inputs selects the operation mode, which is useful usage framing. However, there is no guidance on when to prefer this over evm_address/domain, no statement about what happens if both or neither are supplied, and no exclusions. Usage is implied rather than prescribed.

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 genuinely non-obvious traits: a 15-second cache and the $0.001-per-call price via x402 USDC on Base or Solana, which materially affects how an agent should batch or repeat calls.

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 classification question leads, followed by exact output fields, usage triggers, then operational details (cache, price). Slightly redundant phrasing between the opening question and the field enumeration, but every clause carries information.

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

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

With no output schema, the description compensates by listing the returned fields and the account-type taxonomy, which is what an agent needs to interpret results. Cost and caching are also disclosed; only the payment parameter and per-chain failure behavior remain unaddressed.

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 only 33%, so the description has to carry weight. It does usefully enumerate chain values (Base, Ethereum, Arbitrum, BSC, Polygon, Optimism, Avalanche) and the 'all' scope for the undescribed chain parameter, but says nothing about the payment 'tx' parameter beyond what the schema already states, and the address format relies on the schema pattern.

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 question the tool answers ('wallet or contract?') and enumerates the outputs it returns: wallet vs contract vs EIP-7702 delegated account, bytecode size, nonce, native balance. This implicitly separates it from the sibling evm_balance (balance only) and wallet, though no sibling is named explicitly.

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?

'Use before sending funds or to sanity-check a counterparty' gives a concrete decision context, and the scope 'for one address on one or all EVM chains' frames the calling pattern. It stops short of explicit exclusions or naming evm_balance/evm_call as alternatives for narrower queries.

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 the 15-second cache window, a per-call price of $0.003, and the x402 payment rail (USDC on Base or Solana). Cost and payment requirements are exactly the operational facts an agent must know before calling a paid endpoint.

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 resource and chain scope, then the token coverage, then caching and price. Dense but no filler; the payment clause is compressed into a parenthetical but remains parseable.

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?

There is no output schema, yet the description says what comes back at a high level (balances with USD values) and covers cost, caching and chain scope. It omits the response shape (e.g. per-chain grouping) and any failure behavior for an invalid address or unpaid call.

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 chain, tokens, address and tx. The description only lightly reinforces this by noting chain=all sweeps every chain and that custom contracts are single-chain only, which the schema already states. 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 names a specific resource and scope: native coin plus USDC/USDT/DAI/wrapped-native balances for an address across seven named chains, with USD values. That is concrete enough for an agent to distinguish it from evm_address or evm_token_balance by capability, though no sibling is named explicitly.

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 explains the two operating modes (chain=all sweeps every chain; a single chain allows extra ERC-20 contracts), which is implied usage guidance. It never states when to prefer a sibling such as evm_token_balance or wallet, nor any exclusions or prerequisites beyond payment.

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 readOnlyHint/openWorldHint, the description discloses that results are not cached, that each call costs $0.001, and that payment runs through x402 in USDC on Base or Solana. It also states the return shape (raw hex plus decoded values) and the supported argument and return type sets, which materially affects how an agent prepares a call.

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

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

The lead sentence front-loads the action and the example invocation follows immediately, so an agent gets the essentials first. There is mild redundancy in listing the chain roster ('Base, Ethereum and 5 more chains' then enumerating all seven), but no wasted 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?

With no output schema, the description correctly explains returns (raw hex and decoded values) and supplies type constraints for arguments and return values, plus cost and caching behavior. The remaining gap is the semantics of the block parameter and the tx payment field, which are not explained anywhere an agent would look.

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?

With 71% schema coverage, the description adds real meaning to sig, args and returns by giving a concrete sig/args/returns example and stating which Solidity types are accepted. It leaves the block and tx parameters (tx is described only as an alternative to the X-Payment-Tx header) unaddressed, so it does not fully compensate for the uncovered fields.

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

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

States a specific verb and resource: it calls a view function via eth_call by signature, and enumerates the supported chains (Base, Ethereum, Arbitrum, BSC, Polygon, Optimism, Avalanche). This clearly separates it from siblings like evm_balance, evm_token_balance and evm_tx, which target fixed data rather than arbitrary contract functions.

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

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

The phrase 'calls a view function by its signature' implicitly scopes usage to read-only/pure functions and the worked example (sig=balanceOf(address)&args=0x...&returns=uint256) shows exactly how to invoke it. It stops short of naming alternatives or stating when NOT to use it (e.g. 'use evm_balance for native balances'), so routing is left partly 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?

Beyond readOnlyHint/openWorldHint the description discloses caching (10 s), per-call price ($0.001) and the x402 payment path (USDC on Base or Solana), which are exactly the operational facts an agent needs before spending money. It stops short of stating failure behavior for unsupported chains or unpaid calls.

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 sentences, front-loaded with the resource and cost claim, then scope, then usage and pricing. No filler, and the parentheticals carry real signal rather than decoration.

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

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

With no output schema, the description correctly spells out the return payload (raw and human-readable amount plus symbol and decimals), and the payment/caching notes cover the operational side. Minor gaps remain around default-chain assumptions and unsupported-chain errors.

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 only 25%: 'chain' has no description at all and 'tx' only says 'alternative to the X-Payment-Tx header'. The description partially compensates by enumerating the valid chains and noting that the token symbol and decimals are returned, but it never explains the chain parameter's accepted values or how tx relates to payment.

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 (balance of one ERC-20 token for one wallet) and scopes it to seven named chains, which separates it from a generic 'balance' tool. It does not name the sibling evm_balance (presumably native-coin balance) that an agent would most likely confuse it with, so differentiation stops short of explicit routing.

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 concrete usage contexts ('confirm a deposit', 'check funds before paying') and hints at cost-based selection with '(cheapest balance check)'. There is no explicit when-not or named alternative, so an agent still has to infer that native-token balances belong to a sibling or other tool.

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

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

With readOnlyHint and openWorldHint already given, the description still adds substantial context an agent cannot get from annotations: the underlying data sources (GoPlus, honeypot.is, DexScreener), a 60-second cache, and an explicit per-call price with the x402 payment rail (USDC on Base or Solana). The payment detail is especially actionable because it explains the otherwise cryptic 'tx' parameter, which is the alternative to an X-Payment-Tx header.

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 core purpose and then a dense but scannable list of checks. The opening clause duplicates the tool title, and the long signal list is slightly run-on, but every item is informative and nothing is padding.

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

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

There is no output schema, and the description compensates by stating the return shape: merged flags plus a risk level. Cost, caching, data sources, and chain coverage are all covered. The remaining gap is failure/edge behavior, e.g. what happens for an unsupported chain or an unverified contract, which an agent calling a risk tool would want to know.

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 chain enum, the address pattern, and the tx field are already fully documented in structured data. The description only indirectly explains tx via the x402 pricing sentence and adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

The first sentence states a specific verb+resource: a scam/honeypot check on an EVM token, and the second enumerates exactly which signals are computed (sell simulation, taxes, mintable, proxy, blacklist, holder concentration, LP lock). It does not, however, differentiate itself from the sibling tools token_risk and token_report, so an agent must guess which of the three to pick.

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

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

Usage is implied rather than stated: 'Scam / honeypot check' tells an agent this is a pre-trade safety gate, and the chain list scopes it to EVM networks. There is no explicit when-to-use, when-not-to-use, or reference to token_risk / token_report as alternatives, which is the main ambiguity given the sibling set.

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; the description adds real behavior the agent cannot see elsewhere — a 10-second cache, a metered cost of $0.003 per call, and the x402 payment rails (USDC on Base or Solana). It stops short of describing not-found/error behavior or how many transfers are returned for a busy transaction.

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?

Short, front-loaded sentences with the resource and returned fields first, followed by invocation guidance and then cost/caching notes in the order an agent would need them. The opening sentence largely repeats the tool title and the return-field list is restated at slightly more length than necessary, but there is no filler.

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

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

With no output schema, the description carries responsibility for describing the response, and it does so by enumerating status, confirmations, block time, fee and decoded ERC-20 transfers. Pricing, caching and chain fallback are also covered; only failure modes and transfer-list limits 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 all three parameters are already documented, and the schema fixes the default for chain to an empty string. The description restates the empty-chain semantics in plain language, which is useful but does not add syntax or format detail beyond what the schema already supplies.

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?

Names a specific resource (an EVM transaction identified by hash) and enumerates what is returned: status (pending/success/failed), confirmations, block time, fee and decoded ERC-20 transfers. That is enough to separate it from siblings like evm_address, evm_balance and evm_call, though the description never explicitly contrasts with them.

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?

"Use to verify a payment arrived" gives one concrete situation in which to pick this tool, and "Leave chain empty to search all supported chains" tells the agent how to invoke it under uncertainty. There are no when-not-to-use rules and no named alternative for cases where the hash is unknown or the chain must be pinpointed.

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, yet the description adds material context beyond them: content is cleaned of menus/scripts/ads, responses are cached for 5 minutes, and each call costs $0.005 via x402 (USDC on Base or Solana). The payment requirement in particular is decision-critical information an agent would otherwise miss. It stops short of describing failure modes (non-public URLs, timeouts, payment rejection), which keeps it from a 5.

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

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

It is front-loaded with the purpose, then layers return shape, formats, caching and pricing. The telegraphic fragment 'HTML, plain text and JSON.' is the only rough spot; everything else carries information an agent needs.

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 3-parameter tool with no output schema, the description covers what comes back (Markdown body plus metadata and up to 50 links), cost, and caching. Missing are error/refusal semantics and what happens when a page exceeds max_chars, but nothing essential to invoking it is absent.

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 goes slightly beyond by naming the return fields and the payment mechanism, which gives context for the otherwise cryptic 'tx' parameter, but it never explains max_chars truncation behaviour or the tx/header alternative in the text itself.

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

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

The description states a specific verb and resource ('Read a web page', 'Fetches a public URL') and spells out the transformation (main content as Markdown without menus, scripts or ads) plus the payload (title, description, language, up to 50 links). That is enough to separate it from siblings like search, wikipedia, rss and pdf without opening any schema.

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

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

Usage is only implied: 'public URL' tells the agent this is for a known URL rather than a query, but no alternative is named and no when-not condition is stated (no guidance for PDFs, paywalls, or search-first workflows). A brief 'use search to find URLs, use pdf for PDF documents' would have lifted this.

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 genuinely useful context: 30-second caching, normalization to 8-hour intervals, coverage of up to four venues, and a per-call price with the x402 payment mechanism. It stops short of describing error or rate-limit behavior, so it is strong but not exhaustive.

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 definition is dense and front-loaded, leading with the resource and venues before the returned metrics, caching, and pricing. The opening sentence largely restates the title, which is the only real redundancy.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so by listing the funding rate, next funding time, open interest, spread, and arbitrage direction. It does not specify the response shape or per-venue error handling, leaving a small gap for a paid multi-venue tool.

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

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

Schema description coverage is 100%, so both the symbol and tx parameters are already documented in the schema. The description adds no parameter-level detail beyond the venue count and does not clarify the tx alternative to the X-Payment-Tx header, 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 names a specific resource (perpetual funding rates), the exact venues (Binance, Bybit, OKX, Hyperliquid), and the metrics returned (current rate, next funding time, open interest, spread, arbitrage direction). It is clearly distinguishable from siblings like price, prices, and arbitrage.

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

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

Usage is implied by the metric list, but there is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives such as the arbitrage or price tools. The agent can infer the context but must decide on its own when this tool is preferable.

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 cover read-only and open-world behavior, but the description adds substantial context they don't: data provenance (ECB, NBU, Binance vs USDT), cache TTLs of 30 min for fiat and 5 s for crypto, and a $0.003 per-call cost payable via x402 in USDC on Base or Solana. That pricing/payment detail is exactly the kind of thing an agent needs before invoking. What's missing is any statement of error behavior or rate limits.

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 tight sentences, front-loaded with the core capability followed by cost/caching operational facts; nothing is filler. The opening clause largely restates the title, which is the only wasted space.

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?

There is no output schema, so the description should say what a conversion returns (a rate, a converted amount, a map per target currency) and it doesn't. Payment mechanics, caching, and source coverage are well covered, leaving the return shape as the main gap for a tool that can take up to 10 target currencies at once.

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 only 25% (only `tx` is documented), so the description has some burden to carry. It does clarify the currency universe and that crypto pairs are quoted against USDT, which adds meaning beyond the bare patterns/examples, but it never explains that `to` accepts a comma-separated list of targets or what `tx` is for. 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 (converts) and resource (amount between fiat and crypto), and names the concrete sources (ECB, NBU, Binance) and the ~60-currency scope, which separates it from siblings like price/prices/token_price. It stops short of explicitly naming those siblings as alternatives, so a 4 rather than a 5.

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

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

Usage is implied by 'converts an amount between...' and the mention of paid x402 access tells the agent a cost applies, but there is no explicit when-to-use/when-not guidance or pointer to the price/prices/token_price siblings for non-conversion lookups. Caching windows hint at freshness tradeoffs but aren't framed as selection criteria.

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 genuinely useful behavior beyond that: a 15-second cache window and a $0.005 per-call cost paid via x402 in USDC on Base or Solana. It still says nothing about freshness risk beyond the cache or what the returned fee data looks like.

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

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

Three short fragments with the purpose front-loaded and no filler; caching and price are the two facts an agent most needs. The parenthetical 'x402: USDC on Base or Solana' is dense jargon that could be clearer, which keeps it from a 5.

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

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

For a simple one-parameter read tool this covers purpose, cache, and cost, but with no output schema the description should say what is actually returned (gas price units, chain breakdown, fee tiers) and it does not. The payment flow implied by x402 is also only hinted at.

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

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

Schema coverage is 100% and the single optional `tx` parameter is documented in the schema as an alternative to the X-Payment-Tx header. The description's x402/USDC note gives some surrounding context for the payment path but does not explain the parameter itself, so baseline 3 is right.

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?

Names the specific resource (network fees) and the two chains covered (Ethereum, Solana), which is enough to distinguish it from siblings like price, token_price, or market_overview. It does not explicitly route against any sibling, so it falls short of a 5.

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

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

There is no statement of when to use this tool versus alternatives such as price or market_overview, and no prerequisites or exclusions. Only billing mechanics are mentioned, which is not usage guidance.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real operational context beyond them: results are cached with a 2-minute staleness window, each call costs $0.005, and payment is via x402 (USDC on Base or Solana). It does not explain payment failure behavior or whether a cached response is billed, but the cost/latency disclosure is substantive and goes well past 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, front-loaded with the metric list, then freshness and cost. The opening clause largely restates the title verbatim, which is a small redundancy, but no other sentence is padding — each adds data scope, cache window, or pricing.

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?

No output schema exists, so the description carries the burden of describing return contents — and it does, enumerating every returned metric including the 'top 5' cardinality. Cost, payment rail, and cache TTL are covered; what is missing is payment-failure or error behavior and any guidance on the optional `tx` parameter.

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?

With one parameter at 100% schema description coverage, the schema already explains that `tx` is an alternative to the X-Payment-Tx header. The description mentions the x402 payment path but never references the `tx` parameter or when an agent would pass it instead of using the header, so it adds only indirect meaning.

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

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

The description names a specific resource (crypto market overview) and enumerates the exact metrics returned: Fear & Greed today/yesterday, total market cap and volume, BTC/ETH dominance, 24h change, and top 5 gainers/losers. The scoping to 'liquid Binance USDT pairs' further distinguishes it from siblings like price, prices, and tokens_trending, which return individual or trending token data rather than a market aggregate.

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

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

Usage is implied by the metric enumeration — an agent can infer this is a one-shot market-context snapshot — and the 'Cached 2 min' note hints at acceptable freshness. However, no sibling is named as an alternative (e.g., use tokens_trending for broader mover lists, price for a single token), and there is no explicit when-not-to-use guidance despite a crowded sibling set.

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, the description discloses the source (CoinDesk RSS), cache freshness (5 min), and a concrete cost with payment rails (x402, USDC on Base or Solana). These are real behavioral traits an agent needs before calling. It stops short of explaining failure modes when payment is missing.

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

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

Four short sentences, each carrying distinct information (what, source, freshness, cost/payment), with the headline scope front-loaded. Nothing is redundant.

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

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

For a zero-required-parameter, no-output-schema tool, the description covers source, caching, and payment mechanics adequately. Return shape is implied by the title ('Latest 5 headlines') rather than described, a minor gap.

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

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

Schema coverage is 100%, so the 'tx' parameter is already documented as an alternative to the X-Payment-Tx header. The description adds payment context (cost, USDC rails) that gives the parameter purpose, but it does not explain the expected transaction format or when to use tx versus the header.

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 resource (CoinDesk headlines) with an exact scope (latest 5), so an agent knows precisely what it returns. It does not explicitly name the sibling news_search or clarify how it differs (keyword query vs fixed feed), which keeps it short of a 5.

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

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

Usage is only implied: an agent can infer this is for a quick latest-headlines snapshot, but the description never says when to prefer it over news_search, rss, or fetch. No exclusions or prerequisites are stated.

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

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

Annotations already mark it read-only and open-world. The description adds valuable operational context beyond annotations: Google News primary with GDELT/Bing fallbacks, 5-minute caching, and $0.003 per-call x402 payment (USDC on Base or Solana). Rate limits are not mentioned, but the added behavioral disclosure is substantial.

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?

Front-loaded with purpose, then return fields, filters, caching and price. Every sentence carries operational value with no filler. Minor repetition of the title's phrase, so 4.

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 six-parameter read-only search with no output schema, the description supplies returned fields (headline, source, link, publish time), source hierarchy, filters, cache and pricing. It omits limit/pagination behavior, but is otherwise complete enough.

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 only 33%. The description adds filter categories for language, country and age, and expands when values to 30d, which helps interpret lang/country. However, it never explains the limit parameter and gives no format detail for lang/country beyond what the schema patterns show. Partial compensation supports a 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?

States a specific verb 'Search' and resource 'recent news' with scope 'any topic, company or token.' It is clear, but it does not explicitly distinguish itself from the sibling 'news' tool.

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

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

Implies use for query-based recent-news retrieval by saying 'for a query,' but gives no when-to-use vs when-not guidance or named alternative such as the sibling 'news' tool. No explicit exclusions or 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 only declare readOnly and openWorld, so the description carries the rest and does so well: 15 MB size cap, page-by-page output shape, the scanned/no-text-layer failure mode, 1-hour caching, and pricing with accepted payment rails. It stops short of saying what happens when max_pages/max_chars truncate the result or what a failed download/payment looks like.

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?

Five short sentences, front-loaded with the action, then output shape, failure mode, caching, and price. Nothing is redundant or padded.

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

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

With no output schema, the description adequately sketches the return payload (text per page plus title, author, page count) and covers cost and latency expectations. It falls short only on the truncation parameters and on error behavior, which matter for a paid, rate-limited external fetch.

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 only 50%: url and tx are documented in the schema, but max_chars and max_pages have no description anywhere, and with their large defaults (50,000 chars / 50 pages) they materially affect whether the caller gets full text. The description's "page by page" hints at page handling but adds no meaning for either limit, so it does not compensate for the gap.

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+input form: "Extract text from a PDF by URL." This distinguishes it from the sibling fetch (raw retrieval) and youtube_transcript (different source type), and the follow-up sentence specifies exactly what is returned.

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

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

Usage is implied by the resource type, and the scanned-PDF caveat signals when the tool will underperform. However, it never explicitly contrasts with the sibling fetch tool (why not just fetch the PDF?) nor states prerequisites such as the URL needing to be public.

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, and the description adds real context the annotations cannot: a 60 s cache, a $0.010 per-call price, and x402 payment via USDC on Base or Solana. It does not describe what happens on payment failure or when no markets match, which keeps it below a 5.

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

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

Two dense sentences, front-loaded with the resource and return fields, followed by operational facts. The opening 'Polymarket prediction markets: odds, volume, liquidity' largely restates the title and is mildly redundant, but the remainder earns its space.

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?

No output schema exists, so the description correctly enumerates the returned fields (probabilities, 24h volume, liquidity, change, end date) and covers cost and caching. The only notable gap is that the default limit and empty-query behavior are not spelled out explicitly.

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 67%, and the description adds the key semantic for q — 'all words must appear in the question' — which is a much stronger matching rule than the schema's example. The tx payment parameter and the limit bound are left entirely to the schema, so it stops short of full 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?

States a specific verb and resource ('Active Polymarket markets matching a query ... with outcome probabilities, 24h volume, liquidity, 24h change and end date') and names the second mode ('or the most traded ones'). No sibling tool covers prediction markets, so the resource alone separates it from market_overview, price, or news.

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?

Implies usage through the two operating modes: supply a query to match words in the question, or omit it to get most-traded markets. It never explicitly says when to prefer this over market_overview or news_search, and no exclusions or prerequisites beyond payment are stated.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses genuinely useful behavior: results are cached up to 5 seconds, and each call costs $0.005 paid via x402 in USDC on Base or Solana. That cost and payment-rail information is exactly the kind of operational context an agent needs before invoking, though the return payload shape is not described.

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, front-loaded with the core purpose and followed by symbol format, caching, and cost. Every sentence carries distinct information an agent would act on, 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?

For a low-complexity single-symbol price lookup with no output schema, the description covers purpose, symbol shape, latency characteristics, and cost/payment requirements. The only gap is return-value format and the precise semantics of the tx parameter.

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

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

Schema description coverage is 50%: the symbol parameter has a pattern, default, and example but no prose description, and the tx parameter is only described as an alternative to an X-Payment-Tx header. The description's mention of x402/USDC payment implicitly explains what tx is for, adding some meaning, but it does not explain symbol format constraints or tx value semantics explicitly.

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

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

The description names a specific resource and verb ('Spot price', 'Last price') and scopes it to Binance spot symbols with concrete examples (BTCUSDT, ETHUSDT, SOLUSDT). It does not explicitly distinguish itself from close siblings like prices, token_price, or arbitrage, so an agent must infer the difference from the 'Binance spot pair' scoping.

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

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

The description gives no when-to-use or when-not-to-use guidance and never names an alternative such as prices, token_price, or candles. The agent is left to infer that this is the single-symbol quote tool from the symbol examples alone.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the 5 s cache window, the $0.010 per-call cost, and the x402 payment mechanism (USDC on Base or Solana) — real operational context an agent needs before calling a paid endpoint. It stops short of failure modes (what happens if a venue is down) or how deviation is computed.

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 sentences, front-loaded with the core capability, then venue/quotation detail, then caching and cost. No filler or repetition of the title beyond the necessary scope statement.

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

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

With no output schema, the description still names the key return elements (median and max deviation across venues), and it covers cost, caching, and payment. A brief note on response shape or behavior when a venue is unavailable 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 coverage is 100% and already documents symbols, its default, the 20-ticker pattern, and tx as an X-Payment-Tx header alternative. The description adds the useful detail that quotes are vs USDT on four venues and vs USD on Coinbase, which affects interpretation, but it says nothing about the tx parameter. 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 resource and scope: consensus prices for up to 20 coins aggregated across five named venues, plus median and max deviation. This clearly separates it from single-coin siblings like price/token_price by scale and aggregation, though it never names those alternatives explicitly.

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

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

Usage is implied rather than stated: the agent can infer 'use this when you want a cross-venue consensus rather than one quote', and the 20-coin cap and 5 s cache imply batching is expected. There is no explicit when-not guidance or routing to price, token_price, candles, or market_overview.

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 safety and network reach are covered; the description adds genuinely new behavioral facts: a 5-minute cache and a paid, x402-metered call at $0.003 with USDC on Base or Solana. That payment and caching context materially affects whether and how an agent invokes it. It doesn't say what happens on payment failure or feed errors, but the added value is substantial.

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, front-loaded with the one-line purpose and the return shape, followed by audience, caching and pricing. Every sentence carries distinct information with no repetition of the title or annotations.

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

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

With no output schema, the description usefully enumerates the returned fields, and it covers the cost/caching dimension that would otherwise be invisible. The remaining gap is the undocumented limit parameter and the mechanics of supplying payment (the schema's tx field is only vaguely linked), which keeps it just short of 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 only 33%: url and limit carry no schema descriptions, and only tx is documented. The description implies the url parameter is the feed endpoint ('Fetches an RSS 2.0 ... feed'), which is a small assist, but it never mentions limit or explains the default of 20 / max of 100, so most of the parameter surface remains undocumented.

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

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

The description states a specific verb and resource ('Fetches an RSS 2.0, RSS 1.0 or Atom feed') and names the exact fields returned (title, link, publish date, plain-text summary), so the resource is unmistakable. It stops short of explicitly distinguishing itself from sibling tools like news, news_search or fetch, leaving the differentiation to the reader.

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?

'For news and monitoring agents' hints at the intended context, but there is no explicit when-to-use/when-not guidance and no named alternative such as news_search or fetch for cases where a raw feed URL isn't available. The usage signal is implied rather than stated.

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

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

Beyond the readOnly/openWorld annotations, it discloses ad-free results, multi-engine automatic fallback, a 10-minute cache, per-call pricing ($0.005), and the x402 payment mechanism (USDC on Base or Solana). These are exactly the operational facts an agent needs before invoking a paid, cached, open-world call.

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

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

Front-loaded with the core result shape, then follow-up tool, caching, and pricing in short declarative sentences. Every sentence carries distinct information; nothing is padded or restated 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?

No output schema exists, yet the description fully specifies the return shape (title, URL, snippet, domain) and result ceiling. Cost, caching, engine fallback, and payment requirements round out everything needed to call and budget for this tool.

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

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

Schema coverage is 75%, and the description adds meaning where the schema is thin: "up to 20 organic results" explains the limit ceiling, and the x402/payment sentence gives context for the otherwise cryptic tx parameter. The query and region parameters are left to the schema, which already documents them adequately.

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

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

States a specific verb and resource ("Searches the public web") and enumerates the returned fields (title, URL, snippet, domain, up to 20 organic results, no ads). The general-web scope implicitly separates it from news_search, wikipedia, and fetch, and the explicit pointer to /api/v1/fetch makes the follow-up path clear.

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 clear usage context: use it to get result links, then pair with /api/v1/fetch to read a result as Markdown. It does not state exclusions (e.g. use news_search for news, wikipedia for encyclopedic lookups), so the agent must infer the boundary against siblings.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the data sources, caching window (15-30 s), supported token categories, and per-call payment cost via x402. This adds substantial operational context, though it does not describe failure modes or payment error handling.

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

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

The description is front-loaded with the core purpose, followed by source details, supported token types, caching, and cost. Every sentence adds useful information without repetition or filler.

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

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

With no output schema, the description lists the relevant returned metrics: price, liquidity, 24h volume, 24h change, FDV, and pool age. It also covers data provenance, caching, and payment cost, which is sufficient for an agent to invoke this simple lookup 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 mint and tx parameters are already documented in the input schema. The description reinforces that lookup is by mint and mentions x402 payment, but it does not add parameter-specific meaning beyond the schema baseline.

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

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

The description clearly states it returns USD price, liquidity, and volume for any Solana token by mint, and names Jupiter and DexScreener as data sources. It is specific about the resource and scope, though it does not explicitly contrast itself with sibling tools such as price, prices, or token_report.

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 Solana token price/liquidity/volume checks and notes it works for new and meme tokens. However, it gives no explicit when-to-use or when-not-to-use guidance versus alternatives like token_report or generic 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?

Annotations already cover safety (readOnlyHint, openWorldHint), but the description adds material behavioral context they cannot: this is a paid call at $0.030, settled via x402 in USDC on Base or Solana, which affects pre-call planning and explains the `tx` payment path. It also enumerates the returned data fields in place of a missing output schema. It does not cover failure behavior for an unknown mint or partial results.

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

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

Two sentences, zero filler: the first front-loads the value proposition and contents, the second carries the pricing/payment term. Every clause earns its place and nothing is repeated between description and title.

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

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

With no output schema, the description compensates by listing the returned fields, and it discloses the payment model needed to invoke it successfully. For a 2-parameter read tool the coverage is nearly complete; only error/edge-case behavior for an invalid or non-Solana mint is unaddressed.

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

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

Schema coverage is 100%, and both parameters (mint, tx) are described in the schema, including the regex pattern and the note that tx is an alternative to the X-Payment-Tx header. The description adds no further meaning to the parameters themselves, so the baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Full Solana token report in one call: risk + price + liquidity', and enumerates exactly what is included (rug flags, mint/freeze authority, holders, USD price, deepest pool, liquidity, volume, FDV). It also distinguishes itself from the underlying /token/risk and /token/price endpoints, so an agent can tell it apart from the token_risk and token_price siblings.

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

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

'in one call' and 'Everything /token/risk and /token/price return' clearly position this as the consolidated alternative to the two sibling tools, giving an agent the selection rationale. It stops short of explicit when-not guidance (e.g. 'use token_price alone if you only need price and want to avoid the higher fee'), which keeps it from a 5.

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

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

Annotations already cover read-only and open-world, but the description adds material behavior the annotations cannot: the result is flags plus an overall risk level, responses are cached for 60 s (relevant for freshness-sensitive decisions), and the call is paid at $0.020 via x402 in USDC on Base or Solana. What it does not explain is the failure mode when payment is absent or the tx parameter is omitted, which is the main remaining 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?

Front-loaded with the purpose, then a compact enumeration of checks, then return shape, caching, and pricing — each clause carries distinct information. The check list is dense but every item is a real signal an agent would use to interpret the risk level, so little is wasted.

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

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

With no output schema, the description correctly takes on the burden of describing the return ('flags and an overall risk level'), and it discloses the two things an agent could otherwise stumble on: caching and per-call payment. It falls short only on payment-failure behavior and on how the overall risk level is derived, which matters for a tool whose whole value is a judgment call.

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

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

Schema description coverage is 100%, so both parameters (mint address, tx as an alternative to the X-Payment-Tx header) are already documented in the schema. The description adds only indirect context by calling this a Solana tool, and says nothing about the payment parameter's role in the x402 flow beyond the price line. 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 ('Rug / scam check for a Solana token') and then enumerates exactly which on-chain signals are inspected (mint authority, freeze authority, Token-2022 extensions, top-10 holder share, DEX liquidity, pool age). The 'Solana' qualifier cleanly separates it from the sibling evm_token_risk without the agent needing to open either schema.

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

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

Usage is only implied — an agent can infer you call this before trusting or trading a token. There is no explicit when-to-use framing, no exclusion such as 'Solana only, use evm_token_risk for EVM chains', and no guidance on what to do when the check is inconclusive. Minimum viable rather than instructive.

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, and the description adds important behavior the agent cannot get elsewhere: a 60-second cache window, a per-call monetary cost of $0.010, and the x402 payment requirement (USDC on Base or Solana). Disclosing that calls are paid and settle via a payment header is exactly the kind of operational fact that prevents failed invocations.

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 compact sentences that are front-loaded with the resource and its contents, then the data source, then caching and price. The opening sentence mostly restates the title, which is a small amount of waste, but nothing else is padding.

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

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

With no output schema, the description usefully enumerates returned fields and the sort order, and it covers payment and caching. The remaining gap is that the three source modes — the core selection mechanism for a tool about promotions versus new listings — are never explained, which matters for a read-only discovery tool an agent will call blind.

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 75%, with inline descriptions for chain ('solana, base, ethereum, bsc, arbitrum, polygon, all') and source ('boosted, latest_boosts or new_profiles'). The description adds nothing about the parameters — it never explains what 'boosted' versus 'latest_boosts' versus 'new_profiles' actually returns, nor the 30-item limit ceiling, nor how the 'tx' parameter relates to the X-Payment-Tx header.

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 and scope: promoted/newly listed tokens from DexScreener, enriched with price, 1h/24h change, volume, liquidity, FDV, pool age and links, sorted by 24h volume. That is far more concrete than the sibling names alone (token_price, token_report, market_overview). It does not explicitly say how it differs from those siblings, which keeps it from a 5.

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

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

There is no when-to-use statement, no exclusions, and no named alternative. An agent seeing this alongside price, token_report and market_overview gets no rule for choosing this one over the others; usage is only inferable from the noun phrase 'trending and newly promoted tokens'.

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

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

Annotations already declare readOnlyHint and openWorldHint, yet the description still adds real operational context: Jupiter as the pricing source, a 15-second cache window, a top-50 truncation limit, and a per-call price of $0.020 with the x402 payment rails (USDC on Base or Solana). What it omits is failure behavior and whether zero-balance mints are included, which keeps it below a 5.

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

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

Three dense sentences with the capability stated first, then the pricing methodology and truncation limit, then caching and cost. No filler and no repetition of the title.

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

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

With no output schema, the description compensates by explaining the shape of the response (priced balances sorted by USD value, capped at 50) and the payment prerequisite. It stops short of covering error cases or what happens on an unpriced or empty wallet, but the essentials for calling it correctly are present.

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 both the address pattern/example and the tx field are already documented in the schema. The description only touches the tx parameter obliquely by describing the x402 payment mechanism, adding no syntax or fallback detail beyond structured data.

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

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

States a specific verb-and-resource pair: it returns a Solana wallet portfolio covering SOL plus all SPL/Token-2022 balances with USD pricing. The Solana scope cleanly separates it from the many evm_* siblings without the agent needing to open any schema.

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 Solana-only scope implicitly tells an agent when to pick this over evm_balance or evm_token_balance, but that routing is left to inference rather than stated. There is no explicit when-not-to-use guidance or named alternative.

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

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

Beyond the readOnly/openWorld annotations, the description discloses caching (1 h), pricing ($0.003 per call) and the x402 payment rails (USDC on Base or Solana), which materially affects invocation planning. It still omits truncation behavior against max_chars and what happens when no article matches.

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

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

Three short, front-loaded sentences: capability, return shape, then operational facts (cache, price, payment). No filler, though the return-field list and payment clause make the second half feel dense relative to the 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?

With no output schema, the description usefully enumerates return fields and the cost/caching model. It is still incomplete for a 5-parameter tool: truncation semantics, language fallback, and not-found behavior are absent from both the description and 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?

Schema description coverage is 40%; the description carries meaning for `q` (best-match lookup, not exact title), `full` (adds plain text), and implicitly `lang` ('in any language'). It says nothing about `max_chars` truncation or the `tx` payment-header alternative, leaving half the parameters to a bare 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 verb and resource ('Finds the best matching Wikipedia article for a query') and enumerates the return fields plus the full-text mode. It is unambiguous about being a Wikipedia lookup rather than a general web search, though it never names the adjacent siblings (search, fetch, news_search) it could be confused with.

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?

When-to-use is only implied: 'Finds the best matching Wikipedia article for a query' and 'full=true adds the plain-text article' suggest the summary-vs-full-text tradeoff. There is no explicit guidance on when to prefer search or fetch instead, and nothing about behavior for ambiguous or missing queries.

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 read-only and open-world annotations, it discloses subtitle-source behavior, best-available language fallback, a six-hour cache, and the per-call price with supported payment rails. These details materially help an agent anticipate freshness, language selection, and invocation cost.

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, front-loaded, and efficiently moves from output contents to language behavior, caching, and price. Its opening sentence largely repeats the title, preventing a perfect conciseness score.

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

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

For a relatively simple external read tool, it covers the output, supported subtitle types, language fallback, caching, and cost, compensating well for the absent output schema. Remaining gaps include behavior when subtitles are unavailable, max_chars truncation semantics, and when payment transaction details are required.

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?

With 80% schema coverage, most parameters are already documented, but the description adds meaningful language-fallback semantics beyond the lang field and payment context relevant to tx. It does not explain the otherwise undocumented max_chars parameter, particularly whether output is truncated and how metadata affects the limit.

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 result: manual or auto-generated YouTube subtitles returned as plain text, optionally with timestamps, plus title and channel. This precise scope also distinguishes it from generic content tools such as fetch and pdf.

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 usage context for obtaining a YouTube video's transcript rather than general page content. It does not explicitly state when not to use it or name an alternative for non-YouTube sources.

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