code402-verify-mcp

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

No annotations are provided, so the description carries the full burden. It discloses important behavioral details: pricing range ($0.0029–$0.50), that it returns all gate results plus an XDR-1 signed receipt, and that tier is auto-detected from field count. Minor gaps remain around error behavior, what happens with zero fields, and payment/auth mechanics.

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

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

The description is three short, information-dense sentences with no filler. It is mostly front-loaded, though leading with price rather than purpose is a slight structural quibble; the core capability is still stated immediately after.

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 a tool with four optional parameters, one nested object, and no output schema, the description covers the essentials: what gates can be run, what is returned, and how pricing tier is determined. It could be more complete by addressing empty-input behavior, but it is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that any combination of the gates can be run and that tier is auto-detected from field count, which deepens understanding of how the optional parameters interact and how pricing is determined.

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+resource ('Multi-gate compliance bundle: run any combination of IBAN validation, sanctions screening, and EVM address validation in a single call'), which is precise. It also distinguishes itself from siblings like iban_check, sanctions_check, and onchain_address_check by emphasizing the bundled, single-call nature of the operation.

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 signals the usage context: use this when you want to combine multiple compliance gates in one call rather than calling individual check tools separately. However, it doesn't explicitly name the single-gate alternatives or state when not to use this bundle (e.g., for a single check), leaving some 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?

With no annotations, the description carries the full burden and does disclose two things the agent can't see elsewhere: the call is paid ($0.0029) and the return units are wei and ETH. It doesn't discuss error behavior for malformed addresses 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?

Three short sentences, front-loaded with the cost signal an agent needs before deciding to call, then purpose, then return format. 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 single-parameter read tool with no output schema, the description covers purpose, cost, and return units adequately. It omits nothing critical, though it never explicitly states the call is read-only.

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

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

Schema coverage is 100% with one required parameter already documented as a '0x-prefixed EVM address'. The description adds only that any address is acceptable, so the schema does the heavy lifting and 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 ('Get') and resource ('native ETH balance') with scope ('any Ethereum address'). The word 'native' implicitly separates it from chain_erc20_balance, but no sibling is named explicitly, so an agent must infer the boundary.

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

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

'any Ethereum address' implies unconditional usage and 'native' hints at the ERC-20 alternative, but there is no explicit when-to-use versus chain_erc20_balance or chain_code, and no prerequisites 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the paid cost ($0.0029) and the returned fields (block height and timestamp), which is real behavioral context an agent can't get from the empty schema. It omits freshness/caching behavior and failure modes, keeping 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 short sentences, front-loaded with cost then purpose then return shape. 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?

For a zero-param, no-output-schema utility, the description supplies cost, purpose, and return fields, which is nearly everything an agent needs. Only freshness/latency and error behavior are left unstated.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; the baseline for a no-parameter tool 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 ('Get the latest Ethereum mainnet block number') with clear scope qualifiers ('latest', 'Ethereum mainnet'). It is readily distinguishable from siblings like chain_tx or chain_tx_receipt, though it never explicitly names an alternative.

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

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

The word 'latest' implies when the tool is appropriate, but there is no explicit when-to-use guidance, no statement of when to prefer chain_tx or a receipt lookup instead, and no prerequisites mentioned.

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?

No annotations exist, so the description carries the full burden and does well: it discloses the per-call price ($0.0029) and explains the return-value semantics (empty hex = EOA, non-empty = contract). It omits whether the call is read-only or requires any auth, though cost disclosure is a meaningful behavioral detail most definitions miss.

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 the cost front-loaded and the return-value interpretation immediately after the action. Every sentence carries distinct information; nothing is redundant.

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

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

There is no output schema, and the description compensates by explaining exactly how to interpret the returned hex string. Cost and return semantics are covered; only the read-only/permission posture is left implicit for a single-parameter read.

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 'address' parameter is fully documented as a 0x-prefixed EVM address. The description adds no format or constraint detail beyond 'at an address', 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: retrieve the deployed bytecode at an address, which also disambiguates the terse tool name 'chain_code'. It stops short of explicitly differentiating from the closest sibling onchain_address_check.

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

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

