robotbase-mcp

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

The description depicts a network-publishing write action ('Relay ... to the network', returns {accepted, txid, chain, relayed}), yet the annotations declare readOnlyHint=true and openWorldHint=false. Broadcasting a signed transaction modifies network/mempool state and reaches an open network, so the read-only/closed-world annotations are contradicted by the described behavior. Despite otherwise rich context (non-custodial, availability flag, rejection handling), the contradiction triggers the rule.

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

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

Front-loaded with purpose and cleanly structured under 'When to use', 'Do not use', 'Returns', and 'Availability' labels, so every section is scannable. Slight redundancy in restating the non-custodial point twice ('we never see a private key' and 'we never hold keys') keeps it just short of perfect.

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 broadcast tool with no output schema, the description covers the interaction model (non-custodial relay), success and failure return shapes ({accepted, txid, chain, relayed} vs {accepted:false, reason}), rejection semantics, and the critical deployment availability gate (RB_ENABLE_BROADCAST=1). An agent has everything needed to decide whether and how to call it.

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

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

Schema coverage is 50%: signed_raw_tx_hex is documented in the schema and 'chain' has an enum but no prose. The description reinforces that the transaction must be already signed locally ('we never hold keys'), adding marginal meaning, but provides no format or constraint details beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Relay an already-signed raw transaction to the network through our own full node') plus the non-custodial scope, and explicitly distinguishes itself from siblings like btc_get_transaction. An agent can tell exactly what this does and what it does 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?

Gives explicit 'When to use' (an agent signed locally and wants a high-availability broadcast) and 'Do not use' cases (build/sign, look up a payment, naming btc_get_transaction as the alternative). Nothing is left to inference.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context: address formats supported and a degraded=true response under index load for ultra-active addresses, though it does not discuss authentication or rate limits.

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

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

The description is compact and front-loaded. Purpose, usage, exclusions, return fields, address support, and the degraded-response edge case are all presented efficiently without 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?

There is no output schema, but the description explicitly lists returned fields: address, confirmed/unconfirmed balance, utxo count and total, tx count, and last 10 transactions. For a one-parameter read tool, this is complete enough to invoke correctly.

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

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

Schema coverage is 100%, so the single address parameter is already well documented. The description adds meaningful detail by listing supported Bitcoin address encodings (P2PKH, P2SH, bech32, bech32m), which helps an agent validate inputs.

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

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

The description clearly states the tool returns balance and activity for a Bitcoin address and notes that no key is involved. It distinguishes this from btc_get_transaction by explicitly directing single-payment lookups there.

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

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

It gives explicit when-to-use cases: reconciling a merchant wallet and checking whether an address received funds or how active it is. It also states what not to use it for and names the sibling tool to use for a single payment.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely new behavior: omitting both params returns the chain tip (a default not visible in the schema), plus the response's field set in the absence of an output schema.

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

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

Three compact clauses (what/default, when, when-not, returns) with the core operation front-loaded. Every sentence carries information; no filler.

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

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

For a 2-param read tool with no output schema, the description covers operation, default behavior, alternative routing, and the returned fields. An agent has everything needed to call it correctly without further documentation.

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; however the description adds parameter-interaction semantics the schema lacks — that height and hash are alternatives and that omitting both selects the chain tip, which is a real usage rule beyond the per-field descriptions.

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

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

States a specific verb and resource ('Bitcoin block summary') plus the two lookup modes and the tip default. It distinguishes itself from btc_get_transaction explicitly, so an agent can route without opening either schema.

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

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

Provides explicit when-to-use ('overview of a block, or confirming which block a payment landed in') and an explicit do-not-use with the named alternative ('to fetch a single payment (that is btc_get_transaction)'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact confirmation-target grid, the named recommended fields, the mempool floor, and the Zcash cross-reference, though it does not mention caching/rate-limit or freshness characteristics.

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 purpose, then cleanly segmented into when-to-use, do-not-use, and returns. Despite its length, every clause carries distinct information (target list, field names, sibling routing) with no filler.

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

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

There is no output schema, so the description compensates by enumerating the returned fields and units (BTC/kvB, sat/vb for the named recommended fields). Combined with the routing guidance, an agent has everything needed to call it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The 'Returns' prose is about output rather than input, which is helpful but not parameter semantics.

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

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

States a specific resource (Bitcoin fee rates) and scope (confirmation targets plus mempool floor) with a clear read verb implied. It explicitly distinguishes itself from btc_get_mempool_state and from Zcash fee handling, so an agent can identify it among siblings without opening a 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 explicit when-to-use ('pricing a Bitcoin transaction, or deciding when a sweep will confirm cheaply') and an explicit when-not-to-use that names the correct alternative ('to measure backlog depth ... that is btc_get_mempool_state'). It also pre-empts a wrong-chain assumption by noting ZEC fees are protocol-fixed.

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, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the derived 'verdict' notion and the returned aggregates; it says nothing about snapshot freshness or whether the values are node-local point-in-time readings. Adequate on top of annotations, but not rich.

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 front-loaded segments: what it is, when/when-not, and what comes back. No filler prose; the dense field list is justified because no output schema exists.

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

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

With no output schema and no parameters, the enumerated return fields (txs, bytes, usage_mb, max_mempool_mb, load_pct, min_fee_btc_kvb, total_fees_btc, verdict) are exactly the compensating information an agent needs, and annotations cover the safety profile.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify beyond confirming it is argument-free.

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 (Bitcoin mempool depth/capacity load) and further pins down what is measured via the 'busy/normal verdict'. It is clearly distinguishable from sibling btc_get_fee_rates, which it explicitly names as the tool for fee choice.

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

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

Explicit 'When to use' (deciding whether now is a good moment to settle on-chain, or sizing the backlog) and an explicit 'Do not use' clause routing fee selection to btc_get_fee_rates. Nothing is left to inference.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false), so the bar is lower. The description adds useful context the annotations do not: that this reports state from 'our node' including local txindex sync status, which matters for deciding whether chain data is reliable. It does not describe pagination or freshness/refresh behavior, so it stops short of 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?

Front-loaded and sectioned (state list, when-to-use, do-not-use, returns), with the routing guidance placed early. The opening enumeration and the 'Returns:' enumeration largely restate the same field set, which is mild redundancy that keeps it from a 5.

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

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

No output schema exists, so the description must carry the return contract, and it does — it names the concrete return keys (difficulty, network_hashrate_hs, chain_tx_count_total, tx_rate_per_s, client, connections, relay_fee_btc_kvb, uptime_s, indexes{}). Combined with the explicit when/not-when guidance, an agent has everything needed to call it correctly.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. There is nothing parameter-specific the description could usefully add, and it correctly does not pad the schema with invented arguments.

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 (get) and resource (Bitcoin network/node state) and enumerates exactly what fields it surfaces: difficulty, hashrate, tx counts, tx/s, protocol version, connections, relay fee, mempool size, uptime, and txindex sync state. This is clearly distinguishable from siblings like btc_get_block or btc_get_mempool_state 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?

Explicit 'When to use' guidance (macro questions about hashrate, chain throughput, node index completeness) and explicit 'Do not use' routing to btc_get_fee_rates and btc_get_mempool_state. The condition that selects each alternative is named, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: it frames the tool as a settlement check and, crucially, enumerates the return payload (confirmations, blockhash, vin_count, up to 12 outputs) even though no output schema exists. It omits rate limits or failure modes for an unknown txid, which keeps it short of 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?

Four compact sentences with zero filler, front-loaded with the core purpose before usage and return details. Each sentence carries distinct information (purpose, triggers, exclusions, return shape).

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

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

With no output schema present, the description compensates by listing the returned fields, and it pairs that with explicit usage boundaries and a single well-documented parameter. An agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100% and the single txid parameter is fully documented in the schema with a hex pattern. The description adds no syntax or format detail beyond that; per the baseline rule for high schema coverage, 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?

Opens with a specific verb+resource ('Look up one Bitcoin transaction by txid') and immediately scopes it ('the core settlement check'). It explicitly names the two nearest siblings (btc_get_block, btc_get_address) and what they cover instead, so the agent can discriminate 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?

Contains an explicit 'When to use' clause framed as concrete questions (has the payment arrived, which block, how many confirmations) plus a 'Do not use' clause routing to btc_get_block and btc_get_address. Both the positive trigger and the exclusions are stated, leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met; the description adds real non-obvious behavior — the served=false-plus-tier fallback path for chains that are not live yet, plus the returned field names in the absence of an output schema. It stops short of covering data freshness/caching or failure modes, keeping it at 4.

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

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

Front-loaded with purpose, then use/do-not-use, then returns; the labeled structure makes it scannable. The return-field list is slightly dense but earns its place since there is no output schema to carry 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?

For a single-enum, read-only status tool with no output schema, the description supplies purpose, routing exclusions, return fields and the one notable edge case — everything an agent needs to select and call it correctly.

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

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

Schema description coverage is 100% and the single enum parameter is fully documented in the schema, so the description adds no param-level detail (no enumeration, no defaults, no notes on invalid ids). Baseline 3 is correct when the schema already carries the parameter semantics.

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

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

