MoneyTools Tools

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the low bar is met; the description still adds real value by disclosing the outbound fetch target, the legacy agent.json fallback path, and concrete rate-limit/pricing plus API-key credit mechanics. It stops short of describing failure behavior or what a partial/invalid card result 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?

Two tight sentences with zero filler: the validation scope is front-loaded and the pricing/access sentence follows as secondary context. Every phrase earns its place.

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

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

An output schema exists and annotations cover the safety profile, so the description only needs to establish scope, fetch behavior and cost — which it does. The one residual gap is that it never clarifies the url-vs-card input mode or what happens when neither is supplied (both parameters are optional).

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 properties are already documented, and the description adds essentially nothing about them — notably it omits that a card JSON object may be supplied directly instead of a URL, or how the two inputs interact. Baseline 3 applies when the schema carries the parameter burden.

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

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

Specific verb pair (fetch + validate) applied to a named resource (A2A agent card at /.well-known/agent-card.json, legacy agent.json), plus an enumeration of what gets validated (required fields, skills, transport, security declarations). The resource is distinct enough from siblings like openapi_lint, llms_txt_validate and x402_validate, but the description never explicitly contrasts itself 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?

No explicit when-to-use/when-not-to-use statement or named alternative. Usage is only implied by the resource name and the freemium note (10 calls/day free, then $0.002 via HTTP endpoint or X-API-Key credits), which does help an agent judge call budget but not tool selection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds genuinely new operational context the annotations cannot convey: it produces unsigned bytes and cannot sign, and it discloses a quota (10 free calls/day, then $0.001 via HTTP endpoint or X-API-Key credits). Neither point contradicts the annotations.

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

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

Two short sentences with the core purpose front-loaded and cost/dependency terms last. Nothing is repeated from the schema or annotations, and every clause carries information the 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 two-parameter pure-computation tool with an output schema, an annotations-declared safety profile, and a fully described input schema, the description covers purpose, constraint (unsigned only), and cost/quota. Minor remaining gap: nothing about handling of overloaded signatures or tuple/array argument encoding, though the schema example implies the comma/JSON-list form.

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

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

Schema description coverage is 100% and both parameters carry descriptions plus examples, so the schema does the heavy lifting. The description adds only the conceptual framing ('signature' + 'encoded args'), which mildly clarifies the relationship between the two parameters but no format or edge-case detail beyond the schema. 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 and output: 'Build calldata from a function signature and arguments (selector + encoded args)'. The parenthetical tells the agent exactly what artifact is produced, making it clearly the inverse of the calldata_decode sibling. It stops short of naming that sibling, so it is not fully differentiated in-text.

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?