The phrase 'Useful for distinguishing contracts from wallets' implies the usage scenario but gives no explicit when-to-use/when-not framing and never names an alternative such as onchain_address_check. Usage is inferable 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?

With no annotations, the description does carry useful behavioral weight by disclosing the $0.008 charge and the underlying universal-resolver path. It does not say what happens for unregistered/expired names, whether other ENS TLDs are supported, or whether results are cached.

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

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

Two tight sentences, cost front-loaded so the agent sees the payment implication before anything else. 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 single-parameter read tool with no output schema, saying it returns an Ethereum address is sufficient to call it, and the price disclosure is a bonus. The one real gap is unresolved-name behavior, which matters for error handling.

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 coverage, so the baseline is 3. The description adds marginal value by implicitly scoping inputs to '.eth' names, narrowing the schema's broader 'ENS name' wording.

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), a specific resource (.eth ENS name), and the resulting value (Ethereum address), plus the mechanism (universal resolver). No sibling tool resolves ENS names, so the purpose is unambiguous, though it never explicitly contrasts itself with lookalikes such as onchain_address_check.

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

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

Usage is implied by the operation itself and the paid-cost warning helps an agent decide whether to spend, but there is no explicit when-to-use/when-not guidance or mention of alternatives for address validation versus name resolution.

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

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

With no annotations at all, the description carries the full burden and does reasonably well: it discloses that the call is paid and the exact price, the on-chain method used (balanceOf), and the shape of the result (raw plus human-readable). It does not cover failure modes (malformed address, non-contract token) or whether human-readable output depends on token decimals.

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

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

Three short clauses, front-loaded with the most decision-relevant fact (paid, price), then what it does, then what it returns. 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?

For a two-parameter read tool with full schema coverage and no output schema, the description covers cost, action, and return shape adequately. The remaining gap is edge-case behavior (invalid address, non-ERC-20 contract), which an agent would benefit from knowing before paying for the call.

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

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

Schema coverage is 100%, so both parameters are already documented as 0x-prefixed token contract and wallet addresses. The description adds no meaning beyond the schema, which is the baseline expectation here.

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

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

Names a specific verb and resource ('Get ERC-20 token balance') and pins the mechanism (balanceOf), which cleanly separates it from the native-balance sibling chain_balance. It stops short of explicitly naming that sibling, so the differentiation is implied rather than stated.

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 '$0.0029' cost note is a useful usage signal an agent won't get from annotations, and the ERC-20 scoping implies when to pick this over chain_balance. However, there is no explicit when-to-use/when-not guidance or named alternative.

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

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

With no annotations, the description does the heavy lifting: it discloses the per-call cost ($0.0029) upfront and states exactly what data comes back, which is unusual and valuable context. It stops short of stating freshness/latency or data source, but for a zero-parameter public-data read the risk surface is minimal.

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

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

Three short sentences, front-loaded with the payment cost, then the action, then the return shape. Every sentence carries information and none repeats structured fields.

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

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

For a simple zero-param lookup with no output schema, the description covers what it does and what it returns, and adds the pricing detail. Only the network/data-freshness assumptions are left implicit.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the schema confirms an empty object. Baseline 4 applies; the description sensibly spends no words on absent 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?

Specific verb ("Get") plus a precisely scoped resource ("current Ethereum mainnet gas price"), and it enumerates the returned values (base fee, priority fee, max fee). No sibling in the list does anything similar, so the agent can distinguish it instantly.

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?

"Useful for estimating transaction costs" hints at the use case but gives no explicit when-to-use/when-not conditions and names no alternatives. Nothing in the sibling set overlaps, so the implied guidance is adequate but thin.

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?

No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful behavioral fact — the tool is paid and costs $0.0029 — but omits whether the nonce reflects pending versus latest state, what happens for an address with no history, or any error/rate-limit behavior.

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

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

Two short sentences with no waste, and the cost signal is front-loaded before the purpose so the agent sees the paid constraint 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?

For a simple single-parameter read tool with full schema coverage, the description covers purpose and cost adequately. The one meaningful gap is the pending-versus-latest nonce semantics, which matters for correct transaction construction but is not addressed.

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%: the single 'address' parameter is documented as a '0x-prefixed EVM address'. The description adds no format or validation detail beyond that, so the schema does all the work and 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: 'get the next transaction nonce' for an Ethereum address. This is clearly distinguishable from siblings like chain_balance, chain_tx, or chain_block_number, which return different on-chain data.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternative named. The only context for invoking it is implicit in the phrase 'next transaction nonce', leaving the agent to infer that it is used when constructing a transaction.

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

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

