Tanod Chain

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

With no annotations provided, the description carries the full burden and does so: price (USD 0.005), free quota (3 scans or 30 checks per IP per UTC day, shared pool), latency (under 1 s, p95 ~1 s, max ~4 s), 10-minute caching, and failure handling ('if the chain cannot be read the call fails and is not charged'). It also names the return fields and verdict taxonomy, which no structured field 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 the purpose and trigger, then packs cost, limits, latency, and caveats into dense but useful clauses. Every sentence earns its place for an agent making a paid call, though the middle section is heavy and could be broken into shorter units.

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?

Though there is no output schema, the description enumerates the return shape (verdict, risk_score 0-100, plain-language reasons, proxy/token/verification details, block height) and discloses cost, quota, latency, and failure semantics. Nothing needed to decide whether and how to call it 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 both parameters are already documented with titles, an enum for chain, and the 0x+40-hex pattern. The description's restatement of address format and chain values adds no meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('pre-transaction risk check' on an address) with concrete scope: send, approve, or buy a token on Base or Ethereum. It is clearly not a source-code or package scanner, but it never explicitly contrasts itself with the sibling scan_contract_address, which an agent could easily confuse with this tool.

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

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

Gives a crisp trigger ('call it right before you send a transaction to, approve, or buy a token') plus explicit exclusions: no honeypot simulation, no liquidity/oracle analysis, and a low verdict is not a clearance. No named alternative tools or routing rules to siblings are provided, so it stops short of a 5.

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

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

Beyond the annotations (readOnly/idempotent/non-destructive/openWorld), it discloses case-sensitivity rules per address format, latency ('under 0.1 s, first call up to 1 s'), price (USD 0.002), a shared free-tier pool, and the disclaimer/list_date semantics. This is exactly the extra behavioral context the annotations cannot convey.

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 is front-loaded and the dense detail (formats, return fields, limits, pricing, disclaimer) is largely information-bearing. It is long and reads as a wall of text, but almost every clause earns its place for a paid, caveat-heavy screening tool.

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

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

With no output schema, the description enumerates the return fields (matched, matches with sdn_uid/sdn_name/etc., list, list_date, list_addresses, source, disclaimer) and covers scope, caveats, cost, and latency. 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 coverage is 100% and there is a single parameter, so the schema already carries the format. The description still adds value by explaining the case-sensitivity distinction between EVM/bech32 (case-insensitive) and base58 BTC/TRX (exact match), 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?

The description opens with a specific verb and resource ('screen one crypto address against the US OFAC SDN list's digital currency addresses'), naming the exact list and scope. The word 'one' implicitly distinguishes it from the sibling check_sanctions_batch, so an agent can tell them apart.

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 rich usage context: scope limits (OFAC SDN crypto addresses only, no other lists, no clustering/ownership/exposure analysis), the caveat that a non-match does not clear an address, and verification guidance. However, it never explicitly names check_sanctions_batch as the alternative for multiple addresses, so routing between siblings 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?

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive) the description discloses that signature-database matches are unverified hints, gives a latency range (0.2-1 s), states pricing, rate-limit pooling across three tools, and warns that returned page text and on-chain strings are untrusted data. That is unusually rich behavioral context that annotations cannot convey.

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 core purpose and inputs are front-loaded in the first clause, and every sentence carries operational information (mode behavior, latency, price, quota, untrusted-data warning). It is dense and slightly run-on with pricing/quota clauses, but nothing is wasted.

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

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

With no output schema, the description still sketches the return behavior ('every candidate that decodes cleanly is returned') and adds quota and security caveats. It stops short of describing the actual response shape or how candidates are ordered, which is the one meaningful remaining gap.

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

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

Schema description coverage is already 100%, so the baseline is 3. The description adds genuine meaning by explaining what a null/omitted signature triggers (selector lookup with multiple candidate decodings) and by flagging 0x hex format, which is behavior the schema alone does not imply.

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

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

The description states a specific verb + resource ('decode EVM transaction calldata') with the chainpeek prefix, so an agent immediately knows what it does. It does not, however, differentiate itself from nearby siblings such as decode_tx_logs or get_transaction, so the highest band is not quite reached.

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

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

It clearly explains the two operating modes: supply an optional signature, or omit it and let the selector be looked up with all cleanly-decoding candidates returned. That is real usage context, but it offers no explicit when-to-use / when-not-to-use guidance relative to sibling decoding or lookup tools.

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

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