States a specific resource and scope ('Live run-time state of one chain's node') and enumerates the exact quantities it exposes (height, peer count, mempool depth, client version), which separates it cleanly from per-chain block/transaction/node-status siblings.

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

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

Explicit 'When to use' framing plus an explicit 'Do not use' list naming three alternatives (btc_get_fee_rates, btc_get_transaction, zec_get_pool_status) with the condition for each. Nothing is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds the return shape and data provenance (CoinGecko), which is genuinely useful, but leaves out rate limits or auth needs, so not a full 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?

Densely front-loaded with purpose, usage, exclusions, and returns in a compact form. Slightly list-heavy but every section earns its place.

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

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

No output schema, but the description enumerates the return object keys, and annotations cover safety. Nothing critical for correct invocation is missing beyond parameter-level detail.

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

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

Schema coverage is only 50% and the description says nothing about 'limit' or 'query'. The lone schema note '(currently informational)' is the only clue, and the description does not compensate for the undocumented limit 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?

Names specific verb+resource: CoinGecko trending coins, top markets, DeFi TVL and Fear & Greed. Clear it's an aggregate market-context tool, easily distinguishable from the on-chain siblings (btc/eth/xmr/zec/tron).

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

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

Explicit 'When to use' cases (what's trending, tokens moving, risk appetite, TVL leaders) and a 'Do not use' exclusion that routes to on-chain settlement tools and price charts. No inference needed to select it.

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

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

Annotations already declare readOnly, idempotent, and closed-world retrieval, so safety is covered. The description adds useful context that the data comes from 'our own node' and lists the exact fields returned, though it doesn't disclose staleness/block-tag behavior (latest vs pending).

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 front-loaded blocks (what it does, when to use, when not to use, returns) with no wasted words. The scope statement leads and the disambiguation follows immediately.

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

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

No output schema exists, but the description enumerates the returned fields (address, balance_eth, nonce, is_contract, code_size_bytes), fully compensating. For a single-param read with annotations covering safety, 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 description coverage is 100% and the single address parameter already documents the '0x + 40 hex address' format. The description adds no further parameter semantics, so baseline 3 applies for a one-param, fully-documented 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+resource ('Ethereum account state') and enumerates exactly what it retrieves: ETH balance, nonce, and contract status. It differentiates itself from siblings by naming eth_read_contract and the risk-scoring tool as out of 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?

Explicit 'When to use' and 'Do not use' sections with concrete alternatives: eth_read_contract with balanceOf for ERC-20 balances, and a separate tool for address risk scoring. An agent knows precisely when to route here.

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 read-only/idempotent/non-destructive profile, so the bar is lower. The description adds genuinely non-obvious behavior: the pruned-history boundary (blocks older than height 15,500,000 return an error, not an empty block), which prevents an agent from misreading a failure as absence of data.

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

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

Front-loaded with the core purpose, then cleanly segmented into when-to-use, when-not-to-use, returns, and boundary. The returns list is long but earns its place given there is no output schema; a minor amount of enumerative bulk.

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

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

With no output schema and no required params, the description compensates by enumerating every returned field and disclosing the historical retention boundary and the hash-precedence behavior. An agent has everything needed to call it and interpret the result.

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 params including the hash-takes-precedence rule. The description's 'number, tag (latest/finalized/safe) or hash' restates the schema's enum-like tags without adding syntax or edge cases beyond the pruned-height note.

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 ('One Ethereum block by number, tag or hash') and enumerates the fields returned, which pins down exactly what the tool is. It explicitly distinguishes itself from the nearest siblings, eth_get_transaction and eth_get_fee_rates.

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

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

Contains explicit 'When to use' scenarios (block fullness, production time, base fee, builder) and explicit 'Do not use' exclusions that route the agent to the correct sibling tools. This is the when/when-not/alternatives pattern at full strength.

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, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuine extra context beyond the annotations: the data source ('our own Reth node') and the scope of what is computed (percentiles over the last blocks, cost of a plain vs ERC-20 transfer). It does not mention freshness/caching or rate limits, 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?

Front-loaded with the resource and data source, followed by compact when/when-not clauses and a return listing. The trailing Returns field list is dense but justified because no output schema exists; nothing is truly 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?

No output schema exists, so the description carries the burden of describing return values, and it does so with concrete field names. Combined with the usage routing and data provenance, an agent has everything needed to call and interpret the tool.

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

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

The tool takes zero parameters, so the baseline is 4. There are no argument semantics to add, and the description correctly focuses on outputs rather than inventing parameter guidance.

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 (Ethereum fee market) and enumerates the exact data returned: base fee, next base fee, priority percentiles, and transfer cost estimates. It explicitly names the sibling tools it is NOT for (btc_get_fee_rates, xmr_get_fee_rates, tron_get_chain_economics), so an agent can select it without ambiguity.

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

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

Explicit when-to-use ('pricing an Ethereum transaction, or deciding what tip gets included quickly') plus an explicit do-not-use clause routing to the correct chain-specific alternatives. Both the positive and negative conditions are named.

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

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

Annotations already mark this as a safe read-only, idempotent operation, so the description goes further: it discloses the 1000-block scan cap, that results are truncated with a flag, and critically that logs come from receipts which only exist for a rolling window (~6 days) with older ranges refused. This is exactly the kind of non-obvious failure boundary 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?

Dense but fully front-loaded and segmented into When to use / Do not use / Returns / Boundary. Every sentence carries distinct information with no filler.

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

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

No output schema exists, but the description enumerates the return envelope (filter, matched, returned, truncated, logs[] fields) and documents the receipt-availability boundary, so an agent has everything needed to call it and interpret 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 the schema already documents all five parameters including defaults, so the baseline is 3. The description restates the address/topic0 filters and the block-range filters but adds little param-level syntax beyond what is 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 and resource ('Ethereum event logs over a block range') plus the optional filters, and implicitly distinguishes itself from eth_get_transaction and eth_get_block. The added decoding detail (ERC-20 Transfer logs decoded to token/from/to/amount) makes the scope unambiguous.

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

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

Explicit 'When to use' with a concrete example ('who moved this token in the last N blocks') and an explicit 'Do not use' naming the alternative (eth_get_transaction) and the constraint against huge ranges. Both the positive and negative cases are spelled out.

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 the read-only/idempotent/non-destructive profile, so the bar is lower, yet the description adds high-value behavior the annotations cannot express: a miss means absent from *our* node only and is never proof of non-existence, plus the index boundary (hash index from block 26,170,371, receipts covering a rolling ~6 days). This preempts the most likely misinterpretation of a negative result.

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

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

It is dense and front-loaded: purpose first, then when-to-use, when-not-to-use, return fields, and boundary caveats in that order. Every clause carries information, though the single-paragraph return enumeration makes it read as a wall of text rather than cleanly sign-posted sections.

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

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

With no output schema, the description fully enumerates the return fields (found, status, block_number, from, to, value_eth, gas_used, fee_eth, confirmations, finalized, erc20_transfers[]) and covers the miss semantics and index-window boundaries. An agent has everything needed to call it and interpret the result.

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 parameter with 100% schema coverage, and the schema already documents the '0x + 64 hex' format. The description only implies 'by hash' and adds no format or validation detail beyond the schema, so the baseline 3 is appropriate.

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

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

The description names a specific verb (check) and resource (Ethereum transaction by hash) and enumerates exactly what is reported: success/reverted status, gas used, fee paid, confirmations, finality, and decoded ERC-20 transfers. This clearly separates it from siblings like eth_get_block and eth_get_logs 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?

It states when to use it ('did this ETH or ERC-20 payment actually settle, is it irreversible, who paid whom and how much') and explicitly routes away when not to use it, naming both alternatives: eth_get_fee_rates for fee estimation and tron_get_transaction for Tron. Nothing is left to inference.

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

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

Annotations already establish readOnly, idempotent and non-destructive, so the safety profile is covered. The description still adds real context - execution by the service's own Reth node, 'Nothing is signed or written', and the return field list - which goes beyond the annotations. No contradiction with openWorldHint=false.

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-loads the core mechanism, then when/when-not, then returns - a good ordering with little waste. Slightly dense with back-to-back parentheticals and a long Returns list, but every clause carries information.

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

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

With no output schema, the description correctly compensates by enumerating return fields (ok, contract, function, selector, output_type, value, value_human). Together with the schema and use-case guidance this is nearly complete for a 7-parameter tool; minor ambiguity remains around how 'function' labels interact with a supplied selector.

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

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

Schema coverage is 86%, so the baseline is 3. The description adds meaning beyond the schema by explaining the two calling modes: built-in ERC-20 function labels versus arbitrary calls requiring a 4-byte selector plus ABI-encoded parameter, which is not stated in the property descriptions.

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

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

States a specific verb and resource ('Read-only (eth_call) against any Ethereum contract') plus the built-in ERC-20 helpers and the raw selector path. This is sufficient for an agent to distinguish it from adjacent read tools like eth_get_account or tron_read_contract 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 explicit when-to-use scenarios ('an on-chain value without trusting a third-party API - a USDT/USDC balance, token decimals, an allowance') and explicit exclusions ('Do not use: to send a transaction, or for a historical balance'). The agent has nothing to infer about 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 declare the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description needn't restate safety. It adds value beyond annotations by disclosing the return payload shape and the tier vocabulary (live|provisioning|planned), which is behavioral context the annotations cannot carry. It stops short of note on freshness/caching or the cost of enumerating the full roster, so not 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?

Front-loaded with the core action, then cleanly segmented into 'When to use', 'Do not use', and 'Returns'. Every clause earns its place, and the routing information is placed ahead of the return detail.

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

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

With no output schema, the description compensates by enumerating the returned fields and the tier enum values, and the sibling routing closes the main ambiguity (list-all vs single-chain status vs capabilities). For a zero-parameter read-only roster tool, 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing to document and no risk of an undocumented argument; the description correctly omits parameter talk.

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 ('List every chain on the RobotBase roster with its state') and immediately scopes it against named siblings chain_status and robotbase_capabilities. An agent can distinguish this tool's job from every nearby roster/chain tool without opening a 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?

Provides explicit when-to-use triggers (which chains are supported, which nodes are online, where to start) and explicit do-not-use routing to two specific alternatives with their own conditions. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety need not be re-explained. The description adds meaningful context beyond that: the Polymarket-primary/Manifold-fallback sourcing behavior and an errors field indicating partial failures. It does not discuss rate limits or data-freshness/caching behind the word 'live', which keeps it below a 5.

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

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

Three labeled segments (purpose, when/when-not, returns) with zero filler and the core purpose front-loaded. The longer returns block earns its space because no output schema exists.

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

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

With no output schema, the description supplies the return shape including nested markets/outcomes and the errors field, plus source fallback behavior. Everything needed to decide to call it and interpret results is present for a 2-parameter read-only 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 50%: 'query' is documented in the schema itself, but 'limit' has only type/bounds/default with no explanation of what it caps. The description's return shape hints at query and count but never explains the limit parameter or how the two interact. Baseline 3 is appropriate when the schema carries roughly half the load.

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

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

States a concrete resource ('live implied probabilities from prediction markets') with named upstream sources (Polymarket primary, Manifold fallback). It also distinguishes itself from siblings crypto_trending and attention_trend by name, so an agent can route without inspecting other schemas.

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

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

Provides explicit when-to-use phrasing ('what does the market think will happen', election/crypto/macro probabilities) and explicit do-not-use cases that point to the correct alternatives. Both the positive and negative selection conditions are stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real context beyond that: the retention-boundary concept, the fact that no RPC endpoint exists so this MCP surface is the only read path, and that it emits an 'honesty note'. It stops short of describing error behavior for unknown chains, so not a full 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?

Front-loaded with the payload summary, then cleanly labeled 'When to use', 'Do not use', 'Returns', and 'Key fact'. Every sentence carries distinct information and none is redundant with the name 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?

There is no output schema, and the description compensates by enumerating the returned row fields (chain, tier, name, client, state, capability) plus fee models and an honesty note. Combined with the clear usage triggers, an agent has what it needs to call and interpret this correctly.

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

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

The tool takes zero parameters, so there is no parameter surface to document; the baseline for a no-param tool is 4. The description correctly implies the call needs no arguments by presenting the result as a whole-surface inventory.

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

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

States a specific resource and scope: per-chain capability, retention boundary, and fee model. It distinguishes itself from the nearest sibling by naming chain_status as the tool for live numbers, so an agent can route 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 explicit when-to-use ('before promising that some query is possible', 'when a tool refused a query as out of range') and an explicit do-not-use with the alternative named ('for live numbers - that is chain_status'). Both the trigger and the exclusion are stated, not 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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds value beyond them by disclosing the return payload shape (services[] {name, ok, detail} plus an overall ok flag), which matters because no output schema exists. It stops short of noting rate limits, caching/freshness of 'live' data, or failure behavior when the gateway itself is unreachable.

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

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

Three dense sentences, all front-loaded: identity first, then when-to-use, then when-not-to-use with alternatives, then the return contract. 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?

For a zero-parameter health-check tool with no output schema, the description supplies everything needed to select and call it: scope, routing rules, and the returned field structure including the overall ok flag. 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The stated return fields are not parameters and correctly do not substitute for 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?

States a specific resource ('live availability of every service behind the RobotBase gateway') and enumerates the services covered (chain nodes, Web3 Agent Hub, AITOKENS, MCP). It also names the two siblings it is not (chain_status, robotbase_capabilities), so the agent can distinguish it 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?

Explicit 'When to use' (overall platform health check, finding which service is down) and explicit 'Do not use' routing to chain_status for single-chain node state and robotbase_capabilities for capability boundaries. Both conditions and alternatives are stated, leaving nothing 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?

Goes well beyond the readOnly/idempotent annotations by disclosing a metered payment model (5 free calls/day per IP, then 0.01 USDC over x402), the absence of an API key, and that the 402 response carries machine-readable terms in structuredContent.accepts[]. That is exactly the kind of non-obvious operational detail an agent needs before calling.

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-loads purpose, then when-to-use, exclusions, returns, and pricing in a scannable sequence with no filler. It is on the long side because it must enumerate return fields and metering, but each sentence carries information.

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

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

With no output schema, the description compensates by enumerating return fields (risk_level, safety_score, hit_flags, malicious_contracts_created, account block, not_covered[], disclaimer), and it covers pricing and failure-mode handling (402 terms). Nothing needed to invoke or interpret it correctly is missing.

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

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

Schema description coverage is 100% and there is only one parameter, so the schema already documents the base58 'T...' address format. The description does not add syntax, validation, or format detail 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?

States a specific verb+resource pairing: 'TRON address risk intelligence' with concrete outputs (judicial/black-market labels, account profile, 0-100 safety score). It is clearly distinguishable from sibling tron_get_account (raw account data) and tron_verify_usdt_transfer (transfer confirmation).

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

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

Explicit 'When to use' with concrete scenarios (OTC settlement, merchant payout, pre-payment sanity check) and an explicit 'Do not use' that names the sibling alternative tron_verify_usdt_transfer for transfer confirmation. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered structurally. The description adds real context beyond that: the data is read 'straight off our own node' (freshness/provenance), and it enumerates the observable state fields including a 'found' flag implying the non-existent-address case is handled rather than erroring. It stops short of describing latency, caching, or error 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?

Content is front-loaded correctly: purpose first, then routing guidance, then return shape. It is dense but nearly every clause earns its place; the only mild excess is the closing return-field enumeration, though that compensates for the absence of an output 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?

With no output schema, the description assumes responsibility for the return contract and does so by listing the key fields (found, address, trx_balance, energy, bandwidth, is_witness, has_code). Combined with the explicit alternative-tool routing, an agent has everything needed to call this correctly.

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

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

There is a single required parameter and schema coverage is 100%, with the schema itself documenting the base58 'T...' or 41-hex address format. The description adds no parameter-level detail beyond that, so the baseline 3 is appropriate.

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

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

States a specific verb+resource (TRON account state read) and enumerates exactly what is returned (TRX balance, activation, energy/bandwidth, witness status, account age). It explicitly distinguishes itself from tron_read_contract and tron_check_address_risk, so an agent can separate it from its nearest siblings 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?

Gives explicit when-to-use conditions ('before sizing a transfer', 'checking whether an address exists on chain') and explicit when-not-to-use cases pointing to the correct alternative tools for TRC-20 balances and risk scoring. Nothing about tool selection is left to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds high-value behavioral context: the node is a lite full node keeping only ~6 days, so an empty result means 'outside our window', not 'block does not exist'. This is exactly the kind of non-obvious caveat 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?

Front-loaded with the core purpose, then cleanly segmented into When to use / Do not use / Boundary / Returns. Dense but every clause earns its place with no filler.

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

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

No output schema exists, yet the description enumerates every return field and flags the retention-window gotcha, plus the no-params-required lookup model. An agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 100% and the schema already documents both params including that block_id takes precedence over height. The description only restates the height/block-id duality without adding format or edge-case detail, 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 and resource (one Tron block by height or block id) and enumerates the returned content (producer, timestamp, tx count by type, tx ids). It clearly distinguishes itself from tron_get_current_block and tron_get_transaction by name.

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

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

Explicitly gives 'When to use' (inspect a specific block, confirm which block a tx landed in) and 'Do not use' with named alternatives for the tip and for transactions. Nothing is left to inference.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds meaningful context beyond them by stating the data comes 'straight off our node' rather than an aggregator, and by enumerating the returned fields despite there being no output schema; it does not mention caching, staleness windows, or rate limits.

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

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

Front-loaded with the resource identity, then usage routing, then returns — a sensible order. The opening sentence's field list is partially redundant with the later 'Returns' enumeration, which costs it a point, but every section still carries selection-relevant information.

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

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

With no parameters and no output schema, the description is the only place an agent can learn the return shape, and it supplies that as a concrete field list (energy_fee_sun_per_unit, transaction_fee_sun, next_maintenance_ms, etc.). Combined with the sibling disambiguation, nothing needed for correct invocation is missing.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description appropriately spends its words on outputs rather than inventing parameter guidance.

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 precise verb+resource ('TRON chain economics') and enumerates the exact quantities returned (energy price, transaction fee, account creation fee, witness pay, maintenance interval, unfreeze delay). It also explicitly disambiguates from the sibling fee tools btc_get_fee_rates and xmr_get_fee_rates, so an agent can select it 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?

Contains an explicit 'When to use' clause (working out transaction cost in TRX, checking resource-market pricing) and a 'Do not use' clause that names the two alternative tools for Bitcoin and Monero fees. Both the positive and negative selection conditions are spelled out.

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, closed-world). The description adds meaningful context: it discloses the metadata scope and the heuristic nature of is_trc20 ('whether it looks like a TRC-20'). It stops short of auth/rate-limit details, but with annotations carrying that load this is solid.

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

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

Front-loaded with the resource, then cleanly sectioned into When/D0-not/Returns. Dense but every clause carries distinct information, especially the Returns enumeration given no output schema. Slightly listy but no wasted sentences.

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

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

With no output schema, the description compensates fully by enumerating all return fields. It covers purpose, selection criteria, exclusions, and output shape — everything needed to call and interpret the tool.

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

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

Single required parameter with 100% schema description coverage, so the schema documents 'address' fully. The description adds no syntax or format detail for the parameter, 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?

States a specific verb+resource ('TRON contract metadata') and enumerates the exact fields returned (name, creator, has_abi, functions, code_hash, is_trc20). This clearly distinguishes it from siblings like tron_read_contract and tron_check_address_risk.

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

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

Provides explicit 'When to use' (before calling a contract, to distinguish unverified from published) and an explicit 'Do not use' with the alternative named (tron_check_address_risk for risk/backdoor analysis). Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds non-obvious behavioral context the annotations cannot: the node serves the tip only and historical blocks are closed/unavailable, which changes how an agent should behave on failure. It does not discuss freshness windows, rate limits, or error semantics, so it stops short of 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?

Front-loaded with the resource, then the use/don't-use routing, then the return fields - a clean information hierarchy with no filler sentences. The dense comma-separated field lists are justified by the absence of an output schema, though it reads slightly list-heavy.

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

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

With no output schema, the description carries the return-value burden and does so by naming the returned fields explicitly. The tip-only limitation is called out, so an agent knows both what it gets and what it cannot get.

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

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

The tool takes zero parameters and the description correctly documents no inputs, so there is nothing to disambiguate. Baseline for a no-parameter tool is 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 a specific verb+resource (current/tip TRON block) and enumerates exactly what it carries: number, id, parent, timestamp, tx count by contract type, and producing witness. It also implicitly separates itself from tron_get_block by framing this as the tip-only read.

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?

Contains explicit 'When to use' (how busy TRON is now, what is in the block being produced, who produced it) and 'Do not use' (fetching older blocks - the lite full node serves the tip only). This is exactly the when/when-not guidance that routes an agent away from tron_get_block.

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 useful behavioral context beyond them: the node is operator-owned and lite, so historical block/transaction APIs are unavailable — an agent knows in advance that some related calls will fail.

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 resource and its fields, then cleanly segmented into when-to-use, when-not-to-use, and returns. No filler sentences; every clause carries information the 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?

There is no output schema, and the description compensates by naming the returned fields (height, solidity_height, solidity_lag_blocks, age_s, tx_in_tip_block, peer_count, client_version) plus what they mean for node health. Nothing needed to call this zero-arg tool correctly is missing.

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

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

Zero parameters, so per the rubric the baseline is 4; the input schema is empty with additionalProperties false and there is nothing parameter-level for the description to clarify.

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 ('TRON node state from our own java-tron full node') and enumerates the exact signals returned: tip height, solidity height and lag, peers, client version, tip-block tx count. This clearly separates it from siblings like tron_get_current_block or tron_get_block, which are about block data rather than node health.

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

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

Explicit 'When to use' and 'Do not use' sections, with the exclusion justified ('this is a lite full node and those APIs are closed'). It does not name a concrete alternative tool for the historical case, so it stops short of the 5-level bar of routing the agent to a specific sibling.

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, idempotent read, but the description adds the critical trait they cannot express: the node is a lite full node with a ~6 day window, so an empty result means 'outside our window', not 'payment missing'. That single constraint prevents a serious false-negative interpretation and is exactly the beyond-schema value this dimension rewards.

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-loads the capability, then uses labeled clauses ('When to use', 'Do not use', 'Boundary', 'Returns') so an agent can scan to the part it needs. Despite being dense, no sentence is redundant and each carries distinct decision-relevant 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?

There is no output schema, and the description compensates by enumerating the returned fields (found, block_number, status, contract_type, owner/to/contract_address, amount_trx, trc20_transfers[], energy_used, confirmations, finalized, retention_window). Combined with the retention-window caveat, an agent has everything needed to call it and interpret results correctly.

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

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

Schema description coverage is 100% for the single txid parameter ('64 hex char Tron transaction id'), so the schema already documents it. The description adds only 'by txid', and its field list ('found, block_number, status...') describes the return rather than the parameter, so baseline 3 is correct.

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 ('One Tron transaction by txid') and immediately enumerates what the caller learns: success/reverted, energy used, the call made, and decoded TRC-20 transfers. It names the siblings it is not for (tron_check_address_risk, tron_get_block), so an agent can distinguish it 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?

Explicit 'When to use' framed around a concrete task (did this USDT payment land, for how much, from whom, is it finalized), explicit 'Do not use' with the two sibling alternatives named, and an additional fall-back rule for empty results. Nothing about selection is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the return shape and the semantic note that proposals carry the parameters they would change, but says nothing about ordering guarantees, pagination, or truncation behavior for the 'top' selection.

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 resource and fields, then cleanly segmented into When to use / Do not use / Returns. Every clause carries information; 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?

With no output schema, the description compensates by enumerating the return structure (total_proposals, by_state{}, top_by_approvals[] and its fields). Combined with annotations covering safety and a fully documented single parameter, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% and the sole parameter (limit, 1-100, default 20) is fully documented in the schema. The description adds nothing about the limit parameter or what 'top' is ranked by, so it is the minimum-viable 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 (governance proposals) and enumerates the returned fields (id, proposer, state, approvals, expiry, proposed parameter changes). It also explicitly contrasts itself with tron_get_chain_economics and tron_list_witnesses, so an agent can distinguish it from all nearby siblings.

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

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

Provides explicit 'When to use' (governance/staking questions, pending chain-parameter changes) and 'Do not use' clauses that name the two alternative tools by name. The selection condition for each alternative is stated, not 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the data is 'read from our own node' and it enumerates the shape of the returned structure. It stops short of pagination/rate-limit or freshness details, so it is strong but not exhaustive.

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

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

Dense but front-loaded: purpose first, then 'When to use', 'Do not use', and 'Returns'. Each clause carries information (purpose, routing, return shape). Slightly long due to the parenthetical field list, but no sentence 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?

No output schema exists, yet the description compensates fully by enumerating the return keys (registered_witnesses, active_block_producers, top_by_blocks_produced[] with address, url, blocks_produced, blocks_missed, votes, in_active_set). Combined with the single well-documented parameter, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% for the single 'limit' parameter, so the schema already documents default 30 and max 200. The description mentions 'top_by_blocks_produced[]' and implicitly that results are top-ordered, but adds no syntax or format 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+resource (list TRON witnesses/super representatives and candidates) and immediately scopes what data it surfaces: block production, misses, votes, websites. It distinguishes itself from siblings by explicitly naming tron_get_account as the tool NOT to use for this purpose.

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

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

Provides an explicit 'When to use' (governance/staking questions, block production health) and a 'Do not use' exclusion routing to tron_get_account. Both the positive and negative selection conditions are stated, leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds material context beyond them: execution on the project's own node, no key involved, and a concrete return shape including energy_used. This is genuinely additive rather than restating the annotation.

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

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

Front-loads what the tool is before the when-to-use/do-not-use routing, and closes with a returns list. Sentences are dense but each carries new information; 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 no output schema, the description supplies the return fields (ok, contract, function, output_type, value, value_human, raw, energy_used), which is exactly the gap it needs to fill. Call contract, argument conventions, and failure modes are all covered.

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 83%, so the schema already documents contract, function, argument, argument2, parameter, and output_type. The description reinforces which TRC-20 helpers exist but adds no syntax or format detail (e.g. hex encoding of parameter) beyond the schema, 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?

States a specific verb (read), resource (any TRON contract), execution model (constant call on our own node), and scope (TRC-20 helpers built in, raw selectors for anything else). An agent can distinguish this from siblings like tron_get_contract or broadcast_raw_transaction without opening a 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?

Has explicit 'When to use' with concrete triggers (USDT balance, token decimals, allowance, any view function) and an explicit 'Do not use' clause that routes writes to a transaction tool and historical lookups elsewhere. The alternatives are named, not 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?

Goes well beyond the readOnly/idempotent annotations: it discloses the ~6 day local-node retention window, the automatic TronGrid fallback for older transactions, the `source` indicator of which backend answered, the guarantee that a local miss is not reported as 'not found', and the full metering model (5 free calls/IP/day, 0.01 USDC over x402, no API key, 402 response carries terms in structuredContent.accepts[]). This is unusually complete behavioral disclosure for a read tool.

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

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

Information-dense but well front-loaded: purpose first, then when-to-use, exclusion, data source, returns, optional params, then metering. No filler sentences, though the exhaustive return-field list is long; it is defensible given there is no output 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?

With no output schema, the description compensates by enumerating the returned fields and the plain-language verdict, and it covers the failure/metering mode (x402 402 response). Nothing an agent needs to call this correctly and interpret the result 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. The description adds real meaning on top: it explains that expected_to and expected_amount_usdt cause the recipient and amount to be matched server-side rather than merely asserting what the fields are, which the schema 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?

Opens with a specific verb+resource+scope: a TRC-20 USDT settlement check performed by transaction id. It enumerates the questions answered (did it land, irreversible, how much, from/to), which an agent can match directly against sibling tools like tron_get_transaction or tron_get_block.

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

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

Explicit 'When to use' clause (confirm a USDT payment before releasing value, closing an automated trade loop) and an explicit 'Do not use' clause routing counterparty assessment to tron_check_address_risk. Both the trigger and the exclusion are named, not 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?

Adds substantial context beyond annotations: the full return object shape, the 10-action cap, that screenshot returns MCP image content, and the metering model (shared 100/day free bucket, then 3 credits/call over x402). There is mild tension with readOnlyHint=true given form-submit/typing capability, but the framing is interaction-with-a-public-page rather than a state-changing API call, so it is not a direct contradiction. A note on what happens when an action fails mid-sequence would complete it.

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

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

Front-loads the core action, then uses labeled 'When to use', 'Do not use', 'Returns', and metering clauses. Dense but every sentence carries operational information; nothing is redundant with the name or 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?

Strong for a complex tool with no output schema: it spells out the return fields (ok, url, final_url, title, markdown, chars, elapsed_ms, screenshot?, xhr?, took_ms, _metering), the action limit, and cost. The remaining gap is how per-action error/failure is surfaced within {ok, ...} and what happens if one of the 10 actions fails.

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 six parameters and their defaults are already documented. The description only restates the 10-action maximum (already in maxItems) and adds that screenshot yields MCP image content; it adds no per-action syntax detail (e.g. selector vs text target for click/type) beyond what the schema 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?

States a specific verb ('drive a real Chromium browser') plus resource ('one public page') and enumerates the interaction primitives: click, type, press keys, scroll, wait for selectors. It explicitly contrasts itself against web_fetch and web_crawl, so the agent can distinguish it from siblings without opening schemas.

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

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

Provides explicit 'When to use' (content hidden behind cookie banners, tabs, 'load more', form submit that web_fetch/web_crawl cannot see) and explicit 'Do not use' (plain reading -> web_fetch, bulk crawling -> web_crawl, no login/paywall bypass). This is the when/when-not/alternatives trifecta.

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/non-destructive, but the description adds material context beyond them: robots.txt compliance, SSRF guards, partial-failure skipping, same-host enforcement, and exact metering terms (shared 100/day free bucket, 3 credits over x402, no API key). This is precisely the behavioral disclosure an agent needs before spending quota.

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

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

Front-loaded with purpose, then labeled When/Do-not/Returns/Behavior/Metering segments. Despite being information-dense, every sentence carries a distinct operational fact with no filler or repetition.

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

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

No output schema exists, yet the description spells out the exact return object shape ({ok, url, final_url, count, pages[...], cached, took_ms, _metering}) and notes partial failures are skipped. Combined with metering and safety notes, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema coverage is 100%, so url, depth, max_chars, and max_pages are already documented. The description reinforces the depth range and page cap but adds no new per-parameter semantics (no guidance on when to choose depth 1 vs 2 or how max_chars affects cost), 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 and resource ('Crawl one site's same-host pages starting from a URL') with scope bounds (depth 1-2, ≤20 pages) and names what it returns. It is immediately distinguishable from web_fetch (single page) and web_map (URL listing) by explicit sibling naming.

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

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

Provides an explicit 'When to use' condition (several pages from one site: docs section, news index, product list, and web_map is insufficient) and an explicit 'Do not use' clause routing single pages to web_fetch and full mirrors away. Alternatives and exclusions are both stated, leaving nothing 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description still adds substantial context beyond them: the metering model (100 calls/day free bucket per IP, then 3 credits per submit over x402), the 24h idempotency-key retry window, and the exact return shape. This is exactly the kind of operational context 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?

Dense but well-structured, with a clear purpose sentence followed by labeled when-to-use, when-not-to-use, returns, and metering sections. No sentence is filler; even the metering note is decision-relevant.

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 only 5 params at full schema coverage, no output schema, and rich annotations, the description is fully sufficient: it tells the agent what happens, how to poll, how to retry idempotently, and what it costs. Nothing needed to invoke correctly is missing.

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

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

Schema coverage is 100%, so ranges and defaults for depth, max_chars, and max_pages are already documented in the schema. The description's note on idempotency_key ('retry safely, 24h window returns same job') largely repeats the schema text, adding little new semantics. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Submit a same-host crawl as an asynchronous job') plus the immediate return of job_id. It clearly distinguishes itself from web_crawl (synchronous), web_fetch (single page), and web_crawl_job (polling) by name.

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

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

Explicitly gives when-to-use (more than a couple of pages, can't hold a long request, then poll web_crawl_job until done/failed/cancelled) and when-not-to-use (one page → web_fetch; need result in this call → web_crawl). The alternatives are named with the condition that selects each.

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

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

Adds real context beyond annotations: free/not metered, rate-limited, the full status object shape, and that a done result matches web_crawl's shape. One residual tension is left unaddressed: readOnlyHint=true while action=cancel stops a running job, so the description should clarify that cancel only terminates the job and does not alter fetched data or crawl results.

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

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

Purpose, when-to-use, when-not-to-use, and return shape are ordered by decision value, with no filler sentences. The inline return-shape list is dense but earns its space given there is no output 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 control tool with no output schema, the description covers the lifecycle, terminal states, progress fields, error field, cost, and rate limiting — everything needed to call it and interpret the response correctly.

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

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

Schema coverage is 100% and the enum already documents 'Poll status (default) or cancel the job', so the description largely restates it via 'poll with action=status' and 'action=cancel to stop a running job'. It adds the polling-until-terminal-state habit, but no format or edge-case detail about job_id beyond what the schema says.

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

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

Opens with a specific verb pair and resource ('Check or cancel an asynchronous crawl job') and ties it back to the creating tool, web_crawl_async. An agent can distinguish it from web_crawl_async, web_fetch, and web_monitor_* 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?

Explicit 'When to use' names the polling pattern and termination states, and explicit 'Do not use' names the two alternatives (web_crawl_async to start, web_fetch for quick single-page reads) with the condition that selects each. The action=status vs action=cancel split is spelled out.

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: discloses the 6h page cache and what fresh=true does to it, that snapshots are persisted per URL in SQLite with only the latest kept, and the metering model (shared 100 calls/day free bucket per IP, then 1 credit via x402). The baseline-persistence side effect is disclosed even though it is arguably a write to internal state; readOnlyHint refers to the external target page, so this is a disclosed nuance rather than a contradiction.

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

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

Front-loaded with purpose, then clearly delimited 'When to use', 'Do not use', and 'Returns' blocks, followed by cache and metering notes. The long return-field list is justified because no output schema exists, and no sentence is redundant.

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

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

For a stateful, metered, cache-coupled tool with no output schema, the description covers the state model, the return shape field-by-field, cache interaction, and pricing. Nothing an agent needs in order to call it correctly and interpret the result 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; the description adds real semantics on top by explaining the behavioral consequence of fresh (cache-busting query vs. comparing cached content) and by tying the tool's core semantics to max_chars-style truncation. It does not add specifics for max_chars itself, keeping it short of 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?

Opens with a specific verb+resource+mechanism: fetch a page now and compare against the previous snapshot of the same URL, returning changed flag and unified diff. It explicitly distinguishes itself from web_fetch and web_extract_schema by name, so an agent can route without opening sibling schemas.

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

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

Has explicit 'When to use' (monitoring prices, docs, policy pages, SEO titles/meta) and an explicit 'Do not use' section naming the two alternative tools and the conditions that select them. It also states the statefulness rule: first call stores the baseline, later calls return added/removed lines.

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

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

Beyond the annotations (readOnly/idempotent/openWorld), the description discloses metering and cost (shared 100 calls/day per IP free bucket, then 1 credit per call over x402) and the caching signal in the response. That is genuinely actionable context an agent cannot get from the annotations.

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

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

Front-loaded with purpose, then use/avoid, then returns, then metering — a sensible ordering. The dense return-shape string is somewhat heavy for a description, though it earns its place given no output schema exists.

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

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

With no output schema, the description enumerates the response shape (ok, url, title, meta subfields, jsonld, tables with caption/headers/rows, links, cached, took_ms) and covers cost. An agent has everything needed to call and interpret the result.

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 url and include_links are already documented. The description adds nothing about parameter semantics; the only hint ('links?') merely mirrors the include_links option in the return shape. 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?

Specific verb and resource ('Extract structured data from one public page') followed by an enumeration of exactly what is extracted (tables, JSON-LD, OG/Twitter/canonical/lang metadata). It is clearly distinguishable from web_fetch, web_metadata, and web_extract_schema by the stated payloads.

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

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

Explicit 'When to use' (page has tables or schema.org JSON-LD needed as data, without an LLM) and explicit 'Do not use' routing to web_fetch for text and web_screenshot for images. Alternatives are named with the selecting condition.

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

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

Annotations only cover read-only/idempotent/open-world, but the description adds materially new context: no-LLM extraction, the Open Graph/meta fallback with matched=false, and the metering model (100/day free bucket then 1 credit via x402). It also documents the return payload shape, which no output schema supplies.

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

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

Front-loaded with purpose, then when/when-not, then returns and pricing in clearly segmented clauses. The returns object listing is dense but each field is informative; nothing is wasted, though the brace dump is borderline 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?

With no output schema, the description proactively supplies the exact response shape, the fallback condition, and cost model for a metered open-world call. An agent has everything needed to invoke correctly and interpret 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 coverage is 100%, so baseline is 3, but the description adds meaning by listing which fields each schema type yields and noting 'auto' detection from JSON-LD types. It slightly exceeds what the enum table conveys without duplicating it.

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

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

States a specific verb+resource ('extract a page's structured data into a named schema') and enumerates the supported schema types, so an agent knows exactly what this returns. It also names the sibling tools it is not (web_metadata, web_extract, web_fetch), making differentiation immediate.

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?

Has explicit 'When to use' with concrete field examples (title/author/date, price/availability, FAQ Q&A) and an explicit 'Do not use' clause naming the alternatives for verbatim JSON-LD and raw text. Routing is fully determined without opening any schema.

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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds context they cannot: the full return shape, that summaries are HTML-stripped and capped at 500 chars, caching behavior via the `cached` field, and metering specifics (shared 100 calls/day per IP free bucket, 1 credit per call over x402, no API key). That is real operational context for a rate-limited external call.

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

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

Front-loaded with purpose, then usage, then return shape, then metering - the order matches how an agent needs to consume it. Every sentence carries distinct information; even the metering line prevents a failed call loop.

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

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

No output schema exists, but the description enumerates the return object's fields, documents the summary truncation, and discloses cost limits - which is everything an agent needs to call this correctly and interpret the result.

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 (url with 2048-char cap, limit 1-20 default 10) are fully documented in the schema. The description adds nothing parameter-specific, 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?

Opens with a specific verb+resource ('Read an RSS or Atom feed and return its latest items') and explicitly names the sibling tools web_fetch and web_map as the wrong choice for adjacent tasks. An agent can distinguish it from every other web_* tool without opening a 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 an explicit 'When to use' condition (user wants latest posts/news, or a feed URL is known and headlines+links are wanted) and an explicit 'Do not use' with the two correct alternatives for article text and URL discovery. Nothing is left to inference.

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

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

Despite annotations already declaring readOnly/idempotent/openWorld, the description adds real operational context: robots.txt compliance, no login/paywall bypass, direct-fetch-then-provider fallback with source=provider, caching, and per-call metering (100 free calls/day per IP, then 1 credit via x402, 402 carries accepts[]). It also describes the return payload in detail even though no output schema exists. The one blemish is an internal conflict: it says responses are 'capped at 12000 characters' while the schema documents max_chars defaulting to 8000, which could mislead about actual truncation 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?

Well front-loaded: what it does, then when, then when not, then returns, then limits/metering — a reader can stop after sentence one. It is dense and slightly overlong on metering detail, but almost every sentence carries information an agent needs; only the pricing sentence could be trimmed.

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

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

There is no output schema, and the description compensates by enumerating the return fields (url, final_url, status, title, content, chars, truncated, fetched_at, source, cached, took_ms) and explaining truncation. It also covers auth ('no API key'), rate/credit limits, and failure path (402 with accepts[]), so an agent can call it and interpret the result without further lookups.

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; url, format and ocr semantics are already fully documented in the schema. The description only adds guidance for max_chars (raise up to 20000 for more content), and that guidance partly contradicts the schema's stated default of 8000 by implying a 12000 cap. Enum for format is documented in the schema, not the description.

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 ('Fetch one public web page') plus the transformation applied (readable text as markdown/plain text, boilerplate stripped). The scope word 'one public web page' immediately separates it from web_crawl, web_map and web_fetch_batch.

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?

Has an explicit 'When to use' clause keyed to having a specific URL, an explicit 'Do not use' list (crawling/mirroring, login-gated or paywalled pages, API/RPC endpoints, book text), and names the correct sibling for the last case (cyberlibrary_get_chapter). That level of routing detail is rare and leaves little inference to the agent.

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

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

Annotations already cover read-only/idempotent/open-world/non-destructive, and the description adds a lot on top: partial failures don't fail the whole call, metering is one call per URL against a 50/day free bucket shared with web_fetch, then 1 credit per URL over x402, max 5 URLs, no API key. This is unusually rich behavioral disclosure.

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

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

Front-loaded with purpose, then labeled 'When to use', 'Do not use', 'Returns', and metering sentences. Dense but every clause is load-bearing; only the metering detail is slightly verbose for a description field.

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

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

No output schema exists, and the description compensates by enumerating the return object fields (ok, count, ok_count, results with url/final_url/status/title/engine/chars/snippet, took_ms, _metering). Combined with metering and partial-failure semantics, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds practical meaning: it explains the ~1200-character snippet length (the max_chars default) and the 5-URL cap in terms of triage use. It does not document the format enum's effect beyond what the schema says.

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

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

States a specific verb (fetch) plus resource (up to 5 public URLs) and the exact output shape (title, engine, ~1200-char snippet), framing the goal as triage. It explicitly differentiates itself from web_fetch and web_map by name.

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 an explicit when-to-use scenario (search returned several candidates, want a first pass) and a named follow-up tool (web_fetch for full text), plus a 'Do not use' clause routing crawls to web_map. Both positives and exclusions are covered.

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

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

Adds substantial context beyond annotations: sitemap-first strategy, same-host link discovery, max 50 URLs, no page content, robots.txt compliance, full return shape, caching, and detailed metering (100 calls/day shared bucket, 1 credit over x402, no API key, 402 accepts[]). Annotations already cover safety, but the description provides the operational behavior 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?

Front-loads purpose, then usage, then return shape, then metering. Every sentence carries actionable information; the metering detail is dense but necessary for a paid tool. No filler.

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

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

Given no output schema, the description explicitly describes the return object fields including urls with source tags, cached, took_ms, and metering. It covers safety boundaries, scope, and cost — everything an agent needs to call correctly.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema. The description repeats the 50-URL limit and URL source behavior, which is marginally useful, but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource (discover URLs of one site) and explicitly distinguishes itself from crawler siblings, naming the exact boundary (max 50, no page content). An agent can identify this tool's job 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?

Provides explicit 'when to use' and 'do not use' sections, naming the alternative pattern (web_crawl) and the robots.txt constraint. It tells the agent both the positive trigger (needing a page list before fetching) and the anti-pattern.

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 cover safety (readOnly, idempotent, non-destructive, openWorld), so the description adds metering and cost behavior: a shared 100 calls/day free bucket across all web tools, then 1 credit per call over x402 with no API key. That is genuinely useful operational context. It omits failure behavior (what happens on non-HTML or blocked pages) and whether 'cached' implies staleness, keeping it below 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?

Front-loads purpose, then labeled When-to-use / Do-not-use / Returns / Metering blocks. Dense but every line carries distinct information an agent needs; no filler sentences.

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 tool, the description covers purpose, routing, the full return shape (compensating for the absent output schema), and metering constraints. Nothing material to 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?

There is only one parameter and schema coverage is 100%, with the schema itself documenting the http(s) URL and 2048-char limit. The description adds no further parameter guidance, 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?

States a specific verb (Extract) and resource (page's structured metadata), then enumerates exactly the field families returned (OG, Twitter cards, canonical, language, JSON-LD). It is clearly distinguishable from web_fetch and web_screenshot by the explicit do-not-use routing.

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

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

Gives a concrete when-to-use condition ('you need title/description/author/image ... or JSON-LD for a product/article, without reading the whole page') and explicit exclusions pointing to named siblings web_fetch and web_screenshot for text and screenshots respectively.

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

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

The description says the tool deletes a monitor and removes its event history, which is a destructive write operation. The annotations declare readOnlyHint=true and destructiveHint=false, directly contradicting the described behavior. Although the description adds useful details like cascade deletion, rate limits, and error behavior, the core mutation semantics conflict with the structured 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 compact and front-loaded: deletion scope and cascade effect come first, followed by usage guidance, return shape, error behavior, and rate limits. Every sentence carries operational value.

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

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

There is no output schema, but the description supplies the return shape, the error case for unknown or foreign ids, cost information, and rate limits. For a single-parameter tool, this is sufficiently complete, aside from the annotation contradiction.

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

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

Schema description coverage is 100%, and the schema already documents that monitor_id is the id returned by web_monitor_set. The description does not add meaningful semantics beyond what the schema provides, so the baseline of 3 for full schema coverage is appropriate.

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

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

States a specific verb and resource: deletes one scheduled change monitor owned by the calling IP, and explicitly notes the cascade removal of event history. This distinguishes it clearly from web_monitor_set and web_monitor_list.

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

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

Explicit when-to-use conditions are given (user no longer needs monitoring, per-IP limit reached), plus an explicit when-not-to-use case with the alternative: there is no pause, so delete and re-create. This is unusually complete 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 read-only/idempotent/non-destructive, and the description adds the traits annotations can't: ownership is scoped to the calling IP, the call is free but rate-limited to 20 calls/min, and passing monitor_id unlocks the last diff. The full return object shape is spelled out. This is genuinely additive behavioral context.

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

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

Front-loaded with purpose, then usage, then returns, then cost — a sensible ordering. The inline return-shape enumeration is dense and slightly heavy, but every element conveys something an agent needs.

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

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

There is no output schema, so the description compensates by enumerating the returned object including nested monitor fields and the events array. With rate limits, ownership scope, and the monitor_id variant all covered, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented; baseline would be 3. The description still adds value by tying monitor_id to the concrete outcome (single monitor plus last_event.diff, up to 4000 chars), which the schema does not state.

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 ('List the scheduled change monitors') with an explicit scope ('owned by the calling IP') and enumerates the returned fields. It also names the siblings it is not (web_monitor_set, web_diff), so an agent can distinguish it without opening a 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?

Explicit when-to-use ('after web_monitor_set, poll this instead of re-fetching') and an explicit 'Do not use' clause naming the correct alternatives for creation and one-off comparison. Nothing is left to inference.

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

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

The description itself is unusually rich — webhook contract (https only, no redirects, 8s timeout, 2 retries at 30s/120s), HMAC signature header, first-check timing, limits (15–1440 min, 5 per IP, 7-day expiry) and metering. However it describes a state-creating operation ('Create... stores a new snapshot and records a diff event') while annotations declare readOnlyHint=true and idempotentHint=true; registering a monitor is a persistent write with quota/expiry consequences. The description is more accurate than the annotation, which limits practical harm, but the conflict 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?

Dense but front-loaded: purpose first, then use/do-not-use, then returns, webhook contract, limits and cost. Every sentence carries operational information, though the single unbroken block would scan better with the labeled sections broken into lines.

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

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

With no output schema, the description still specifies the return shape ({ok, monitor_id, url, status, interval_minutes, next_check_ts, webhook_enabled, ...}), where change events surface (web_monitor_list.recent_events), the baseline timing, and the cost. An agent has everything needed to call this correctly and set expectations.

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

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

Schema coverage is 100% and documents all three params, so the baseline is 3; the description adds genuine meaning on top: webhook must be https with no redirects, the interval bound 15–1440, the max-5-monitors-per-IP cap, and the exact signature header format. What it does not clarify is override/duplicate behavior when the same URL is monitored twice.

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 ('Create a scheduled change monitor for one public URL') and immediately explains the mechanism: re-fetch on interval, store snapshot, record diff event. It also names the siblings it is not (web_diff for a one-shot comparison, web_fetch for a single read), so an agent can discriminate without opening schemas.

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

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

Explicit 'When to use' block with concrete triggers (price, docs, policy page, job post, release notes, 'watch this for me') and an explicit 'Do not use' block routing to web_diff and web_fetch with the selecting condition. This is the textbook when/when-not/alternative structure.

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 readOnly/openWorld/idempotent annotations: real Chromium rendering, robots.txt respect, SSRF guarding, a 3MB per-image cap, and full metering terms (100/day shared free bucket across twelve web tools, then 2 credits via x402, no API key, 402 response carries accepts[]). These are exactly the operational facts an agent needs before calling a network-dependent paid tool.

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

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

Front-loads purpose, then when-to-use, exclusions, return shape, and metering in a logical order with clear labels. It is dense but every clause carries information; the metering sentence is long yet operationally necessary since no API key exists.

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

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

No output schema exists, and the description compensates by naming the return payload: image/jpeg content plus url, final_url, title, width, height, bytes, engine, elapsed_ms, and _metering. Combined with documented failure/metering behavior, an agent has everything needed to call and interpret the result.

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 url, width, height, and full_page are already fully documented with ranges and defaults. The description adds only the implicit 'one public web page' single-URL constraint and no per-parameter meaning, 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?

States a specific verb and resource ('Capture a screenshot of one public web page as an image (JPEG) plus metadata') and explicitly scopes it to a single page. It is clearly distinguishable from web_fetch and bulk-capture siblings, which are named in the exclusion clause.

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 an explicit when-to-use condition ('visual layout matters – a dashboard, chart, UI state') and explicit when-not-to-use cases, naming the alternative for text reading ('use web_fetch'). Login, paywall, and bulk capture are ruled out by name rather than left to inference.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds substantial context beyond them: a SearXNG-first provider chain with automatic Serper/Tavily/bing_rss fallbacks, a 10-minute cache that still bills as a call, and a metering model (100 free calls/day per IP, then 1 credit via x402, no API key, 402 carries accepts[]). These are exactly the operational traits an agent cannot infer from structured 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?

Front-loaded with purpose, then when-to-use, then exclusions, then operational details in a predictable order. Dense and mostly waste-free, though the returns-shape block and the max-count sentence sit slightly awkwardly after the metering discussion.

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

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

There is no output schema, and the description compensates by spelling out the response object, including provider, cached and took_ms fields. Caching, metering, fallback behavior and result limits are all covered, leaving nothing an agent needs in order to call it correctly.

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

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

Schema description coverage is 100%, so every parameter (lang, site, count, query, freshness) is already documented in the schema. The description's only parameter remark, 'max count is 10', restates the schema's 1-10 range and adds nothing new. 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?

States a specific verb and resource (search the live web) plus the exact return shape (title, URL, snippet, published date). It explicitly distinguishes itself from the sibling tools an agent might confuse it with: web_fetch, the on-chain tools, and cyberlibrary_fulltext_search.

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

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

Provides concrete use-case examples in the agent's own voice ('recent Zcash governance proposals'), an explicit ordering rule ('use it before web_fetch, then fetch the one URL that looks authoritative'), and a 'Do not use' section that routes to named alternatives with the condition that selects them.

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 closed-world, so the safety profile is covered. The description adds value by enumerating the exact returned fields (reward_xmr, difficulty, block_weight, orphan, etc.), which no structured field provides. It stops short of describing edge behavior (e.g. what happens if the hash is unknown), so not a full 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?

Labeled 'When to use / Do not use / Returns' structure is front-loaded and scannable, and every sentence carries distinct information with no filler.

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

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

With no output schema, the description compensates by listing the returned fields and identifying the two lookup modes. Nothing an agent needs to select or invoke the tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds only the fact that the lookup can be done 'by height or by block hash', and the precedence rule ('block_hash... takes precedence over height') is already in the schema, so it adds no meaning beyond structured data.

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

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

States a specific verb and resource ('One Monero block header, by height or by block hash') and explicitly distinguishes itself from xmr_get_recent_blocks and xmr_get_transaction. An agent can route correctly 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?

Provides explicit 'When to use' (confirming block for a tx, inspecting reward/difficulty/weight) and 'Do not use' clauses naming the two alternatives. Both positive and negative guidance are present.

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/closed-world, so the safety profile is covered. The description goes beyond them by disclosing data provenance ('read from our own monerod') and the domain-specific behavior that Monero blocks are never full, so the baseline tier normally confirms next block — useful context an agent could not derive from structured 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?

Front-loaded with the core purpose, then structured into When to use / Do not use / Returns blocks. Every sentence carries information — the alternatives, the return fields, and the fee-market caveat all earn their 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 no output schema, the description compensates by enumerating the return fields (baseline_fee_per_kb_xmr plus priority_tiers[] with priority, fee_per_kb_atomic, fee_per_kb_xmr). Combined with the usage routing and provenance note, an agent has everything needed to call and interpret this tool.

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

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

The tool takes no parameters, so there is nothing for the description to clarify at the parameter level; the baseline for a zero-parameter tool applies. The description instead spends its budget on the return shape, which is appropriate.

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

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

States a specific verb+resource ('Monero fee estimate per kB') and adds the structural detail that it is split into ascending priority tiers read from the operator's own monerod. This cleanly distinguishes it from btc_get_fee_rates and eth_get_fee_rates by naming the chain in the purpose 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?

Gives explicit when-to-use triggers (pricing an XMR transaction, deciding whether to pay the baseline fee for next-block inclusion) and explicit do-not-use cases naming the two nearest alternatives (btc_get_fee_rates, xmr_get_mempool_state). Nothing is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds behavioral value by disclosing the returned fields (including a 'congestion verdict') and what the tool is meant to answer, though it does not discuss caching, refresh cadence, or data staleness.

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 resource, then the usage guidance, then the return fields — a logical order with no filler sentences. The trailing field list is slightly dense but every item is informative given there is no output 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?

With no output schema and no parameters, the description compensates by enumerating the return fields and giving a practical interpretation of them. Nothing an agent needs to select or invoke this tool is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and no parameter documentation is required. The description correctly adds no param detail and instead spends its budget on return semantics.

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

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

States a specific verb+resource (Monero mempool state) and enumerates the exact measurements returned: pending tx count, bytes, fees, oldest tx age, double-spend/failing counts. This is clearly distinguishable from siblings like xmr_get_network_stats, xmr_get_fee_rates, or xmr_get_transaction.

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

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

Includes explicit 'When to use' (is the network congested, how long will a new tx wait) and 'Do not use' clauses that name the correct alternatives (xmr_get_fee_rates for fees, xmr_get_transaction for a specific payment). Routing is unambiguous.

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 closed-world, so the safety profile is covered without description help. The description nonetheless adds real behavioral context beyond the annotations: the 720-block aggregation window for emission and fees, and the scope of what state is snapshotted. It does not mention caching or rate limits, which keeps it short of 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?

Front-loaded with the core purpose, then usage, then exclusions, then returns — a clean and scannable ordering. The returns list is fairly long, but it earns its place because no output schema exists.

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

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

With no output schema, the description fully enumerates the returned fields (height, hashrate, difficulty, block size/weight, emission, fees, hard fork info, client version), which is exactly the compensation needed. Combined with annotations and usage routing, an agent has everything required to call it correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description needs to compensate for parameter documentation, and it correctly avoids inventing arguments.

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 ('Monero network-wide state') and enumerates the exact metrics covered: hashrate, difficulty, emission, fees, protocol version, next hard fork. It explicitly distinguishes itself from the sibling xmr_get_node_status, so an agent can pick between them without opening either schema.

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

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

Contains explicit 'When to use' (macro questions about the Monero network) and 'Do not use' clauses, naming the alternative tool xmr_get_node_status for node health. This is the full when/when-not/alternative pattern.

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 closed-world, so the safety profile is covered. The description adds real value beyond that: it enumerates the return fields and states a scope limitation ('RobotBase does not index Monero wallets or ring signatures'), which is useful behavioral context not present in annotations.

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

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

Front-loads the node-state summary, then when-to-use, then when-not-to-use, then returns. The returns enumeration is somewhat long, but since there is no output schema it earns its place; only minor trimming would be possible.

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

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

With no output schema, the description fully compensates by listing the returned fields, and it covers scope, usage, and routing. An agent has everything needed to select and invoke it correctly.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument call and adds no misleading parameter information.

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

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

States a specific verb+resource ('Monero node state') and enumerates the exact facets covered (height vs target, sync flag, difficulty, txpool size, database size, version, peer counts). This clearly differentiates it from siblings like xmr_get_network_stats and xmr_get_mempool_state.

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

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

Provides explicit when-to-use ('whether the XMR node is synced and healthy, or how big its chain and txpool are') and explicit when-not-to-use routing to named alternatives (xmr_get_fee_rates, xmr_get_transaction, xmr_get_network_stats). Nothing is left to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: the monerod distribution data lags the tip by roughly 5,000 blocks, and the response discloses the real height and the lag. That lag caveat is exactly the kind of trait an agent would otherwise get wrong.

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 definition, then usage, then boundary, then returns - a logical order with no filler sentences. It is slightly long and mildly repetitive ('This is the anonymity-set side of Monero that free explorers rarely expose' partially restates the opening), which keeps it off a 5.

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

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

Even without an output schema, the description enumerates the return shape (tip_height, queried_range, data_lags_tip_by_blocks, start_height, outputs_before_start, distribution[]), so an agent knows what it will receive and what the counts mean.

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 document their defaults, so baseline would be 3. The description goes further by explaining why the defaults exist ('default range is 5,010 to 5,000 blocks back') and that the response reports the lag, giving the agent a reason to adjust the range rather than just a syntax.

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

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

States a specific resource and measurement ('how many spendable outputs fall into each ring-size bucket') plus its provenance ('read from our own monerod'), which cleanly separates it from siblings like xmr_get_block, xmr_get_network_stats, and xmr_get_mempool_state. An agent can identify the tool 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?

Explicitly structured as 'When to use: reasoning about Monero privacy - how large the spendable-output set is at a given height' and 'Do not use: to guess a privacy score'. It also names a concrete boundary condition (5,000-block lag) that changes how an agent should call it.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds meaningful context beyond them: that the tool computes an observed interval against a target, and enumerates the returned fields, which is valuable since no output schema exists. It stops short of pagination/rate-limit detail, so not 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?

Front-loaded purpose followed by labeled 'When to use', 'Do not use', and 'Returns' sections. The Returns enumeration earns its length because there is no output schema; 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?

With no output schema, the description compensates by enumerating the return fields, and the when/when-not guidance plus annotation-covered safety profile leave nothing an agent needs missing.

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

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

Schema description coverage is 100% and the single 'limit' parameter is fully documented (default 10, max 50) in the schema. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb+resource (recent Monero blocks) plus the analytical dimension (observed block interval). It explicitly distinguishes itself from xmr_get_block, so an agent can route without opening either schema.

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

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

Provides an explicit 'When to use' (checking normal block production near the 120s target) and a 'Do not use' clause naming the alternative (xmr_get_block) for single-block lookups. Both selection conditions are spelled out.

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/idempotent/non-destructive, but the description adds substantial protocol-level context: outputs and amounts are not recoverable by any third party, only the recipient or tx-key holder can prove a payment. It also enumerates the returned fields, going well beyond the safety profile that annotations cover.

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

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

Front-loaded with the core action and clearly segmented into purpose / when / do-not / returns, so an agent can stop reading early. The long tail of return-field names is informative but dense, keeping it just short of maximum conciseness.

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

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

No output schema exists, yet the description enumerates the full return shape (found, confirmed, in_mempool, block_height, confirmations, double_spend_seen, size_bytes, inputs, outputs, ring_size_per_input, tx_version, unlock_time) plus the fields the protocol withholds. Nothing an agent needs to call or interpret the result 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 the single txid parameter is fully documented in the schema ('64 hex char Monero transaction id'), so the description adds no syntax or format detail. Baseline 3 is appropriate when the schema does the heavy lifting for a one-parameter lookup.

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 ('Look up one Monero transaction by txid') and enumerates the exact questions it answers: mined status, block, confirmations, size, output count, ring size. An agent can distinguish it from xmr_verify_payment or xmr_get_block without inspecting schemas.

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

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

Contains explicit 'When to use' ('did this XMR transfer get into a block, and how deep is it now') and 'Do not use' clauses, with the reason the do-not-apply (Monero hides amounts and parties by design). This is textbook when/when-not guidance that routes the agent correctly.

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 real context the annotations do not: the view key can read but never spend, it is used in a single-use view-only wallet and discarded, and it lists the exact returned fields. It stops short of describing rate limits or failure modes, so not 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?

Front-loaded with the purpose before the when/do-not-use/returns/security sections, and each block is purposeful. It is on the longer side and the 'view-only wallet and discarded' clause is a slight digression, but there is minimal waste.

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

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

For a tool with no output schema, the description enumerates the return fields (tx_count, received_total_xmr, daily[], top_amounts[], transfers[], window.complete) and covers required inputs and the security model. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so all five parameters are documented in the schema, including the 1-2000 limit, 1-30 period_days, and include_pending default. The description only restates the window and view-key facets, adding marginal meaning beyond the schema, which is the correct baseline 3.

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

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

Opens with a specific verb+resource ('Historical incoming-payment ledger for one Monero address, computed with a view key') and immediately scopes what it computes (per-day counts/totals, top amounts, window). An agent can distinguish it from xmr_get_transaction and xmr_verify_payment without opening a 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?

Explicitly states 'When to use' (merchant/treasury reconciliation over a period, which a block explorer cannot do for Monero) and 'Do not use' with named alternatives: xmr_verify_payment for a single tx and xmr_wallet_balance for balances. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses the underlying model (live chain difficulty, tail-emission reward) and enumerates the returned fields, which is meaningful since no output schema exists. It stops short of stating caching/liveness of the chain data or any rate limits, so not a full 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?

Front-loaded with the capability, then clearly segmented into 'When to use', 'Do not use', and 'Returns'. No filler sentences; the Returns block earns its place because there is no output 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 pure read-only computation tool with no output schema, the description covers what it computes, when to use it, when not to, and what it returns. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description implies which inputs matter (hashrate, power price, hardware cost for ROI) but does not clarify the mutual-exclusivity of hashrate_hs/hashrate_khs/hashrate_mhs or default behavior when everything is optional, adding little 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+resource ('Mining profitability calculator') and immediately qualifies it with the data sources ('live chain difficulty and the Monero tail-emission reward'), which distinguishes it from the read-only chain-data siblings like xmr_get_network_stats. The enumerated outputs (gross XMR, power cost, net USD profit, break-even prices, ROI days) make the tool's scope unambiguous.

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

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

Has explicit 'When to use' (decide whether a hashrate is worth running, explain economics changes) and explicit 'Do not use' exclusions (pool share accounting, price prediction). This routes the agent away from misusing it as a pool-accounting or forecasting tool, which is exactly the disambiguation a calculator 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 read-only/idempotent/non-destructive, and the description adds value beyond them: it discloses the required proof inputs and how to obtain them, enumerates the return fields, and reassures that the tx key/proof cannot spend funds or scan other payments. That is meaningful behavioral context a read-only hint alone does not provide.

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

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

Front-loads the action, then uses clear 'When to use / Do not use / Returns' structure, so it is easy to scan. It is somewhat long and dense, but nearly every clause carries routing or security information.

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

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

With no output schema, the description still enumerates the return fields (verified, confirmations, received_xmr, received_atomic, in_pool) and covers inputs, routing, and the security model. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantics beyond the schema by explaining the tx_key-vs-signature dichotomy and sourcing each (get_tx_key / get_tx_proof) as an either/or. It does not cover the optional message parameter, keeping it just short of 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 (verify) and resource (one Monero payment) with the distinguishing mechanism (cryptographic proof material only the recipient can provide). An agent can immediately separate this from xmr_get_transaction or tron_verify_usdt_transfer.

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

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

Explicitly names when to use it (merchant/agent confirming an XMR payment before releasing value, without trusting a block explorer) and when not to (discovering unprovable payments, or TRC-20 USDT settlement, routing to tron_verify_usdt_transfer). Both the condition and the alternative are stated.

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

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

Annotations already declare the safe-read, idempotent, closed-world profile, so the bar is lower. The description adds genuinely non-obvious context beyond them: the view key can read but never spend, and it is discarded after the call, which materially informs the privacy/security tradeoff of invoking this tool.

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

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

Front-loaded with the core purpose, then scoping, then exclusions, then returns, then a security note. Every sentence earns its place 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 no output schema, the description compensates by naming the return fields (balance_xmr, unlocked_xmr, pending_xmr, scanned_to_height, chain_tip, complete). Combined with usage, exclusions, and view-key handling, an agent has everything needed to call and interpret this correctly.

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

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

Schema description coverage is 100%, so the schema already documents address, view_key, and lookback_days. The description reinforces the view-key semantics and the scan-window concept (scanned_to_height) but adds no format or constraint detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource (balance for one Monero address) and enumerates exactly what is returned (total, unlocked, pending XMR, scanned window, completion flag). It is clearly distinguishable from the sibling read tools by naming the two it is not (xmr_verify_payment, xmr_merchant_report).

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

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

Explicit 'When to use' clause covers the two real scenarios (checking holdings now, checking whether funds unlocked) and a 'Do not use' clause routes the agent to the correct alternative for payment proof and history. Nothing is left to inference.

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