With no annotations, the description carries the full burden; it usefully discloses the paid cost ($0.008) and the main returned fields (from, to, value, gas used, status, block info). It says nothing about behavior for unknown/pending hashes or error cases, leaving meaningful gaps for a paid 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?

Two compact sentences with no filler, and the return-field list is informative. Leading with the price is slightly unconventional but still front-loads a key decision factor.

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 with no output schema, the description covers cost and return fields, but omits not-found/pending behavior and the distinction from chain_tx_receipt, leaving an agent without enough to invoke confidently in edge cases.

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 single hash parameter has 100% schema description coverage ('0x-prefixed 64-hex transaction hash'), so the schema does the heavy lifting. The description only restates 'by hash' and adds no format or constraint detail beyond it, matching the baseline 3.

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

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

States a specific verb (get) and resource (Ethereum transaction details by hash), so the agent knows exactly what it fetches. However, it never distinguishes itself from the close sibling chain_tx_receipt, 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 phrase 'by hash' implies the required input but gives no guidance on when to prefer this over chain_tx_receipt, nor any prerequisites or exclusions. The agent must infer the choice between overlapping sibling 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?

No annotations are supplied, so the description carries the full burden. It does disclose the paid cost ($0.008) and the shape of the result, but says nothing about failure behavior for pending, dropped, or nonexistent hashes, which is the main behavioral unknown for a receipt lookup.

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

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

Two short sentences, the cost and purpose front-loaded, followed by the return contents. Nothing extraneous.

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

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

For a one-parameter read tool with no output schema, the description covers cost, purpose, and the meaningful return fields. The only gap is error behavior for non-confirmed transactions.

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 hash parameter is fully documented as a 0x-prefixed 64-hex string, so the schema does the work. The description adds no constraints or format notes beyond it, making 3 the correct 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 and resource ("Get the receipt of a confirmed transaction") and enumerates the returned fields (status, gas used, logs, contract address), which makes it easy to separate from chain_tx (which submits a transaction) in the sibling 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?

The word "confirmed" implies the transaction must already be mined, which hints at when the tool applies, but there is no explicit guidance on what to do for pending or unknown hashes and no named alternative.

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

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

With no annotations, the description carries the behavioral burden and usefully discloses that the tool is paid ($0.0029), lists the validation layers, describes the return as pass/fail with checks and issues, and states country coverage. It does not discuss latency or authentication, but for a simple read-only validator those omissions are minor.

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

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

The description is compact and front-loaded: cost first, then purpose and checks, then return behavior and coverage. Every phrase contributes useful information without repetition.

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

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

For a one-parameter validator with no output schema, the description is complete enough: it states the checks performed, the pass/fail return shape, country coverage, and price. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%: the single iban parameter is fully documented with an example and note that spaces are allowed. The description does not add further parameter syntax or format details, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ("Validate an IBAN") and enumerates concrete checks: ISO 13616 structure, country registration, length, and MOD 97-10 checksum. It also states scope ("Covers 50 countries"), which distinguishes it from generic checksum siblings like mod97_check.

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

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

The description implies the tool should be used for IBAN validation and notes the 50-country coverage limitation, but it does not explicitly route the agent away from siblings such as mod97_check or luhn_check. There is no explicit when-to-use/when-not guidance beyond the purpose 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?

With no annotations, the description does carry the behavioral burden and it does disclose two real traits: the $0.0029 cost and the implementation backend (Rust WASM). It does not state what the validation returns on failure, whether it reports the specific failing condition, or how malformed input is handled.

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

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

Three short sentences with no filler; the validation mechanics are front-loaded after the price. Leading with the price rather than the action is slightly awkward for scanning, 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?

For a single-parameter pure validator with no output schema, the description covers input format, algorithm, and cost — enough to call it correctly. The remaining gap is the absence of any statement about the return shape (e.g. valid/invalid plus reason), which matters since there is no output schema to fall back on.

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

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