Beyond the read-only/idempotent annotations it discloses result shape and caps (200 logs, 1 kB data), exact-integer formatting, charging behavior for not_found (200, charged) vs. malformed node answers (5xx, uncharged), expected latency, price, free quota pool, and an untrusted-data warning. This is unusually rich 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?

Dense but front-loaded: inputs, outputs, decoding scope, then caveats and pricing. Every sentence carries information, though the repeated 'chainpeek:' prefix and the long event-family enumeration make it longer than it needs to be.

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 describing the return payload fields, the event coverage, and the error/charging semantics. 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 description coverage is 100% and both parameters are documented there, so the description's restatement of 'chain' and 'hash' adds no new semantics. The one marginal addition is the enumerated chain values, which the schema already carries as an enum.

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?

It names a specific verb+resource ('decode a transaction's event logs') and a narrow scope (Ethereum or Base, specific event families), which is unambiguous. It never contrasts itself with the close sibling get_transaction or decode_calldata, so the agent must infer why this differs, keeping it short of a 5.

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

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

Usage is implied rather than stated: use it when you have a tx hash and need decoded logs. It adds a genuine caution ('events are decoded by signature only... check the emitting address') but never names an alternative tool or a when-not-to-use 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial extra context: the exact slots read, that an upgradeable proxy's implementation can change after the read, that malformed/inconsistent node answers return 5xx uncharged, latency of 1-4s, pricing, and the shared free-tier rate limit. This is far beyond what the annotations provide.

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

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

Front-loaded with the core action and inputs before the return field list, then caveats, latency, and pricing. It is a dense single-paragraph block, but nearly every clause carries operational value for a tool with this many return fields; minor density cost only.

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 full burden and does so thoroughly: it enumerates is_contract, is_proxy, kind (with all enum values), implementation and whether it has code, admin, beacon, and raw slots, plus the transient nature of the implementation for upgradeable proxies. Nothing an agent needs to interpret results 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% with an enum on `chain` and a regex pattern on `address`, so the schema already documents both parameters fully. The description restates the same input contract (ethereum|base, 0x+40 hex) without adding new syntax or semantic detail, so the baseline of 3 applies.

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

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

States a precise verb+resource: detecting whether a contract is a proxy and which kind, across two named chains. The enumerated `kind` values (eip1967_transparent, eip1822_uups, eip1167_minimal, etc.) make the scope unambiguous and clearly separate it from siblings like scan_contract_source or check_contract_before_interaction.

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

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

The description makes the usage context inferable (you call it to classify a deployed contract), but it never explicitly says when to prefer this over siblings such as scan_contract_address, scan_contract_source, or check_contract_before_interaction. No when-not guidance or alternative routing is offered.

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: it discloses error semantics (422 not charged, 5xx not charged and why), expected latency, price, a shared free-tier quota, and an explicit untrusted-data warning. Annotations already cover safety (readOnly, idempotent, non-destructive); the description adds the operational and trust posture 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 front-loaded: purpose first, then inputs, returns, error behavior, timing, and pricing. Every clause carries information, though the pricing/free-tier detail makes it heavier than a purely discovery-oriented description needs to be.

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 return fields (allowance_raw, allowance, decimals, symbol, unlimited) with the 2^255 threshold, and covers error, latency, and cost dimensions needed to call the tool correctly.

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

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

Schema description coverage is 100%, so the four parameters are already documented in the schema, including the chain enum and the 0x+40-hex patterns the description repeats. The description adds no syntax or format meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource (read an ERC-20 allowance) and scopes it to two named chains. An agent can distinguish this from siblings like get_balance or get_token_info 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?

The description gives clear context for when the tool applies (reading approval state on Ethereum or Base) and adds operational conditions (422 for non-readable ERC-20, 5xx for bad node data). It does not explicitly route the agent away from or toward sibling tools such as check_contract_before_interaction or get_token_info, so a 4 rather than 5.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well beyond them: it enumerates return fields and the null-missing convention, states typical latency (0.2-1 s), discloses the pricing and the shared 10-read daily IP quota, and warns that returned page/on-chain strings are untrusted. That is unusually rich behavioral context 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?

Front-loads purpose and input before returns, latency, cost, and the safety warning. Dense but every sentence carries information; the pricing/free-pool sentence is the longest and only marginally relevant to invocation correctness.

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

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

With no output schema, the description correctly enumerates the returned fields and the null-for-missing rule, and it covers cost, quota, and injection handling. Nothing an agent needs to call this one-parameter read 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?

Only one parameter with 100% schema description coverage and an explicit enum, so the schema fully carries parameter meaning. The description restates the enum values but adds no syntax or format detail beyond them, which is the baseline-3 case.

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 the latest block header') and scopes it to two named chains. The word 'latest' implicitly distinguishes it from the sibling get_block_at_time, which handles historical blocks.

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?

Names the accepted chain values and gives operational context (latency, cost, free-quota pool shared with the sanctions screen and URL check), which helps an agent budget calls. It never explicitly states when to prefer get_block over get_block_at_time or get_gas, so routing vs siblings 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 readOnly/idempotent/openWorld, and the description adds substantial beyond-annotation behavior: pre-genesis requests return 422 before_genesis unchained, malformed node answers return an uncharged 5xx, latency is typically 1-3 s, and the `assumed_utc` flag is disclosed. This is exactly the extra context the structured fields cannot carry.

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: inputs first, then return shape, then error semantics, then cost/limits. Every sentence carries operational weight with no filler or repetition of the schema.

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

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

With no output schema present, the description compensates fully by naming the return fields (`block`, `next_block` {number, timestamp}, `is_latest`) and the edge cases. For a 2-parameter read tool, nothing an agent needs to invoke and interpret it is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: that a no-offset ISO timestamp is treated as UTC and surfaced via `assumed_utc`, and that timestamps accept integer or digit-string Unix seconds. This is genuine value over the two documented parameters.

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

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

States a specific verb and resource ('find the block at a point in time') with an explicit chain scope (Ethereum or Base), which inherently separates it from the sibling get_block (block-by-number) without naming it. An agent can tell exactly what this tool resolves.

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

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

Gives clear operational context: cost (USD 0.003), the shared free pool of 10 chain reads per IP per UTC day, and the conditions that produce errors. It does not explicitly route the agent to an alternative tool when a block number is already known, so it falls short of a full when/when-not statement.

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?

Excellent disclosure beyond annotations: the 422 non_ascii_name path and its non-charging, the 5xx-on-malformed-node behavior and its non-charging, CCIP-Read offchain records being reported but not fetched, 1-3 s latency, USD 0.003 price, the shared 10-reads/IP/day free pool, and an untrusted-data warning. Annotations already cover readOnly/idempotent/destructive, so this is pure added value.

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 and input, then packs return shape, constraints, failure modes, and pricing into dense but non-redundant sentences. It is long and run-on, but nearly every clause carries operational information an agent would otherwise lack, so it earns its length.

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 carries the return-value burden: it names resolver/wildcard, address decoding formats, contenthash schemes, and text record keys. Combined with error modes, timing, and cost, 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?

Only one parameter, and schema description coverage is 100% — the schema already documents `name` as an ASCII ENS name with an example and length bounds. The description restates the example and the ASCII constraint but adds little syntactic 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 precise verb+resource ('read an ENS name's records') and enumerates exactly what is returned: resolver/wildcard, addresses (eth/btc/base), contenthash protocols, and text keys. The scope (Ethereum mainnet, ASCII names) is explicit. It does not, however, differentiate itself from the sibling resolve_ens, which an agent could easily confuse with this tool.

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

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

The description gives operational conditions ('ASCII names only', offchain records reported but never fetched, malformed answers produce 5xx) which imply when the call succeeds or fails, but it never says when to choose this over the sibling resolve_ens or which record types warrant this heavier call. Usage is implied rather than directed.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, yet the description adds substantially: explicit return fields, the null base_fee case on non-EIP-1559 chains, latency (~0.2-1s), pricing, quota limits, and a prompt-injection warning about untrusted on-chain/page text. This is rich behavioral context beyond the 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 action and scope, then methodically layers inputs, outputs, cost, quota, and a safety note. Every sentence carries distinct operational value 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 enumerating the returned fields and the null base_fee edge case. Combined with annotations covering safety semantics, an agent has everything needed 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% and the enum already restricts chain to ethereum|base; the description restates those values without adding format or edge-case meaning. 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+resource ('read the current gas price') and scopes it to Ethereum or Base, which cleanly separates it from siblings like get_block and get_transaction. An agent can identify the tool's function 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?

Implicitly conveys the use case (fetching current gas price) and adds operational context — latency, per-call cost, and the shared free-tier pool across chain reads, sanctions screen, and URL check. It stops short of naming an alternative (e.g., get_block already returns base fee), so it's clear but not fully routed.

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

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

Beyond the readOnly/idempotent/destructive annotations it discloses rich behavior: attacker-controlled on-chain strings flagged untrusted_content:true and never fetched, malformed node answers producing an uncharged 5xx, 0.3-2 s latency, USD 0.002 price and a shared 10-read/day free pool. This is exactly the context annotations cannot carry.

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 ordered: purpose, inputs, returns, security caveat, error/latency, then pricing and free tier. Length is justified because most sentences carry new operational facts, though it does restate the parameter formats already in the schema.

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

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

With no output schema, the description fully enumerates the return fields (standard, interfaces, name/symbol, owner, exists, token_uri plus truncation/resolution variants) and adds safety, error and cost context, leaving nothing an agent needs 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% and each parameter already documents its format (enum for chain, 0x+40 hex contract, uint256 decimal/0x-hex token_id). The description largely restates those formats without adding new 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 ('read one NFT') with an explicit scope of Ethereum or Base, and the title narrows it to standard, owner and token URI. This distinguishes it from fungible-token siblings like get_token_info and generic scans like scan_contract_address.

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

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

The description makes the use case clear (reading a single NFT's standard/owner/URI) and surfaces chain limitations, pricing and the shared free-tier pool. However, it never names an alternative or states when NOT to use it, e.g. vs get_token_info or get_portfolio, so alternatives must be inferred.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive hints. The description goes far beyond by disclosing return structure (native and per-token fields), error handling (ok:false for non-ERC-20, 5xx not charged), security warnings (attacker-controlled token symbols, untrusted data), performance (0.3–2 s), pricing, and free-tier rate limits. This is rich behavioral context.

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

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

The description is front-loaded with the core purpose, then logically flows through inputs, outputs, error behavior, performance, pricing, and security. Every sentence adds actionable information for an agent, with no wasted words despite its length.

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 must explain return values—it does so thoroughly, including field names and error semantics. It also covers edge cases, security, rate limits, and timing. Combined with annotations that carry the safety profile, nothing an agent needs 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 description coverage is 100%, so the schema already documents all three parameters in detail. The description repeats the input details (chain enum, address format, optional tokens up to 20) but adds no new semantic meaning for the parameters themselves. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'read the native balance and up to 20 ERC-20 balances of an address on Ethereum or Base in one call.' It clearly distinguishes itself from sibling tools like get_balance or get_token_info by emphasizing multi-token retrieval in a single call. An agent can immediately understand the tool's function.

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

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

The description implies usage—you call it when you need native and multiple ERC-20 balances for an address—but never explicitly states when to choose this over alternatives such as get_balance (for a single native balance) or get_token_info. No exclusions or sibling comparisons are provided.

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

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

Annotations already declare readOnly/openWorld/idempotent, and the description adds substantial context beyond them: the 422 behavior when no pool has liquidity (not charged), the 5xx behavior on malformed node answers (not charged), 0.3-2s latency, USD 0.003 price, and a shared 10-read/day free pool. It also flags returned on-chain data as untrusted, which is valuable safety 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?

Dense and front-loaded: the quote operation and inputs lead, followed by return shape, caveats, errors, and pricing. It is long, but nearly every sentence carries distinct operational value for an agent; only minor compression is 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 compensates by enumerating the return fields (amount_out/amount_out_raw, fee_tier, gas_estimate, price, all fee tiers tried, disclaimer). Combined with error and pricing behavior, 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%, so the schema already documents chain enum, token patterns, and the 'exactly one of amount_in or amount_in_raw' constraint. The description restates the amount formats (decimal units vs. raw base units) but adds no syntax or semantics beyond the schema, 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 precise verb+resource+scope: an exact-input swap quote on Uniswap V3 (QuoterV2, read-only eth_call) on Ethereum or Base. This is easily distinguishable from siblings like get_token_price or get_fx_rates, which return reference prices rather than single-pool spot quotes.

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 frames when use is appropriate and when it is not: 'A spot quote, not a firm price', 'one Uniswap V3 pool at the latest block, exact input, no gas or other venues', and 'never use it as an oracle'. It doesn't name a sibling alternative for oracle-style pricing, so it stops short of a 5.

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

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

Annotations already declare read-only/idempotent/non-destructive/open-world, and the description adds material context beyond that: return-shape fallback (is_erc20:false), attacker-controlled on-chain name/symbol text, latency, pricing, and a shared-quota mechanism. The explicit untrusted-data warning is exactly the kind of disclosure annotations cannot carry.

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 and inputs are front-loaded, then returns, then trust/cost/quota caveats — a logical order with no filler. Slight redundancy: the '0x + 40 hex' format is repeated from the schema, and the pricing/quota sentences are dense, keeping it short of 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 correctly names the returned fields and the is_erc20:false fallback. Combined with annotations and a fully described two-parameter schema, an agent has everything needed 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% with an enum on chain, so the schema already documents both parameters. The description restates the chain options and the 0x+40-hex address format, adding essentially no semantics beyond the structured fields. 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 ('get ERC-20 token metadata') scoped to two named chains, and enumerates exactly what it returns (name, symbol, decimals, total supply, or is_erc20:false). An agent can distinguish it from get_token_price, get_balance, and get_nft 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 clear operational context for choosing/invoking: required inputs, expected latency (0.2-1 s), cost (USD 0.003), and the shared 10-reads-per-IP-per-day free pool across chainpeek reads, sanctions screens, and URL checks. It does not explicitly name when to prefer a sibling (e.g. get_token_price for pricing), so it stops short of a 5.

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

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

Annotations already cover readOnly/idempotent/openWorld, but the description adds substantial behavioral context beyond them: 422 (unbilled) for unsupported pairs, latency 0.2-1 s, USD 0.002 cost, a shared 10-reads/IP/day free pool, and an untrusted-data warning about page/on-chain strings.

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 and front-loaded with the core read action, then inputs, return fields, failure mode, timing and cost. It is long and somewhat run-on, but nearly every clause carries operational information an agent needs.

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

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

With no output schema, the description enumerates the returned fields (price as exact decimal string, decimals, round_id, updated_at, age_seconds, stale with heartbeat rule, feed address), plus error and cost 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 coverage is 100% so the baseline is 3, but the description adds meaning the schema does not: which pairs are valid on ethereum vs base, and that chains are limited to ethereum|base. The enum values themselves are already 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 ('read a token price from a Chainlink on-chain price feed') and explicitly distinguishes itself from the DEX-spot-price approach used by siblings like get_swap_quote. An agent can tell what this returns 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?

The framing as a 'deterministic oracle answer, not a DEX spot price' implicitly routes the agent away from spot-quote siblings, and the free-tier/pricing context helps decide when to call. However, it never states an explicit 'use this instead of X when...' condition, so the guidance is context rather than a rule.

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 covering the safety profile, the description adds substantial operational context: the full status enum including not_found/unknown, the rule that an unknown hash is charged while a 5xx node error is not, latency (0.3-2s), price ($0.002), the shared 10-read free pool, and an untrusted-data warning. This is well beyond what readOnlyHint/idempotentHint convey.

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, leading with inputs and the return shape before pricing and safety notes. The long enumeration of return fields is a slight laundry list, but with no output schema each field earns its place.

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

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

With no output schema, the description fully compensates by enumerating return fields (status, block, fees, L1/blob splits, etc.) and the status semantics. Combined with pricing, latency, and security notes, 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% and both parameters are fully documented with pattern and enum, so the schema does the heavy lifting. The description restates the chain options and hash format but adds no format or edge-case detail beyond the schema, making the baseline 3 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?

The description states a specific verb and resource ('read a transaction and its receipt on Ethereum or Base'), which cleanly separates it from adjacent siblings like get_block, decode_calldata, and decode_tx_logs. An agent knows exactly what this retrieves without opening the schema.

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

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

Usage is implied by naming the supported chains (Ethereum, Base) and the accepted inputs, but the description never states when to prefer this over alternatives such as get_block or decode_tx_logs, nor any exclusions. Guidance is present but indirect.

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 (readOnly/openWorld/idempotent/non-destructive) by disclosing latency (0.2-1 s), price (USD 0.002), the shared 10-reads/day free pool, the forward-verification of reverse records via `verified`, and an untrusted-data warning. These are exactly the behavioral 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 the purpose and input contract, then layers in the reverse-verification nuance, cost/quota, and safety warning. It is dense but every sentence carries distinct information; only the shared-pool parenthetical is slightly over-detailed.

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 partially compensates by explaining the `verified` field's meaning and the spoofing risk. Combined with cost, quota, and latency it is nearly complete, though the full shape of the returned record is not described.

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

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

Schema description coverage is 100% and each parameter already documents the 'give name XOR address' constraint, so the schema does the heavy lifting. The description restates the same XOR rule without adding format or syntax detail beyond it, which is the baseline 3 case.

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 (resolve) and resource (ENS name or address) with scope pinned to Ethereum mainnet. An agent can distinguish this from read-only lookups like get_ens_records because the description names both the forward and reverse resolution modes explicitly.

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

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

Gives clear context on which input to supply (name XOR address) and what each path does, so the agent knows how to invoke it. It stops short of naming alternatives (e.g. get_ens_records) or stating when-not to use this tool, so no exclusions are offered.

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