'Unsigned bytes only, for agents preparing a tx for a human or wallet to review' gives an explicit use context: pre-signing construction for human/wallet review. That usefully frames when to use it, but no exclusion or alternative-tool routing is stated (e.g. when to decode rather than encode).

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 a safe, read-only, idempotent, open-world operation, so the safety bar is largely met structurally. The description contributes information the annotations cannot: a free tier of 10 calls/day, then $0.002 per call via the HTTP endpoint or X-API-Key credits — a real operational constraint for a paid-shaped tool. It does not cover failure modes (invalid address, ENS name that doesn't resolve, per-chain errors), 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?

Two sentences, both front-loaded and dense: the capability and its output fields first, then the cost/quota caveat. No filler adjectives, no restatement of the title, and the pricing sentence is clearly separated from the capability sentence so an agent can skim it.

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?

A read-only 2-parameter tool with a full output schema and complete annotations — the description covers the capability, chain scope, and cost model, which is what an agent needs to decide and invoke. The remaining gap is behavioral edge cases (unsupported/obscure chain names in the comma list, ENS resolution only on Ethereum), none of which block a correct first 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 coverage is 100%, so both parameters (address, chains) are already documented with examples, and the description adds no format or syntax guidance beyond restating that the input can be a 0x address or ENS name. It does implicitly confirm the default chain set by listing the seven chain names, which is mildly useful context over the schema's "default all 7". Baseline 3 applies when the schema does the heavy lifting.

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

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

Opens with a specific verb+resource ("Profile an EVM address or ENS name") and enumerates exactly what the profile contains: EOA vs contract vs EIP-7702 delegated, nonce, native balances in USD, primary ENS name, known-contract label. That enumeration is enough for an agent to distinguish it from adjacent siblings such as address_validate (validity only) and ens_resolve (name resolution only).

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

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

Usage is implied by the purpose statement — profile when you need a multi-chain address overview — and the caller is told the chain scope defaults to all seven. However, the description never states when to prefer this over address_validate, ens_resolve, or token_balances, nor does it say what happens if only one chain is wanted versus the full sweep. No explicit exclusions or prerequisites.

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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is free. The description's real additive value is commercial behavior: a 10 calls/day free tier, then $0.001 via HTTP endpoint or X-API-Key credits – an agent needs that to plan usage. It still says nothing about what an invalid address returns (error vs. a validity flag), though the presence of an output schema lowers that burden.

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

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

Front-loaded with the core question the tool answers, then the supported-chain list, then the pricing caveat. Every sentence carries information, though the long parenthetical chain enumeration is dense and could be trimmed. No filler or repetition.

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

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

With rich annotations, a 100% covered single-param schema, and an output schema, most structural burden is already handled; the description adds chain coverage and rate-limit economics. The only real gap is behavior on invalid input, which the output schema likely covers. Sufficient to call correctly on the first try.

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?

Only one parameter exists and schema coverage is 100%, with an example address already in the schema, so the description owes no additional parameter documentation. The chain list hints at what the validator infers, but adds no syntax, format, or constraint detail beyond what the schema 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?

Names a specific operation (validate an address, detect its network) and enumerates exactly which chains/encodings are covered (EVM checksum, BTC legacy/P2SH/SegWit/Taproot, Solana, Cosmos bech32, TON). This clearly separates it from siblings like btc_address or address_profile, which imply chain-specific generation or enrichment rather than cross-chain format checking.

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 'Catches typos before sending' supplies a concrete usage context (pre-transaction sanity check), which is genuinely useful. It stops short of explicit exclusions or naming an alternative tool (e.g., when to prefer address_profile for balance/history), so it does not reach 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 establish readOnlyHint, destructiveHint=false and idempotentHint, so the safety profile is carried structurally. The description still adds real value beyond them: output is explicitly UNSIGNED (never broadcast), plus a concrete rate limit (10 calls/day) and pricing model — details an agent cannot infer 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?

Three tight sentences with the actionable output (unsigned revoke tx) front-loaded and the monetization detail last. The pricing/payment sentence is the least essential part but is short and does inform call planning.

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 annotations and an output schema present, the description does not need to describe return values, and it covers scope, defaults, side-effect profile, and cost. The only thin spot is that it never indicates what makes an approval 'risky' or what determines the ordering/completeness of results.

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 documenting chain/owner/tokens/spenders is already handled structurally and the baseline is 3. The description contributes the otherwise-undocumented default semantics for tokens and spenders, but adds nothing on formats, symbol resolution, or chain-name conventions beyond what the schema examples show.

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 — find risky ERC-20 approvals and return unsigned approve(spender,0) revoke transactions — and names the exact scope (wallet, default token/spender universe). An agent can distinguish this from token_safety_check or token_balances without opening the 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?

Explains the default behavior (common tokens × 20 well-known routers/spenders) and the override path (your own lists), which tells an agent when the defaults suffice versus when to pass tokens/spenders. It stops short of naming alternatives or exclusion conditions, so it is clear context rather than full routing guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is not obliged to restate it. What it does add is genuinely non-obvious operational context: a 10 calls/day free quota, a $0.001 per-call cost afterwards, and two access paths (HTTP endpoint or X-API-Key credits). It does not say what happens when no inputs are supplied, which is the main behavioral 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?

Two sentences, front-loaded with the core conversion and then the distinguishing extras, with the quota/cost caveat placed last where it belongs. The phrasing is dense to the point of being telegraphic ("doubling time" as a bare fragment), which costs a little clarity but nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and the safety annotations are supplied. However, with zero required parameters and six optional ones, the definition never says which combination is valid or what a bare call returns, leaving a real ambiguity for a moderately featured calculator.

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 a 3 is the floor, but the description earns an extra point by framing how parameters combine: projecting earnings over N days with an optional performance fee ties days, principal and feePercent into one coherent operation rather than three isolated numbers. It is still silent on whether apr and apy are mutually exclusive and what the default compounding assumption is.

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 ("Convert APR to APY (or back)") and enumerates the extra capabilities: compounding frequency, earnings projection over N days with an optional performance fee, and doubling time. That is far more specific than the name alone. It stops short of naming or contrasting with a nearby sibling such as unit_convert, so an agent must infer the boundary.

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 "(or back)", which hints that either apr or apy is supplied, and the pricing sentence signals a free tier of 10 calls/day before paid credits. There is no explicit when-to-use / when-not-to-use guidance, no statement that apr and apy are mutually exclusive, and no direction to a sibling converter for plain unit conversions.

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 read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-structured context: a rate/quota model (10 free calls/day), a paid path with HTTP endpoint or X-API-Key credits, and that lookup uses interpolation search, which hints at accuracy characteristics. It does not say what happens for out-of-range timestamps, but the added value over annotations is real.

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 sentences: what it does, what it is for, then cost. Purpose is front-loaded ahead of pricing, and nothing is repeated 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 an output schema present, the description need not explain return values, and it covers scope, use cases and the pricing model. The remaining gap is edge-case behavior -- timestamps before genesis or in the future -- which an agent may plausibly hit for a block-height lookup.

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 carry their own descriptions, including the accepted chain list and the unix-seconds-or-ISO-8601 format, so the schema does the heavy lifting. The description reinforces 'any of 7 EVM chains' and implies the timestamp is treated as an upper bound, but adds no format or edge-case guidance beyond that. 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?

Names a specific verb and resource ('Find the last block at or before a date/time'), scopes it to 7 EVM chains, and the floor semantics ('at or before') distinguishes it cleanly from any range or hash-based lookup among the siblings. An agent knows exactly what it gets back without opening the 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?

Gives concrete use cases -- historical balance queries, snapshots, log ranges -- which tells the agent when this tool is the right one. It stops short of naming an alternative tool or stating when-not to use it, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the description's real contribution is the upstream data source (LI.FI public status API) and the quota/cost model (10 free calls/day, then $0.002 or X-API-Key credits), neither of which is derivable from structured fields. It stops short of saying what happens with an unknown or too-early hash, which is the main behavioral 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?

Compact and front-loaded: the operation and its output fields come first, with the pricing/quota note trailing. The free-tier sentence is arguably two ideas (quota and paid fallback) compressed into one clause, but 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?

With an output schema present, the description needn't detail return values, and it still summarizes the key ones plus the data source and cost model. For a 2-parameter read tool that is close to complete; only edge-case behavior (invalid/unknown hash, not-yet-indexed transfer) 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%, so both parameters are already documented, and the description only restates the required one as 'source tx hash' without clarifying format. It says nothing about fromChain, which the schema itself notes speeds up lookup, so no meaning is added 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 specific verb and resource ('Track a bridge transfer by its source tx hash') and enumerates the result space (pending/done/failed, bridge used, sending and receiving tx with amounts), which is far more concrete than the bare title. The word 'bridge'/'cross-chain' scopes it away from generic single-chain lookups, though it never names the sibling tx_status, so an agent must infer the boundary itself.

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 'by its source tx hash' — it applies when you hold the hash of a bridge deposit transaction — but there is no explicit when-not guidance and no pointer to tx_status for non-bridged transactions. The agent gets context but no exclusions.

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

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

Annotations already declare readOnly, openWorld, idempotent and non-destructive, so the bar is lower, and the description still adds real behavior: HEAD with GET fallback, a hard cap of 12 checks, and the free-tier quota of 10 calls/day followed by $0.003 via HTTP endpoint or X-API-Key credits. It leaves out what happens to the remaining links past the cap and whether timeouts are retried.

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 tight sentences, capability first and commercial terms second, with zero filler. The pricing clause is useful for an agent reasoning about cost but is the least essential part of the text.

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

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

With an output schema present, the description need not explain return values, and all three parameters are documented. For a read-only checker of this complexity the definition covers method, limits and cost; only edge-case behavior past the 12-link cap 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%, so the schema already explains url, limit and the all|internal|external scope. The description reinforces the 12-link cap stated in the limit parameter but says nothing about scope, adding no meaning beyond the structured fields. Baseline 3 applies.

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

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

The description uses specific verbs (extract, check) on a clear resource (links from a page) and enumerates the outputs (status, redirects, latency, broken list). An agent can distinguish it from neighbors like robots_check or sitemap_parse, though the description never names a sibling 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 capability statement — you call it when you want to validate a page's outbound and internal links. There is no explicit when-to-use/when-not guidance and no pointer to alternatives such as url_metadata, http_inspect, or robots_check for overlapping needs.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: the upstream data source (mempool.space public API) and the quota/payment model (10 free calls/day, then $0.001 or X-API-Key credits). It does not mention error behavior for invalid addresses or whether pending balance affects totals.

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, front-loaded with the returned fields before the cost/source clause. Dense but every clause (payload, scope, source, price) earns its place.

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

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

For a one-parameter read tool with annotations and an output schema, the description supplies what structured fields cannot: data source, cost, quota, and the field list. It is nearly complete; only address-validity handling and pagination/caching behavior are unstated, which are minor for this shape.

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

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

There is a single required parameter with 100% schema description coverage, so the schema carries the burden and baseline 3 applies. The description only adds the scope phrase 'any Bitcoin address' — no format, network, or validation constraints beyond what the schema already shows via its example.

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 (BTC balance) plus the exact payload: confirmed and pending balance in USD, tx count, address type and reuse, scoped to any Bitcoin address. An agent can distinguish this from solana_account or address_profile on domain alone without opening the 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 implied rather than stated: an agent infers it should call this when it needs BTC balance data for an address. The pricing/rate-limit sentence ('Free: 10 calls/day; then $0.001...') is a useful cost-consideration cue before calling, but there is no explicit when-not guidance or named alternative among the 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: a free tier of 10 calls/day and a per-call charge of $0.001 via HTTP endpoint or X-API-Key credits, which an agent needs to know before looping on this tool. It stops short of disclosing data source or freshness of the fee estimates.

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, no padding, and the primary output content is front-loaded ahead of the billing note. Every clause carries information an agent would otherwise lack.

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

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

With an output schema present, the description need not enumerate return fields, and the annotations cover mutation risk; what remains is a read-only single-parameter estimator that is well described. The only gap is provenance/freshness of the fee data, which matters somewhat for a time-sensitive pricing tool but is a minor omission.

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 parameter (vbytes, default 141) is fully documented in the schema itself. The description never references the parameter or explains how a custom transaction size changes the returned cost estimate. With the schema doing all the work, baseline 3 applies.

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

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

The description names a concrete resource and granularity: recommended sat/vB for next block, 30 min, 1 hour, and economy, plus a transaction cost estimate in sats and USD. That is far more specific than the name alone. It does not, however, position itself against a plausible sibling such as gas_compare, so an agent must infer that this is the Bitcoin-side specialist.

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: the mention of "what your transaction will cost" suggests calling it before sending a Bitcoin transaction, but there is no explicit when-to-use or when-not-to-use statement. No alternative tool is named or ruled out. The rate-limit/pricing sentence is operational context rather than selection guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new operational context beyond the annotations: a free tier of 10 calls/day and paid access at $0.001 via HTTP endpoint or X-API-Key credits, which is exactly the kind of rate-limit/auth detail agents need. It stops short of explaining error behavior or mode precedence.

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 core capability is front-loaded and the commercial terms follow, so an agent can decide on the first sentence alone.

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

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

An output schema exists, so return values need no explanation, and the tool is simple. The remaining gap is the undefined interaction between end and add plus no note on timezone or holiday-edge handling, which matters for a date calculator.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by mapping the country values to real meanings (Taiwan official calendar, US federal holidays, plain weekdays) rather than the schema's bare 'TW | US | none'. It also clarifies that add takes N business days, which the schema only hints at.

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: count business days between dates, or add N business days, against a named calendar (Taiwan, US federal, or plain weekdays). An agent can identify the operation immediately, though it never distinguishes this tool from the sibling public_holidays 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?

Two modes of use are implied (counting a range via start/end, and offsetting via start/add), which gives usable context. However, there is no explicit guidance on when to choose this over public_holidays or lunar_date, and no statement about what happens if both end and add are supplied.

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?

Goes well beyond the annotations by disclosing the data source (open Sourcify signature DB, matching openWorldHint), the fallback mechanism via caller-supplied ABI/signature, and concrete cost/rate-limit behavior (10 free calls/day, then $0.001 or X-API-Key credits). Annotations already cover safety, and the description adds the operational context an agent needs.

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 action and output, followed by the input fallbacks and then pricing. Every clause carries information an agent needs (source, fallback, cost); 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?

With an output schema present, the description needn't explain return shape, and it covers source, inputs, risk interpretation, and cost. The main remaining gap is failure behavior (e.g., what happens with an unknown selector or undecodable data), which an agent calling with arbitrary calldata 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 coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining that abi and signature exist as alternatives to the Sourcify lookup and including an example risky selector (approve) that hints at typical data values. It stops short of stating precedence when multiple inputs are supplied, so it doesn't fully earn a 5.

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 ('Decode raw EVM calldata') plus the exact output ('function name and typed arguments') and an extra capability (plain-language meaning for risky selectors like approve/setApprovalForAll/permit). An agent can immediately tell this is the decode direction of the calldata operation, distinct from encode/inspect siblings such as abi_encode or tx_explain.

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 a clear usage context ('before signing') and explains the input options: rely on the Sourcify signature DB or supply your own ABI/signature. It does not state explicit exclusions or name a sibling alternative (e.g., typed_data_risk for EIP-712, abi_encode for the reverse direction), so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered; the description adds genuinely new behavior: the response contains only a masked number and the number is never stored. The free-tier quota and paid fallback also set expectations about throttling and cost that annotations cannot express.

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

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

A single dense sentence with the functional content front-loaded and the privacy and cost facts trailing in order of importance. Every clause earns its place; nothing is repeated from the schema 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?

An output schema exists, so return shape need not be explained, and the description still covers the privacy of the return value plus quota/cost. For a one-parameter validation tool this is close to complete, with the only real omission being differentiation from a2a_card_validate.

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 and 100% schema description coverage (including an example value), the schema already does the work of explaining the input. The description adds no format hints (separators, spaces) or validation-caveats for the number field beyond restating the kinds of checks performed, so baseline 3 applies.

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

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

Names the specific checks performed — Luhn checksum, brand detection (with an explicit brand list), and length validation — which is far more informative than the title alone. It does not, however, distinguish itself from the sibling a2a_card_validate, leaving the agent to guess which card-checking tool 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?

There is no explicit when-to-use or when-not-to-use guidance, and no pointer to the obvious alternative a2a_card_validate. The only contextual sentence is about pricing/quota ('10 calls/day; then $0.001 via the HTTP endpoint or X-API-Key credits'), which is cost information rather than usage guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the data provenance/license and a concrete quota model (10 calls/day free, then $0.001 via HTTP endpoint or X-API-Key credits), which tells an agent about rate limits and cost before calling. It stops short of describing unknown-chain-id behavior.

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

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

Two short sentences, front-loaded with the input→output contract and followed by access/pricing terms. Dense but every clause carries information; no filler. The arrow notation is compact rather than verbose.

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

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

An output schema exists, so the enumerated return fields are a bonus rather than a necessity, and the description still covers provenance, cost, and auth (X-API-Key). For a single-parameter read-only lookup this is close to sufficient; only error/not-found behavior and any response-shape caveats are 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 coverage is 100% and the single parameter is already documented as "numeric chain id or common name" with an example. The description's "Chain id →" framing confirms the input semantics but adds no format detail, validation behavior, or fallback rules beyond what the schema states. Baseline 3 applies when the schema carries the parameter documentation.

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

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

The description uses a precise input→output mapping ("Chain id → name, native currency, public RPCs, explorers, CAIP-2 id and a ready wallet_addEthereumChain object") that names both the resource and exactly what comes back. It also cites the underlying dataset (ethereum-lists/chains, CC0), which separates it from siblings like rpc_health or erc20_info that operate on live chains or tokens rather than static registry metadata.

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

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

Usage is only implied: an agent can infer this is the tool for resolving a chain id to registry metadata, and the quota note hints at cost sensitivity. There is no explicit when-to-use/when-not guidance and no named alternative for adjacent tasks (e.g., live RPC probing via rpc_health), so routing must be inferred.

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 the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the rate limit and cost model — 10 free calls/day, then $0.001 via HTTP endpoint or X-API-Key credits — which an agent needs before repeated calls. The reference to an 'HTTP endpoint' is slightly out of place for an MCP tool but still informative.

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

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

A single front-loaded sentence enumerates the capabilities, then a second covers limits and pricing. Dense but well-structured with semicolons; every clause carries information, though the pricing clause is somewhat tangential to invocation.

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

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

With an output schema present, return values need not be described, and the description covers both the conversion and contrast halves of the tool. Minor gap: it does not say whether contrast/luminance results are simply absent when `against` is not supplied, or how invalid color strings are handled.

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

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

Schema coverage is 100%, but the schema descriptions are placeholders ('color', 'second color'). The description clarifies the `against` color is used for contrast evaluation, which adds modest meaning, but it does not state accepted input syntax, case handling, or what happens if `against` is omitted.

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 specific verbs and resources: converting between hex/rgb/hsl/CSS names and hex/RGB/HSL/CMYK, plus luminance, best text color, and WCAG AA/AAA contrast. That is concrete enough to separate it from siblings like unit_convert or number_base, though it never explicitly names an alternative.

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: 'contrast against another color' hints that the optional `against` parameter is what enables the WCAG metrics. There is no explicit when-to-use/when-not-to-use statement or comparison to related conversion tools such as unit_convert or number_base.

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 read-only, idempotent, open-world, non-destructive, so the safety profile is covered; the description goes beyond that with real operational detail — open-data source, automatic proxy/implementation merging, and an explicit free tier of 10 calls/day followed by $0.002 via HTTP endpoint or X-API-Key credits. The remaining gap is failure behavior: it never says what comes back when a contract is unverified or a chain is unsupported, which is the main uncertainty for a Sourcify-backed 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, no filler, and the highest-value information (what it is, where the data comes from, proxy handling) leads before the cost/rate-limit detail. Every clause earns its place.

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

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

With an output schema present, return shape needn't be explained, and the description covers source, proxy merging, and pricing. It falls just short of fully complete because the unverified-contract case and chain-support scope are unaddressed for a tool that can legitimately fail on both.

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 `full`, `chain`, and `address` each documented inline, so the schema carries the semantics and baseline 3 applies. The description adds no argument-level detail — nothing about accepted chain naming conventions or when to set `full` — beyond restating that signature lists are returned.

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 (fetch) and resource (a verified contract's ABI), plus the data source (Sourcify) and the enrichment it performs (proxy resolution, implementation ABI merge, signature lists). The resource is narrow enough that an agent can distinguish it from siblings like abi_encode, contract_read, or proxy_inspect 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 implied rather than stated: fetch this when you need an ABI for decoding/encoding. There is no explicit when-not guidance and no sibling is named as an alternative, even though abi_encode, calldata_decode, contract_read, and proxy_inspect all sit adjacent to this resource. The note that proxy resolution is handled internally is useful context but not 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 already cover readOnly, idempotent, openWorld and non-destructive, so the description is not burdened with the safety profile. It adds real context beyond that: results are decoded, a historical block is optional, and there is a 10 calls/day free tier with $0.001 per call afterwards via HTTP or X-API-Key credits. Rate-limit and cost disclosure is exactly the kind of behavior annotations cannot express.

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 clauses with the core capability front-loaded and the example signature immediately after. The pricing sentence is slightly crammed but it is genuinely actionable information rather than filler. No wasted framing.

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?

Five parameters, three required, all documented in-schema, and an output schema exists so return format need not be explained. The description covers capability, decoding, historical block support and cost model. Only the relationship to sibling read tools 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 every parameter carries its own description and example, so the schema does the heavy lifting. The description restates 'human signature and args' and flags the block as optional/historical, which is essentially duplication of what the schema already declares. 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 and resource: calling any view function via a human-readable signature with args, returning a decoded result. From this an agent knows exactly what the tool does. It does not, however, distinguish itself from nearby siblings such as contract_abi, token_balances, or calldata_decode, so it stops 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 implied rather than stated: the mention of 'view function', 'human signature' and 'optional historical block' hints at when this fits. There is no explicit when-to-use, no when-not-to-use, and no routing toward siblings like token_balances for standard reads or contract_abi for building calldata.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context not in structured fields: the free tier is 10 calls/day, after which calls cost $0.001 via HTTP endpoint or X-API-Key credits — material for an agent deciding whether to call repeatedly. It does not discuss error behavior for invalid expressions, 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?

Two sentences, front-loaded with the capability and followed by the pricing/rate-limit constraint. No filler or repetition of the title. The pricing sentence is slightly tangential to selection but is behaviorally useful, so it earns its place.

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

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

With an output schema present, the description need not explain return shape, and the input semantics are fully covered by the schema. It supplies the extras an agent needs — macro syntax support, arbitrary IANA zones, and the rate-limit/pricing ceiling. Only a note on invalid-expression handling is missing.

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

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

Schema coverage is 100% and each parameter already carries a description and defaults (UTC, 1-50, default 5), so the baseline is 3. The description adds only one piece of extra meaning — that the expression may be a 5-field cron or a macro like @daily — but does not clarify count semantics (does it include the current minute?), so it does not clearly exceed the baseline.

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

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

States a specific verb+resource: computes the next N run times of a 5-field cron expression, with time-zone support and a plain-language rendering. An agent can tell exactly what it gets back. It does not contrast itself with the nearest siblings (time_convert, business_days), 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?

The use case (cron schedule preview) is strongly implied by the name and description, but there is no explicit 'use this when...' guidance, no statement of when another tool is preferable, and no prerequisite notes. Adequate but with a clear gap.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: delimiter/type inference, error-row reporting, and a concrete rate limit (10 free calls/day, then $0.001 via HTTP endpoint or X-API-Key credits). It stops short of describing output shape or how error rows are surfaced, but the quota disclosure is material.

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

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

One compact sentence front-loads the primary direction and enumerates sub-behaviors efficiently, with pricing second. Dense but not wasteful; a little more structure (e.g., separating the commercial note) would read better.

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

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

An output schema exists, so return values need not be explained, and the description covers both directions, inference behavior, and the access/cost model. For a stateless two-way converter this is nearly sufficient; only the precise format of error reporting is 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 all three parameters (input, delimiter, direction) are already documented with defaults marked 'auto'. The description reinforces that both delimiter and direction are auto-detected, which slightly clarifies the defaults, but adds no format or syntax 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 both conversion directions with their concrete behaviors (auto delimiter, headers, typed values, error rows), so the agent knows exactly what operation this performs. It does not distinguish itself from nearby siblings like yaml_json_convert or json_format, leaving the agent to infer the boundary.

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 by the input formats ('CSV text or JSON array' vs a YAML tool or a pretty-printer), and the free-tier/quota note hints at cost-sensitive usage. There is no explicit statement of when to prefer this over yaml_json_convert or json_format, and no prerequisites or exclusions.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description adds substantial new information: the underlying rate sources, the daily (i.e. stale-by-design) refresh cadence, an attribution obligation, and concrete rate limits with pricing and the X-API-Key credit path. Those economics and staleness constraints are exactly what an agent needs to avoid surprise failures or misuse.

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 and sources first, the important caveat ("Not tradable quotes") second, and the cost/limit model last. Every clause carries operational weight, and nothing is 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 an output schema present, return-shape explanation is unnecessary, and the description covers provenance, freshness, cost, and disclaimer well. A minor gap remains around how multiple `to` codes and the default amount are reflected in the response for multi-target conversions.

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 from/to/amount semantics are already documented in structured form. The description only reinforces "fiat amounts" and the multi-currency nature of `to`; it adds no formatting or syntax 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?

"Convert fiat amounts with daily reference rates" gives a specific verb, resource, and scope, and the rate provenance (ECB via Frankfurter, ExchangeRate-API for e.g. TWD) makes clear this is reference data, not market data. That cleanly separates it from siblings like unit_convert, color_convert, time_convert, and dex_price.

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

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

"Not tradable quotes" is an explicit when-not that steers agents away from pricing/trading use cases, and the fiat-only scope is clear. It stops short of naming an alternative (e.g. dex_price for on-chain prices, unit_convert for non-currency units), so routing to the right sibling still requires inference.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description adds real context beyond them: KyberSwap as the quote source, that it is a quote and not an executable swap, and explicit rate/cost limits (10 free calls/day, then $0.002 via HTTP or X-API-Key credits).

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

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

A single front-loaded sentence carries the core purpose, outputs, and quote-only caveat, followed by one short sentence on cost. No filler or restated title 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 an output schema present, return structure needn't be explained, and the description covers source, denomination, impact sizing, and rate limits for a 3-parameter read tool. A small gap remains around how the DefiLlama deviation should be interpreted or what happens when no route exists.

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% — chain, token, and sizeUsd are all documented, including the default size. The description reinforces that sizeUsd controls the price-impact check and that pricing is in USDC, but adds little beyond the schema's own wording, 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-style resource: the executable-style USDC price of any ERC-20 derived from DEX aggregator quotes, plus price impact, route DEXes, and deviation vs a DefiLlama reference. This clearly distinguishes it from siblings like erc20_info (token metadata), token_safety_check (risk), and chain_info (network data).

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

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

The description implies the use case (get a size-dependent price with route and cross-reference deviation), but never states when to prefer it over alternatives or what it should not be used for. The 'quote only' note hints at a boundary (no execution), yet no sibling is named or excluded.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral facts the annotations cannot express: transport is DNS-over-HTTPS, output includes a DNSSEC flag and misconfiguration detection, and there is a concrete rate limit (10 free calls/day) with a stated paid fallback of $0.001 via HTTP endpoint or X-API-Key credits — exactly the cost/limit context an agent needs before looping 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?

Two tight sentences with no filler; the record-type/feature scope is front-loaded and pricing is correctly relegated to the second position. The first sentence is a telegraphic fragment without a verb, which slightly slows comprehension but wastes no tokens.

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

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

An output schema exists so return values need no explanation, and annotations plus pricing cover the operational profile. However, it omits mechanics an agent would want: whether DKIM detection uses a default selector or requires one (no selector parameter exists), what 'common misconfigurations' checks actually run, and default record types when 'types' 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 coverage is 100% and both parameters carry their own descriptions ('comma list, e.g. A,MX,TXT' and 'hostname'), so the schema does the heavy lifting. The description only echoes this by saying 'or chosen types', adding no syntax or default behavior beyond the schema (e.g. what types are queried when 'types' is omitted).

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 enumerates the concrete resource scope — A/AAAA/CNAME/MX/TXT/NS/CAA record types plus DNSSEC and SPF/DMARC/DKIM signals — so an agent knows exactly what data comes back. It stops short of naming the action verb ('look up') and never distinguishes itself from the sibling tools spf_dmarc_check and dns_propagation, which overlap directly with the email-auth and propagation parts of its scope.

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

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

There is no when-to-use guidance, no exclusions, and no reference to the closely related siblings spf_dmarc_check or dns_propagation. The agent must infer from the record-type list alone whether this tool or one of those siblings is appropriate.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive traits, so the description only needs to add context. It does so meaningfully by disclosing the exact resolver set queried and the cost/rate-limit model (10 free calls/day, then $0.002 via HTTP endpoint or X-API-Key credits), which the agent cannot get from annotations. It omits timing/timeout behavior, which is relevant for a propagation check.

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 purpose and the six resolvers are front-loaded in one compact sentence, followed by pricing. Nothing is padding, though the pricing clause mixes in an HTTP-endpoint mention that is marginal for an MCP caller.

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

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

For a two-parameter read-only tool with a full output schema and complete annotations, the description covers purpose, scope of resolvers, and cost. Return-value shape is handled by the output schema; only propagation-timing expectations are left unexplained.

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

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

Schema description coverage is 100% and both parameters (domain, type with its record-type list) are already documented in the schema. The description adds no format, defaulting, or constraint information beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('query 6 public resolvers... compare answers') and even names the resolvers, so the agent knows exactly what is being checked. It never names the sibling dns_lookup, which is the obvious alternative for a single-resolver query, so the differentiation is only implicit.

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 framing question 'has my DNS change propagated?' implies the usage scenario (post-change verification) but does not state when to prefer this over dns_lookup or when it is unnecessary. Usage is inferred rather than instructed.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: free quota, paid credit path, and risk flags for new or near-expiry domains.

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

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

The description is compact and front-loads the returned fields before mentioning flags and pricing. The semicolon-packed phrasing is dense but every element is useful, with little wasted wording.

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

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

An output schema exists, so detailed return-value documentation is unnecessary. The description still gives enough context about the registration fields and risk flags to set expectations, with only minor gaps around error behavior.

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

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

There is a single required parameter with 100% schema description coverage, so the schema already documents the input. The description adds no domain-format or normalization guidance beyond what the schema provides, making the baseline 3 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 specific resource and data domain: registrar, creation/expiry dates, age, status codes, nameservers, and DNSSEC from RDAP. This clearly separates it from DNS-record siblings like dns_lookup or dns_propagation, though it never explicitly names the sibling it is not.

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

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

Usage is only implied by the data fields listed; there is no explicit 'use this when' or 'do not use this for' guidance. An agent can infer it is for registration metadata rather than live DNS resolution, but that inference is left unstated.

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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the free-tier limit of 10 calls/day and the $0.001 credit/API-key fallback, which matters for an agent deciding whether to call this repeatedly. It stops short of describing output shape, but an output schema exists to cover that.

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 accepted formats and their examples, with the operational/pricing caveat trailing where it belongs. Every clause carries information; the pricing sentence is the only element that is adjacent rather than core to the parsing behavior.

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

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

For a two-parameter, single-purpose parsing tool with an output schema and full annotation coverage, the description supplies everything needed to call it correctly: input syntaxes, the optional start-time parameter's purpose, and the cost model. Nothing an agent needs is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns an increment by explaining that 'from' is an optional start time used to derive an end time — meaning the schema's bare 'ISO start time' label does not convey. It also clarifies that 'duration' accepts three distinct syntaxes, not just the single example in the schema.

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

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

States a specific verb ('Parse') and resource ('durations'), enumerates the accepted input formats with concrete examples (P1DT2H30M, hh:mm:ss, '1h 30m'), and names the output forms (seconds, ISO, human). This distinguishes it in practice from siblings like time_convert or unit_convert, though it never names an alternative 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 format list rather than stated: an agent can infer this is the tool for duration strings, and the 'optional end time from a start date' clause hints at the second parameter's use case. There is no explicit when-to-use/when-not guidance or routing to sibling conversion 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 declare read-only, idempotent, non-destructive, open-world, but the description adds real behavioral context on top: no SMTP probing (so the agent knows verification is DNS/heuristic-based, not mailbox-handshake), and concrete rate/cost limits of 10 free calls per day then $0.001 via HTTP endpoint or X-API-Key credits. It also honestly labels one output as a 'guess', setting expectations about reliability.

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 capability list so an agent can scan the checks first, followed by the constraint/pricing note. The list of checks is long but each item is actionable; little waste, though the pricing sentence is slightly dense with two payment channels in one clause.

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

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

With an output schema present, the description needn't explain return values, and annotations cover the safety profile, so scope, method limits, and quota/cost are what remain — all covered. The only minor gap is no mention that it handles a single address per call, leaving an agent to infer batch behavior.

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

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

There is a single required parameter with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about the email parameter itself (format expectations, IDN handling, single vs batch), 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 description opens with a specific verb and resource ("Validate an email") and then enumerates the exact checks performed: syntax, MX over DoH, accepts-mail, disposable domain, role account, free provider, and a deliverability guess. An agent knows precisely what the tool returns conceptually. It does not name or contrast any of the closely related siblings (dns_lookup, spf_dmarc_check, domain_rdap), so it falls short of full sibling differentiation.

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

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

Usage is only implied: you call it when you need to validate one email address. The "No SMTP probing" note implies a boundary on how far validation goes, which is useful, but there is no explicit when-to-use versus alternatives such as dns_lookup or spf_dmarc_check, and no guidance on handling a 'deliverability guess' result.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. Beyond that, the description adds real behavioral value: the three possible status outcomes, that expiry and yearly base price are returned, that a registration link is included, and that there is a 10 calls/day free cap with paid HTTP/API-key overage. It does not state error behavior for malformed labels, 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 tight sentences, front-loaded with the core question so an agent grasps the purpose immediately. The slash-separated status list is efficient, though the telegraphic fragment style is slightly choppy and the pricing sentence, while useful, is the least essential element.

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

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

For a single-parameter read-only lookup with an output schema, everything an agent needs is present: what is checked, the possible outcomes, the returned fields, cost/rate limits, and sibling-safe annotations. Return-value details need not be expanded further because an output schema exists.

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

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

Schema description coverage is 100% and the single parameter already documents 'label or label.eth', so the schema does the heavy lifting. The description's 'name.eth' phrasing mildly reinforces that the .eth suffix is handled, but adds no syntax, validation, or normalization 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?

Opens with a specific question-form verb and resource ('Is name.eth available?') and enumerates the answer states it returns (registered / grace period / available). It does not explicitly distinguish itself from the sibling ens_resolve, so an agent must infer that this is the registration-check path rather than the forward-resolution path.

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 question — check availability before registering a name — and the free-tier/pricing note gives practical invocation context. However, there is no explicit when-to-use vs. ens_resolve guidance and no stated prerequisites (e.g., whether a bare label or full name is preferred).

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful operational context: a free tier of 10 calls/day, then $0.001 via HTTP endpoint or X-API-Key credits, plus optional L2 resolution and forward verification.

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

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

The description is two sentences with no wasted wording: the first front-loads the dual-mode purpose, and the second adds the rate-limit and pricing information. It is appropriately sized for a tool with rich schema and 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?

Given the output schema and annotations, the description covers the essential context: forward and reverse ENS resolution, record retrieval, optional L2 addresses, and cost limits. Return-value details are not needed because an output schema exists.

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

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

Schema description coverage is 100%, so the parameter documentation baseline is already satisfied by the schema. The description adds some high-level mapping between name, address, and optional L2 chains, but it does not clarify parameter combinations, mutual exclusivity, or input formats beyond what the schema provides.

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

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

The description states a specific verb and resource: resolving an ENS name to an address or an address to its primary ENS name. It also names the additional records and optional L2 addresses, making the tool's scope distinguishable from a simple availability check or generic address lookup.

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

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

The two resolution directions and optional chain support imply when the tool is appropriate, but there is no explicit guidance on when to use it instead of siblings such as ens_available or address_profile. No exclusions or prerequisites are stated beyond the pricing note.

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, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description nevertheless adds genuinely new context: a rate limit (10 calls/day free) and the paid fallback via HTTP endpoint or X-API-Key credits, which affects retry and batching decisions.

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, no filler: the returned fields lead, and the secondary cost/quota note trails. Every clause earns its place and nothing needs re-reading.

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

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

An output schema exists, so return structure need not be restated, and the read-only profile is covered by annotations; the description is sufficient for correct invocation. The remaining gap is sibling disambiguation against token_balances and token_safety_check for a tool operating in a crowded token-inspection namespace.

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

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

Schema description coverage is 100% and each parameter is documented inline, so the schema carries the semantics. The description's only added value is signaling that holder is optional, consistent with the two-required-parameter contract; it adds no format or validation 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 enumerates the exact data returned (name, symbol, decimals, total supply, owner, paused, proxy detection, optional holder balance) for any ERC-20, so the resource and payload are unambiguous. It does not distinguish itself from nearby siblings such as token_balances, token_safety_check, or contract_read, leaving overlap for the agent to resolve.

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 notes the holder balance is optional, which is implied usage guidance, and discloses the free-tier/cost model. It never states when to prefer this over token_balances or contract_read, nor any exclusion conditions, so the agent must infer routing from the sibling names 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely non-structured behavior: a 10 calls/day free quota and a $0.002 per-call cost with the payment mechanisms named. It does not disclose error behavior or state that omitting holder simply drops the position fields.

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

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

Two short sentences, front-loaded with the returned data before the commercial terms. Every clause carries information; nothing is restated from 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 an output schema present, return values need not be explained, and the description correctly focuses on scope plus cost. However, the telegraphic fragment style leaves real gaps: no statement of what the tool returns when holder is absent, and no error or unsupported-chain behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only marginal meaning, implicitly linking the 'holder' parameter to the returned 'holder's position' and confirming that asset/share price figures are derived from the vault. It gives no format or constraint hints beyond the schema.

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

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

The description names the resource and enumerates the specific facts returned: underlying asset, total assets, share price, deposits open, and holder position. This distinguishes it from generic siblings like contract_read or erc20_info, which don't target ERC-4626 share/asset accounting. It stops short of naming an alternative explicitly, and the verb is implied rather than stated ('Yield vault facts').

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

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

There is no guidance on when to pick this over contract_read, erc20_info, or token_balances, and no note on what happens if the optional holder parameter is omitted. The only conditional content is commercial (free tier limits and pricing), not usage-selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior: decoding falls back to the open Sourcify signature DB when no event signature is supplied, and there is a hard 5000-block window plus a 10 calls/day free tier then $0.002/credit. It does not explain how fromBlock/toBlock interact with the blocks parameter.

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

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

Two tight sentences with the scope limit and decoding behavior front-loaded, followed by cost. No filler, no restatement 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 an output schema, full annotation coverage and 100% parameter documentation, the description only needs to add scope, decoding behavior and cost, which it does. The one gap is how the block-range parameters interact, which an agent may need before calling 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 all seven parameters are already documented, which sets the baseline at 3. The description contributes one real insight beyond the schema — that the event signature is optional because Sourcify auto-resolves it — but says nothing about the overlap between blocks and fromBlock/toBlock.

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: recent events of a contract, bounded to ≤5000 blocks, with decoded output. It is clearly distinct from siblings like contract_read or tx_explain, though it never names an alternative 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?

There is no when-to-use or when-not-to-use guidance and no routing to alternatives such as contract_read for function calls or tx_explain for a single transaction. The only conditional content is pricing and quota, which does not help an agent choose the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely new operational context the annotations do not carry: a 10 calls/day free quota and $0.001 per call afterwards, plus the two payment paths (HTTP endpoint or X-API-Key credits). Return shape is omitted, but an output schema exists, so that gap is minor.

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, with the capability statement front-loaded and the cost caveat trailing. Nothing repeats the title or 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?

For a two-parameter, read-only extractor with full annotation coverage and an output schema, the description covers what is extracted and what it costs, which is what an agent needs to decide to call it. The one remaining gap is how the 'types' limiter interacts with the output, left entirely to 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 100%, so baseline is 3, but the description adds real meaning by naming the entity categories, which are effectively the legal values for the otherwise opaque 'types' comma list. It does not state that 'types' narrows the output or how the names must be spelled, which keeps it below a 5.

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

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

The description uses a concrete verb ('Pull ... out of') plus an explicit enumeration of the resource classes (emails, URLs, EVM addresses, tx hashes, BTC addresses, phones, dates, money, IPs, hashtags, @mentions) applied to 'any text'. That enumeration separates it from near-neighbours like pii_redact, text_stats, or address_validate 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 extraction-from-text context is clear, but there is no explicit when-to-use/when-not guidance and no reference to alternatives such as pii_redact for redaction or address_validate for verifying a single address. The second sentence is about pricing, not about tool selection, so usage is only implied.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured context: a free tier of 10 calls/day, then $0.002 per call via HTTP endpoint or X-API-Key credits, which affects whether an agent should call it. It does not discuss failures (unreachable page, non-feed content) or item ordering beyond 'latest items'.

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 behavior and output shape, followed by cost. No filler, though the pricing sentence is closer to marketing detail than invocation guidance and could be trimmed without loss of call correctness.

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

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

With an output schema present, annotations covering safety and idempotency, and a fully documented 2-parameter schema, the description only needs to establish scope and cost — which it does. The remaining gap is error/edge-case behavior for pages that are not feeds, which is minor for a read-only parser.

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 url ('feed or page URL') and limit ('items 1-50') are already documented, making 3 the baseline. The description's 'or autodiscover it from a web page' reinforces the url dual-purpose but adds nothing about limit or defaults.

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 (parse) and resource (feed: RSS/Atom/JSON), and adds the autodiscovery-from-page variant plus the returned fields (title, items with link, date, summary). This clearly separates it from adjacent tools like sitemap_parse or url_metadata without needing to name 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?

Usage is only implied by the phrasing 'Parse a feed (or autodiscover it from a web page)'. There is no explicit when-to-use/when-not guidance and no named alternative (e.g. sitemap_parse for XML sitemaps) to route the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description goes beyond that with genuinely useful non-schema context: live/current data, a free tier of 10 calls/day, and a $0.001 overage path via HTTP endpoint or X-API-Key credits — an agent needs this to decide whether to batch or repeat calls. It does not name the 7 chains or discuss staleness/caching, which keeps it at 4 rather than 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 sentences, front-loaded with what the tool returns, then the differentiator, then cost/limits. No filler or restatement of the title, and every sentence carries information an agent can act on.

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

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

With an output schema present, the description need not explain return shapes, yet it still summarizes the payload, and it covers defaults, freshness, and rate limits. The main gap is that the seven supported chain identifiers are never named, forcing the agent to guess valid values for the chains parameter or call with no argument.

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

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

Schema description coverage is 100% and the single optional parameter already documents 'comma list (default all 7)'. The description only reinforces the chain scope by saying '7 EVM chains', adding no format, casing, or error-handling detail beyond the schema. Baseline 3 applies since the schema does the heavy lifting.

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

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

The description gives a specific resource (multi-chain gas) and enumerates exactly what is returned: base fee, priority fee, suggested maxFee, and USD costs for transfer, ERC-20 transfer, approve, and DEX swap. The closing line 'Tells you the cheapest chain right now' adds the differentiating angle that separates it from siblings like btc_fees or dex_price.

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

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

Usage is only implied: an agent can infer this is the pre-transaction cost check, and the 'cheapest chain right now' line hints at the comparison use case. However, there is no explicit when-to-use/when-not guidance and no named alternative (e.g. btc_fees for Bitcoin, chain_info or rpc_health for raw chain state), even though those siblings exist and could confuse selection.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds context annotations cannot carry: the free tier (10 calls/day), the $0.001 cost via HTTP endpoint or X-API-Key credits, and the important caveat that JWT decoding is unverified. It omits error behavior and which ops require which optional params.

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, no filler, but the first is an unstructured comma-separated dump mixing hashing, encoding, decoding and address formatting, which is slower to parse than a grouped list. Pricing is correctly placed at the end rather than front-loaded.

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

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

An output schema exists, so return values need no explanation, and the parameters are fully documented. But for a multiop tool spanning a dozen operation families, the description gives no op catalog beyond schema examples and no indication of which parameters are conditionally required per operation, leaving an agent to guess for HMAC, selector and decode ops.

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%, including the enumerated op examples and the inputEncoding values, so the baseline is 3. The description adds only marginal meaning beyond the schema — naming HMAC-SHA256 hints at the purpose of `key`, but it does not map operations to the required parameters (e.g. that `selector` expects a function signature in `input`).

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

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

The description enumerates concrete capabilities (sha256/sha1/sha512/md5/keccak256, function selector, HMAC-SHA256, base64(url), hex, URL encoding, UUIDs, JWT decode, EVM checksum address), so an agent knows exactly what class of operation the tool performs. It does not, however, distinguish itself from siblings that overlap heavily (jwt_inspect, id_generate, number_base, abi_encode), so it stops 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 when-to-use or when-not-to-use statement anywhere in the description. With overlapping siblings like jwt_inspect (also JWT decode) and id_generate (UUIDs) present, the absence of routing guidance is a real gap; only the operation list implicitly hints at applicability.

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 the safety profile (readOnly, openWorld, idempotent, non-destructive), and the description adds substantial context beyond them: main-content extraction with scripts/nav removed, a token estimate in the result, a hard free-tier limit of 10 calls/day, and the paid path ($0.002 via HTTP endpoint or X-API-Key credits). The rate limit and payment requirement are exactly the kind of operational facts annotations cannot express.

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 action and result, then the content-handling details, then commercial terms. The single semicolon-chained sentence is dense but every clause carries information; the pricing clause is the longest and could be trimmed, which keeps this just short of top marks.

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

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

With rich annotations, full schema coverage, and an output schema (so return values need no explanation), the description fills the remaining gaps an agent needs: content filtering behavior, rate limits, and cost/auth requirements. Nothing material for correct invocation is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented in structured form, and the description largely restates them ('public URL', 'or pass HTML'). It does hint that url and html are alternatives, which helps with the ambiguous empty required list, but adds no format, size, or precedence 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?

States a specific verb and resource: fetch a public URL (or accept raw HTML) and return clean LLM-ready Markdown of the main content. It also enumerates what is preserved (headings, links, lists, tables, code) and what is stripped (scripts/nav), which distinguishes it clearly from the inverse sibling markdown_to_html.

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

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

The use case (turn a page into LLM-ready Markdown) is implied clearly, and 'public URL' implicitly excludes authenticated or private pages. However, it never names an alternative (e.g., markdown_to_html for the reverse direction, url_metadata for raw metadata) and gives no explicit when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them with concrete operational context: a 10 calls/day free quota, a $0.002 per-call charge afterward, and the X-API-Key credit mechanism — material facts an agent needs when planning repeated 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?

Effectively two sentences, front-loaded with the action and the payoff, with the enumeration and pricing kept tight. The long header-family list is dense but each item is informative; nothing is obviously padding, though the output enumeration slightly duplicates what the output schema presumably covers.

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

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

With an output schema present, the description need not restate return values, and the small two-parameter input is fully covered by the schema, so the essentials are there. What is missing is sibling differentiation and any note on authentication requirements for paid calls beyond the bare mention of X-API-Key credits.

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

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

Schema coverage is 100% for both parameters ('url' documented as http(s) URL with an example, 'method' documented as GET (default) or HEAD), so the baseline is 3. The description adds no meaning beyond the schema for either parameter — it never mentions the HEAD/GET distinction or any constraints on the URL.

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 ("Fetch a URL") and enumerates exactly what the report contains: status, redirect chain, latency, size, cache headers, CORS, parsed rate-limit headers and a security-headers grade. It does not, however, distinguish itself from close siblings such as security_headers_audit, url_metadata or proxy_inspect, so an agent cannot route between them from the description alone.

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. Given that security_headers_audit, broken_links, robots_check, og_image_check and proxy_inspect all touch adjacent HTTP territory, the absence of any routing hint is a real gap; the pricing sentence is commercial information, 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 already declare readOnly, idempotent, and non-destructive, so the description is not needed for the safety profile. It nonetheless adds context annotations cannot express: 'Not stored' discloses the data-retention behavior, and 'Free: 10 calls/day; then $0.001 via the HTTP endpoint or X-API-Key credits' discloses rate limits and pricing, which directly affect an agent's decision to call it repeatedly.

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, both front-loaded: the first states what is checked and returned, the second states retention and cost. Nothing is repeated from the title or annotations, and 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 an output schema present, the description needn't explain return values, and it correctly avoids doing so while still naming BBAN and print format. For a single-parameter read-only tool, this is near-complete; the only residual gap is how an invalid IBAN is surfaced (error vs. a validity flag), which is reasonably delegated to the output schema.

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

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

Schema coverage is 100% with a single required 'iban' string, so the schema already documents the only parameter and the baseline of 3 applies. The description adds no format guidance beyond what is present — notably it does not say whether the spaced form shown in the example ('GB82 WEST ...') is accepted, leaving that inference to the schema example alone.

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

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

The description states a specific verb and resource ('Check an IBAN') and goes further by naming the exact checks performed ('country length and mod-97 check digits') plus the outputs ('BBAN and print format'). This makes it unmistakable against siblings like card_number_check, phone_format, or address_validate, which validate different resources.

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

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

The description makes the tool's scope clear but never states when to prefer it over an alternative or when it should not be used (e.g. that it validates format/checksum, not whether an account is live). The mention of the free tier implies a cost-based reason to call it sparingly, but that is indirect rather than explicit usage guidance.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false), but the description adds genuinely new behavior: a free tier of 10 calls/day followed by $0.001 per call via HTTP endpoint or X-API-Key credits, plus the fact that decoding yields version and embedded timestamp. It does not mention pagination or output shape, but an output schema exists so that is covered elsewhere.

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, both front-loaded: capability first, then cost/quota. Every clause carries information (formats, count cap, decode output, rate limit, auth mechanism) with no filler or 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?

For a three-parameter, fully optional-argument tool with an output schema, the description covers the modes, the count bound, the decode return semantics, and the commercial/rate-limit constraints. The only gap is that it does not say what happens when no type is supplied, which matters since no parameter is 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?

Schema description coverage is 100%, so the schema already documents type (uuid4|uuid7|ulid|nanoid), count (1-100) and decode. The description restates the type options and the count ceiling but adds no format or syntax detail beyond the schema; its only marginal value is clarifying that decode returns a version and embedded timestamp.

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 specific verbs and resources: generate UUID v4/v7, ULID or nanoid, or decode a UUID/ULID. It also states the two operating modes (generation vs decoding) and the cap on output (up to 100), which lets an agent tell immediately that this is the identifier tool rather than a sibling like hash_encode or number_base.

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: 'or decode a UUID/ULID' signals that the decode path is the alternative mode, and 'up to 100' bounds generation. There is no explicit when-to-use or when-not-to-use guidance and no named alternative tool, though among the siblings none is a close substitute, so the cost of that omission is low.

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, idempotentHint, and destructiveHint already declared, the description adds genuinely new behavioral context: a free tier of 10 calls/day and a $0.001 cost afterward via HTTP endpoint or X-API-Key credits. That rate-limit/cost disclosure is exactly the kind of detail annotations cannot convey, though the description does not state what happens on quota exhaustion (error vs. fallback).

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 with the capability front-loaded, followed by a positioning statement and then pricing. No padding, though the pricing sentence is dense enough that a scanner might miss it if skimming the opening clause.

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-parameter tool with an output schema, the description supplies what the output schema cannot: detection scope, an example, intended use, and cost model. The main residual gap is any note on input normalization or what happens when the quota is exhausted.

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

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

The schema already carries 100% coverage and documents the single parameter as 'domain or URL' with a punycode example. The description confirms punycode input is handled, but adds no syntax, normalization, or edge-case detail (e.g. whether trailing paths or schemes are stripped) 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?

States concrete operations (punycode decoding, mixed-script detection, look-alike character comparison, brand/wallet typo detection) with a worked example ('Cyrillic а vs Latin a'). This clearly separates it from siblings like domain_rdap, dns_lookup, and url_parse_clean, which do not perform look-alike analysis.

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

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

'Anti-phishing for agents' implies the intended use case but gives no explicit when/when-not guidance and names no alternative tool. An agent must infer that this is the right check before domain_rdap or dns_lookup when the concern is impersonation rather than registration or resolution.

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

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

Annotations already cover read-only, idempotent and non-destructive behaviour, yet the description adds real operational context the annotations do not: a 10 calls/day free quota and the paid fallback ($0.001) via HTTP endpoint or X-API-Key credits. What is missing is failure behaviour — what a quota-exceeded or invalid-range call returns.

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 computation and its two variants, then the commercial constraint. No filler and nothing buried.

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?

All five parameters are optional and an output schema exists, so return values need no explanation, and annotations carry the safety profile. The remaining shortfall is that the description never says which parameter combination is required for each mode, leaving a zero-required-parameter tool under-constrained.

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 baseline would be 3, but the description adds genuine meaning by scoping lower/upper to the v3 concentrated case and implying they are unnecessary for the full-range computation. It does not clarify that entryPrice+newPrice and priceRatio are alternative input paths, which is the one 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 computation (LP value vs holding after a price move) and enumerates both supported models, full-range Uniswap v2 and concentrated v3 with lower/upper. No sibling in the list (apr_apy, liquidation_price, dex_price, erc4626_vault) computes impermanent loss, so the boundary is self-evident.

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 two modes imply which inputs to use (bounds for v3, none for v2), but there is no explicit when-to-use statement and no alternative tool is named or excluded. Usage context is inferable 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?

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description pays that back with non-obvious context the annotations don't carry: a 10 calls/day free quota and paid overage via HTTP endpoint or X-API-Key credits, which matters for rate-limit planning. It says less about whether split and contains can be combined in one call or how the result is structured.

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 capability list before the commercial terms; no filler. The enumeration is compressed to near-telegraphic style, which slightly hurts scanability but wastes nothing.

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?

A three-parameter, read-only calculator with a rich output schema and full annotation coverage needs little more; the capability list plus quota note is nearly sufficient. The remaining gap is the interaction semantics between the optional split and contains parameters, which an agent would need in order to call it confidently in one shot.

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 defines all three parameters, and the baseline is 3. The description does add framing—'contains-check' for the IP test and 'subnet split' as a distinct operation producing subnets—but it does not state whether split and contains may be supplied together or how they interact when both are present.

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?

Opens with a specific verb+resource pair ('IPv4/IPv6 subnet math') and enumerates the exact computed outputs: network, range, size, netmask/wildcard, private/reserved type, contains-check, and subnet split. This is distinguishable at a glance from neighbors like ip_owner (whois) or address_validate (format check).

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

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

The operation list implies when the tool applies, and the pricing sentence clarifies the free-tier boundary, but there is no explicit when-to-use/when-not guidance and no reference to competing siblings such as address_validate or ip_owner. An agent must infer the choice rather than being routed.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing a concrete quota and cost model (10 free calls/day, then $0.001, with HTTP endpoint or X-API-Key credits) — real operational context an agent needs before retrying or looping.

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, both front-loaded: the ownership question and returned fields come first, then the cost/quota caveat. No filler, no restatement of the title verbatim, and the most decision-relevant information leads.

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?

Because an output schema exists, the description doesn't need to explain return values, and annotations cover safety. What it does supply — data source, field list, and rate/cost limits — is close to sufficient; the only shortfall is edge-case behavior (invalid or private IPs, failure mode) for a single-parameter lookup.

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

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

There is exactly one parameter and schema description coverage is 100% ('IPv4/IPv6' with an example), so the schema does the work. The description adds nothing about accepted formats (e.g., whether hostnames, private ranges, or CIDR blocks are valid), 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 description names a specific verb and resource — 'Who owns this IP?' — and enumerates the returned data (network name, CIDR, country, organization, abuse contact) plus the source (RDAP). An agent can tell this is an IP-ownership lookup rather than a CIDR calculator like ip_cidr, though it never explicitly contrasts itself with that sibling.

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: the question phrasing signals 'use this when you need IP registration data.' There is no statement of when to prefer this over ip_cidr, dns_lookup, or geo-style siblings, and no prerequisites (e.g., public IPs only) are given. The pricing line hints at volume/cost constraints but is 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?

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds useful non-annotation context: the free quota of 10 calls/day and paid access via HTTP endpoint or X-API-Key credits. It could go further on input limits or error behavior, but it meaningfully supplements the annotations.

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

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

The description is two focused sentences: the first states the core diff behavior and output, the second gives pricing/access constraints. It is front-loaded and contains no redundant wording.

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

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

For a simple two-parameter diff tool with an output schema and rich annotations, the description covers purpose, output components, and pricing/access. It omits explicit usage alternatives and does not note that the schema restricts inputs to objects, but the structured fields fill most remaining gaps.

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

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

Schema coverage is 100%, and the schema already documents both parameters as old JSON and new JSON with examples. The description adds no parameter-specific detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description gives a specific verb and resource: structural diff of two JSON values, with added/removed/changed JSON Pointer paths and an RFC 6902-style patch. This clearly differentiates it from text_diff by operating on JSON structure, but it does not explicitly name or contrast against sibling tools such as json_query or json_format.

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

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

The description explains what the tool does but does not state when to use it versus alternatives such as text_diff, json_query, or json_repair. There is no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious context: validation failures return an error line with surrounding context, and there is a quota/paid-tier model (10 free calls/day, then $0.001 via HTTP endpoint or X-API-Key credits), which an agent needs before retry-looping.

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: the capability list is front-loaded and the commercial terms are compressed into one clause with no filler. The operation list is dense but readable; only the depth/size clause is arguably unearned since no parameter backs it.

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

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

With an output schema present, the description needn't explain return values, and it covers ops, path syntax, and pricing. The gap is the mapping between advertised capabilities (validate, depth, size) and the schema's op values, which are documented only as 'pretty | minify' — an agent cannot tell how to request validation or metrics from the supplied fields.

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 json, path, op, and sortKeys, and the baseline is 3. The description echoes the path syntax ('a.b[0].c') already shown in the schema example and adds nothing about op values beyond pretty/minify — notably it advertises depth/size measurement without indicating which parameter selects that mode.

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 concrete operations (validate with error line + context, pretty-print/minify/sort keys, depth/size measurement, path extraction) on a specific resource (JSON text), so the agent knows exactly what capability it gets. It stops short of differentiating from nearby siblings such as json_schema_validate, yaml_json_convert, or csv_json_convert, which could plausibly be confused with a general JSON 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?

Usage is implied through the enumerated operations and the example path syntax, giving an agent a reasonable sense of when the tool fits. However, there is no explicit when-not-to-use statement and no pointer to json_schema_validate for schema validation or to the YAML/CSV converters, leaving sibling selection to inference.

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

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

Annotations already cover read-only, idempotent, non-destructive, so the description correctly spends its words elsewhere: the 10 calls/day free tier and the $0.001 per-call charge via HTTP endpoint or X-API-Key credits is real operational context an agent cannot get from the schema. What is missing is failure behavior, e.g. whether a malformed path errors or returns empty.

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 operation and followed by syntax examples, then quota. Dense but every clause carries information; the pricing clause is secondary but legitimately useful for a paid endpoint.

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

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

For a two-parameter tool with a 100% covered schema, an output schema, and annotations carrying the safety profile, the description supplies the two things structured fields lack: the path dialect and the quota/cost model. Error semantics would be a nice-to-have, not a blocker.

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

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

Schema coverage is 100%, so the baseline is 3, but the schema labels are bare ('JSON', 'path') and the description adds genuine grammar detail: dotted access, wildcards a[*].b, negative index a[-1], slices, and filter expressions items[?(@.price>=10)]. That is meaning the schema's single example does not convey.

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 ('Extract values from JSON') plus the mechanism (JSONPath-like path), which distinguishes it from siblings like json_format, json_diff, and json_schema_validate that also take JSON. It stops short of naming those siblings 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?

The extraction framing implies when to use it over formatting or validation tools, but there is no explicit when-to-use or when-not-to-use statement. An agent must infer the boundary from the sibling list.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes beyond them by disclosing the lenient-repair semantics, the return shape (parsed JSON + list of applied fixes), and the quota/cost model (10 free calls/day, then $0.001 via HTTP endpoint or X-API-Key credits). It does not say what happens when repair is impossible (error vs. best-effort output), which is the one behavioral 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 core action, then the defect taxonomy, then the return value and pricing — a sensible order with no filler. The error enumeration is dense but each item carries routing information; the pricing sentence is slightly secondary but operationally relevant for rate-limited use.

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 annotations and an output schema already present, the description only needs to add repair semantics and cost context, both of which it does. The remaining omission is failure behavior and whether repaired output should be re-validated downstream — minor for a single-string 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?

Only one parameter, and schema description coverage is 100% with a concrete malformed-JSON example embedded in the schema. The description adds no meaning beyond that — it never mentions the 'text' input explicitly or constraints on it — so the 3 baseline for a fully documented schema 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 ('Fix broken JSON from LLMs') and enumerates the exact defect classes handled: code fences, leading prose, comments, single quotes, bare keys, trailing commas, Python literals, truncated strings, unclosed brackets. This clearly separates it from sibling tools like json_format (well-formed JSON) and json_schema_validate (schema conformance), which an agent could otherwise confuse with it.

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 enumerated defect list functions as an implicit when-to-use trigger: if the payload exhibits any of those symptoms, this is the tool. What's missing is any explicit exclusion or named alternative (e.g. 'for already-valid JSON use json_format'), so the agent must infer the routing itself.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context: the free tier of 10 calls/day, the $0.001 cost afterwards, and that paid access works via an HTTP endpoint or X-API-Key credits — cost/rate-limit disclosure is exactly the kind of thing annotations cannot express.

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, no filler, with the core action and supported drafts front-loaded before the use case and pricing note. Every clause carries information an agent would act on.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile; the description still adds the useful 'precise error paths' hint and the billing model. A minor gap is that it does not clarify the mismatch between 'JSON value to validate' and the schema's object-only typing of data.

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 data, schema and draft, including the draft enum values and default. The description's parenthetical draft list merely restates the schema, adding no new syntax or format meaning, 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 description states a specific verb and resource ('Validate JSON data against a JSON Schema') and enumerates the supported drafts, which is far more precise than the title alone. It does not explicitly name a sibling such as json_format or openapi_lint to draw the boundary, 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?

'Use it to check tool outputs or API payloads' gives a concrete usage context that an agent can match against a task. There are no exclusions or named alternatives (e.g. when to prefer json_format for pretty-printing), so the guidance is clear but incomplete.

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 readOnly, idempotent, openWorld, and non-destructive, so the bar is lower; the description still adds real value. It names the supported asymmetric algorithms (RS/PS/ES/EdDSA), states no secrets are needed or stored, and discloses a 10 calls/day free quota with $0.002 thereafter. What it omits is what happens with HMAC/HS256 tokens, which cannot be verified via JWKS.

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

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

Three sentences, front-loaded with the decode/verify action, then constraints, then cost. No filler. The pricing sentence is slightly promotional but legitimately informs an agent about quota limits.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers purpose, algorithm support, privacy, and cost. Remaining gaps are edge-case behavior: unsupported algorithms, decode-only mode, and failure/error semantics.

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 a 3 is the baseline, but the description goes beyond the terse schema labels by presenting jwksUrl and discover as two alternative verification paths (external JWKS vs issuer OIDC discovery). It does not state precedence if both are supplied, which caps it at 4.

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

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

States specific verbs and resource: decode a JWT, explain claims (expiry, lifetime), and verify RS/PS/ES/EdDSA signatures against a JWKS URL or OIDC discovery. That is far more precise than the name alone. It does not explicitly differentiate from the sibling signature_verify (or typed_data_risk), which keeps it off 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 context is implied well: pass a token, and either supply a JWKS URL or enable issuer discovery. The 'No secrets needed or stored' line usefully frames the safe case. However, there is no explicit when-not guidance and no routing to the closest sibling (signature_verify) for raw non-JWT signatures.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot express: a free tier of 10 calls/day, then $0.001 per call via the HTTP endpoint or X-API-Key credits — an agent can budget calls accordingly. It stops short of describing accuracy behavior on short inputs, which the schema only hints at.

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

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

One compact sentence with the capability front-loaded and the scope qualifiers trailing in parentheses, so nothing is buried. The pricing clause is useful but appended with a semicolon, making the sentence do two unrelated jobs; a split would read more cleanly.

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

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

For a one-parameter tool with rich annotations and an output schema, the description covers capability, language coverage, and cost — enough for correct invocation without explaining return values. The only omission is any note on behavior with very short or mixed-language input, which the schema touches only as "20+ chars best".

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

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

There is a single required parameter with 100% schema description coverage ("text (20+ chars best)") plus an example, so the schema already carries the semantics and the baseline is 3. The description's mention of 82 languages and Chinese variants relates to output granularity rather than adding meaning to the input parameter.

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

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

States a specific verb and resource ("Detect the language of a text") and immediately qualifies scope with 82-language coverage, ISO 639-3/BCP 47 output codes, and Traditional vs Simplified Chinese disambiguation. An agent can distinguish this from nearby text tools like text_stats or text_diff 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 by the verb — an agent can infer you call this when you need the language of a string, but there is no explicit when-to-use framing, no statement about alternatives, and no prerequisite notes. The pricing sentence describes cost, not selection criteria, so it does not fill the guidance gap.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: a 10 calls/day free tier, then $0.001 per call via HTTP endpoint or X-API-Key credits, plus the 'not advice' limitation. It stops short of describing output shape, though an output schema exists to cover that.

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 capability and mode split, then pricing. The nested parentheticals are dense but readable, and no sentence is pure filler. The pricing clause is tangential to invocation but earns its place as cost context.

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

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

For a 9-parameter calculator with no required fields and an existing output schema, the description covers both operating modes, the field mapping per mode, the returned quantities, and cost/rate limits. An agent has everything needed to choose a mode and construct a valid 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 coverage is 100%, so baseline is 3, but the description adds real meaning by grouping parameters by mode (side/entry/leverage/maintenanceMargin vs collateral/debt/liquidationThreshold) and mapping LT to a health-factor result. That disambiguation is not present in the flat schema, which merely labels each field.

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 computation (liquidation price and distance, plus health factor for lending) and enumerates the inputs each mode consumes, so an agent knows exactly what the tool returns. It never explicitly contrasts itself with siblings like impermanent_loss or apr_apy, but the resource is specific enough to stand apart.

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