Schema coverage is 100% for the single 'lei' parameter, whose schema description already gives the 20-character format and an example. The description's format note merely restates 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 (Validate) and resource (LEI, ISO 17442) and pins down the exact checks performed (20-char alphanumeric format, Mod 97-10 check character). It is distinguishable from siblings like iban_check and luhn_check by the standard it cites, though it never names the closest sibling, mod97_check, which performs the underlying algorithm.

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

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

Usage is implied by the domain: validate an LEI string. There is no explicit when-to-use/when-not, and no routing to mod97_check or sanctions_check/onchain_address_check despite those being adjacent validators. The price disclosure ('Paid ($0.0029)') is useful for cost-aware selection but is not usage guidance.

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

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

With no annotations, the description does real work: it discloses the price ($0.0029), the execution engine (Rust WASM), the standard applied, and precisely what is verified (numeric format and Mod-10 checksum). It omits the return shape and the important caveat that passing Luhn does not mean the account exists or is chargeable, 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?

Three short sentences, with the cost front-loaded where an agent will see it before deciding to call. The engine note is marginally useful for trust but is the least load-bearing sentence.

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

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

For a one-parameter, no-output-schema tool, the description covers purpose, standard, cost, and what is checked, which is nearly everything needed to call it correctly. The one gap is what the response looks like and how to interpret a pass versus a fail.

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

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

Schema description coverage is 100% and the single parameter already documents format (12-19 digits, spaces allowed). The description adds no constraints or semantics beyond what the schema states, 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 (validate) plus the resource (payment card or account number) and names the exact algorithm and standard (Luhn, ISO/IEC 7812-1), which implicitly separates it from siblings like mod97_check and iban_check. It stops short of explicitly contrasting itself with those siblings, so a 4 rather than a 5.

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

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

Usage is only implied: an agent can infer this is the tool for pre-charge card-number sanity checks. There is no explicit when-to-use/when-not guidance and no referral to mod97_check or iban_check for other numbering schemes.

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

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

With no annotations, the description carries the full burden and does well: it discloses the per-call cost ($0.0029), the return range (0-96) and the success sentinel (valid=1), plus the Rust WASM engine. It omits error behavior for non-alphanumeric input, 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?

Four short clauses, each carrying information (cost, operation, return contract, use cases). The cost notice is front-loaded where an agent will see it before invoking 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?

No output schema exists, and the description compensates by stating the return value range and the valid sentinel. For a single-parameter primitive that is nearly complete; only failure/edge-case behavior for invalid characters is unaddressed.

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

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

One parameter with 100% schema coverage, so the schema already documents 'input'. The description adds little beyond restating that the string is alphanumeric and that the remainder is computed over the whole string; 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: 'Calculate ISO 7064 Mod 97-10 remainder for any alphanumeric string'. This is clearly the low-level primitive behind sibling tools like iban_check and lei_check, and the phrase 'custom identifier validation' hints at that generic scope, but no sibling is named explicitly.

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

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

'Used for IBAN, LEI, and custom identifier validation' implies the domain of application, but it does not tell the agent when to call this primitive versus the dedicated iban_check or lei_check siblings. No exclusions or prerequisites are stated.

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

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

With empty annotations the description carries the full burden and does well: it discloses cost ($0.0029), that the result is a valid/invalid verdict, and that normalization and checksum status are returned. It does not say whether a malformed input raises an error or returns valid=false, nor whether the paid call is charged on failure.

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

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

Three short sentences: cost first, then what is validated, then what is returned. Zero filler and the operation is front-loaded after the price.

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

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

For a one-parameter pure-computation tool with no output schema, the description says enough to call it and to know what comes back. The only real gap is failure semantics for malformed input.

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

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

Schema coverage is 100% with a worked example address, so the single parameter is already fully documented structurally. The description adds only that the address is checked for EIP-55 checksum casing, which is marginal meaning beyond the schema.

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

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

States a specific verb (validate) and a specific resource (EVM address) and names the exact checks performed: format and EIP-55 mixed-case checksum. Among the validation siblings (iban_check, lei_check, luhn_check) the resource is self-evidently distinct, though the description never explicitly routes against them.

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

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

No statement of when to use this versus alternatives and no prerequisites (e.g. 'call before chain_tx to avoid wasted gas on a mistyped address'). The purpose sentence lets an agent infer usage, but there is no explicit context or exclusion.

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

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

With no annotations, the description carries the burden, and it does much of that work: it discloses cost ('free'), signals a read-only lookup, and names the return payload fields, which matters because there is no output schema. The gap is behavior when neither optional parameter is supplied (0 required params) — the description is silent on the default/all-tools case.

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

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

Three short sentences, zero filler: purpose and cost first, return contents second, parameter routing last. Nothing repeats the tool name or pads.

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

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

For a simple two-parameter lookup with no output schema, describing the returned fields is the key omission it correctly covers. It falls short only on the zero-argument case and error behavior for an unknown tool_name/url.

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 with examples in the schema; baseline is 3. The description adds only the either/or framing of the two lookup modes, which is a marginal gain 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+resource ('look up pricing for any code402 tool') and enumerates what is returned (pricing tiers, accepted networks, availability). No sibling tool does pricing, so it is trivially distinguishable from the chain_*/check utilities listed.

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 disambiguates the two lookup modes ('use tool_name for named lookups or url for URL-based lookups'), which is genuine routing guidance at the parameter level. It does not say when an agent should call this versus just invoking a tool, nor any prerequisite such as 'check pricing before paid calls' — usage is implied rather than stated.

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

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

Annotations are empty, so the description carries the full burden; it does disclose two genuinely useful behavioral facts not available elsewhere — that the call is paid ($0.0029) and that it returns clear/hit with matched entries. It stays silent on cost-per-call semantics for batching, partial-match handling, error behavior, and whether screening happens live or against a snapshot.

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

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

Three tight sentences with the cost signal front-loaded ahead of capability and return shape; nothing is wasteful. It could be marginally better ordered by leading with the purpose rather than the price.

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 annotations and no output schema, the description must carry everything; it covers cost and the clear/hit result shape but leaves the empty-input case and result payload details unstated for a tool whose parameters are both optional.

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

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

Schema coverage is 100%, so both parameters are already documented as arrays of names and 0x-prefixed addresses. The description's line 'Supports both EVM addresses and human-readable names' restates that split without adding format, batching, or size-limit detail, so it holds at the baseline.

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

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

States a specific verb and resource ('Screen Ethereum addresses and entity names against OFAC/UN/EU sanctions lists') and names the concrete data sources, which lets an agent distinguish this from generic siblings like onchain_address_check. It does not explicitly contrast itself with onchain_address_check or lei_check, so sibling differentiation is implied rather than stated.

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 purpose sentence makes the intended use obvious (compliance screening against named sanctions lists), but there is no explicit when-to-use/when-not guidance versus onchain_address_check, and no statement that at least one of addresses/names must be supplied even though required parameters is zero.

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

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

With no annotations provided, the description carries the full burden and does so reasonably well: it discloses the operation is offline and free, that results are per-receipt valid/invalid, and what the response contains (signer recovery, declared signer comparison, integrity digest). It does not cover failure modes such as malformed receipt JSON, 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?

Three tight sentences: the core action and cost signal come first, the return shape second, and the batch input format last. Nothing is repeated and every sentence carries information an agent needs.

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

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

There is no output schema, so the description correctly compensates by summarizing the per-receipt return fields. Combined with the documented parameters, an agent has enough to call it correctly; only error/failure behavior is left unstated.

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

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

Schema coverage is 100%, so the baseline would be 3. The description adds genuine value beyond the schema by clarifying that raw_receipt accepts a single JSON string or an array for batch verification, which conveys the batch semantics at a glance. It says nothing about settlement_asset, which explains why it is not a 5.

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

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

The description names a specific verb and resource: 'Verify one or more XDR-1 signed receipts offline', and adds the key scope of batch support. It does not explicitly contrast with the sibling bundle_verify, which is the one tool an agent might reasonably confuse it with, so it stops short of a 5.

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

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

Mentioning 'offline (free)' implicitly signals no network call and no cost, which is useful context for choosing this over on-chain checks. However, it never states when not to use it or names an alternative such as bundle_verify, so the guidance remains implied rather than explicit.

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