x402-checks

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so safety is covered. The description adds genuinely non-derivable behavior: values come back both raw and formatted, and the result carries a signed receipt, which tells the agent the response is attestable.

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

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

Two tight sentences with no filler. Asset scope and default are front-loaded, and the receipt note is appended only because it matters.

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

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

An output schema exists, so return shape need not be explained, and the description covers chain, assets, encoding and the receipt. The one real hole is sibling disambiguation against erc20_balance.

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

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

Schema description coverage is 100%, so both parameters (address, token_address) are already documented, including the USDC default. The description restates the default-token behavior but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource: fetching native ETH and one ERC-20 (default USDC) balance for an address on Base. The scope (chain, asset types, default token) is concrete enough to distinguish it from generic balance readers, though it never names the near-identical sibling erc20_balance.

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 when-to-use, when-not-to-use, or prerequisite guidance. With erc20_balance in the sibling list, an agent has to guess which tool to pick for a single-token query versus this one; the description offers no routing 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered structurally. The description adds a pricing note and an ambiguous claim that 'each result states its scope,' but says nothing about failure handling for invalid items, partial-batch behavior, or rate limits.

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

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

Two short sentences, front-loaded with the core capability and the item cap. The 'each result states its scope' sentence is somewhat vague and contributes less than the other two, but there is no padding.

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

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

With an output schema present, return values need not be explained, and the description does cover batch size limits, item shape, and the cost rationale. It could be stronger on per-item error behavior, but nothing essential for invocation is missing.

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

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

Schema description coverage is 100% and the single 'items' parameter is fully specified in the schema, so the 3 baseline applies. The description restates the {tool, value} shape and the 50-item cap but adds no syntax or format detail beyond the schema.

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

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

The description states a specific action and resource: running up to 50 {tool, value} identifier checks in a single request. This clearly distinguishes it from the single-check siblings like iban_check and lei_check, though it never names them explicitly.

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

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

The line about comparing batch quotes with individual quotes implies the batch is a cost-saving alternative to per-item calls, and 'savings depend on batch size' hints that small batches may not be worth it. However, no explicit threshold or when-not-to-use rule is given, leaving the agent to infer the tradeoff.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one non-obvious behavioral detail – that the result carries a signed receipt – but does not explain what that receipt is or how it should be used, so the added context is thin.

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

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

Two tight sentences with the resource and returned fields front-loaded and no wasted prose. The trailing sentence about the signed receipt is slightly vague but earns its place by flagging a return-value trait.

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

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

An output schema exists so return values need no explanation, and annotations carry the safety profile; the description covers what the tool reads and its default scope. Only the ambiguous 'signed receipt' phrase leaves a small gap in what an agent should expect.

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

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

With a single parameter at 100% schema description coverage, the schema already fully documents accepted hex/decimal/tag formats and the default. The description only restates 'latest or a given block' and adds no format or constraint detail beyond the schema.

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

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

States a concrete resource (block header) and enumerates the returned fields (number, timestamp, transaction count, base fee) plus the scope (latest or a given block). It does not name a sibling such as tx_activity, but the purpose is unambiguous.

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

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

'for the latest or a given block' implies the default behavior, and the schema confirms defaults to latest. However, there is no explicit when-to-use guidance or differentiation from related tools like tx_activity, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: the comparators are assumptions rather than measurements of any bank/provider, and no protocol fee is deducted on this rail — important for interpreting the output.

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

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

Two sentences, purpose front-loaded, with the caveat about assumptions following immediately. Tight overall, though the named-but-absent parameters cost some clarity.

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

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

An output schema exists so return values need not be described, and the assumption/no-protocol-fee caveat is valuable. However, with zero required parameters and no usage guidance against siblings, an agent still lacks routing information to invoke this correctly.

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

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

Schema description coverage is 100% so the baseline would be 3, but the description names bank_fee_pct and custodial_fee_pct as caller-supplied parameters while the schema contains only amount/amount_usd/amount_usdc/currency. These phantom parameters are misleading and add no reliable value over 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 operation (arithmetic comparison of a USDC settlement against comparator percentages) and resource (FX savings across fiat currencies), which is enough to distinguish it from siblings like fx_spot_price_oracle or check_price. Not quite a crisp 'verb+resource' formulation, but clear.

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

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

No statement of when to use this tool versus alternatives such as fx_spot_price_oracle or check_price, and no prerequisites or exclusions. The only usage-adjacent text is that the comparators are supplied by the caller.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds genuinely useful behavior beyond that: no financial obligation is created, the quote_id is opaque, a TTL applies, and settlement requires an EIP-3009 signed voucher. It does not state what happens when the TTL expires, 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, front-loaded with what it returns, then the zero-cost guarantee, then the settlement flow. No filler and the most decision-relevant facts come first.

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

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

With an output schema present, the description is not obligated to enumerate return fields, yet it still names the key ones. Combined with the settlement flow and zero-cost caveat, an agent has enough to call it correctly; only TTL/expiry behavior is left implicit.

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

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

Schema coverage is 100%, so 'tool' and 'amount' are already documented in the schema (including the example and default). The description adds no further meaning about parameter values or formats, 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 ('returns the live price, an opaque quote_id, TTL, and the settlement URL') and frames the tool's role as the zero-cost pricing hook preceding code402 tool calls. This clearly separates it from the sibling validation tools (iban_check, gstin_check, etc.), none of which produce 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?

Explains the usage context well: call it first to feed pricing into a planner's context, then hit settlement_url only if acting on the quote. It gives the when and the conditional follow-up but stops short of naming an explicit alternative tool or a when-not-to-call 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?

Annotations already cover read-only, open-world and idempotent, so the bar is lower. The description still adds real behavioral context beyond them: the no-JS constraint, the fact that output includes headings, and that the result carries a signed receipt (which pairs with the receipt_verify sibling). Rate limits and failure modes are not disclosed.

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 core action, followed by the key limitation and one notable output trait. Every sentence carries information; nothing is redundant with the title.

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

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

An output schema exists, so return values need not be spelled out, and the description still flags the two most relevant payload traits (Markdown + headings, signed receipt). The only gap is that it does not say what happens when both url and html are omitted, given that neither is required.

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

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

Schema coverage is 100% and both parameter descriptions already state the 'provide exactly one of url or html' rule plus the 1 MiB / port constraints. The description only restates the url-or-html duality, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

Specific verb and resource ('Fetch a public web page by URL ... return Markdown plus headings'), with the alternate input mode named explicitly. No sibling tool in the list overlaps with web-to-Markdown conversion, so no differentiation is needed and none is missing.

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 JavaScript rendering' is an effective negative guideline: an agent can immediately tell this tool is unsuitable for JS-rendered pages. It also names the two input modes, but stops short of naming an alternative for the JS case or stating exclusions like auth-required pages.

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

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

Annotations already cover read-only and idempotency, but the description adds genuinely useful traits: deterministic output, pure function with no external calls or ML, and hashing over the exact input bytes. The only tension is openWorldHint=true versus "no external calls," though this reads as a permissive default rather than a real conflict.

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

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

Two dense sentences with no filler, front-loaded with the digest components and closing with the determinism guarantee. Every clause carries information.

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

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

The tool is simple, the single parameter is fully documented, and an output schema exists, so return detail is a bonus rather than a requirement. The one gap is the absence of any indication of when an agent should reach for this tool, which for a one-param utility is the only missing piece.

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's description already states the text is arbitrary and hashed exactly as given, so the schema does the heavy lifting. The description clarifies the digest's components but adds nothing new about the parameter itself, matching the baseline 3 for fully covered schemas.

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

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

States a concrete verb+resource ("text digest") and enumerates the exact outputs: word count, top-5 frequent words with stop words excluded, first sentence, keccak-256 hash. No sibling tool performs text analysis, so the purpose is unambiguous 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?

No when-to-use or when-not-to-use guidance is given; nothing routes the agent among the finance/validation siblings or explains the intended scenario (e.g. deduping scraped text before downstream processing). "Pure function — no external calls" is a property, not usage guidance.

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

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

Annotations already declare readOnly, openWorld, and idempotent, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: the source is public price feeds, results are cached for 60 s (implying staleness), and the result carries a signed receipt (verifiability). It stops short of stating rate limits or error behavior for unknown symbols.

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

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

Two short sentences, front-loaded with what is priced and from where, then the cache and receipt facts. No filler and nothing repeated.

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

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

An output schema exists, so return-value explanation is not required, and the signed-receipt mention is a helpful pointer. Caching and source are disclosed, but error handling for unrecognized symbols and any rate limiting are absent.

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

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

Schema description coverage is 100% and there is only one parameter, so the schema already documents the ticker-vs-CoinGecko-id duality fully. The description restates the same accepted forms without adding format or validation detail, matching the baseline 3 for a schema-complete tool.

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: spot USD price for a crypto ticker or CoinGecko id. The 'USD' and 'crypto ticker' qualifiers implicitly separate it from fiat siblings like fx_spot_price_oracle, but it never names or explicitly contrasts any sibling, so disambiguation is left to inference.

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 when-to-use guidance, no when-not-to-use, and no mention of alternatives such as check_price or fx_spot_price_oracle. The only contextual detail is the data source and cache TTL, which is not routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: decimals are read on-chain from the token, and the result carries a signed receipt — a non-obvious output trait.

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

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

A single tight sentence that front-loads the operation, the resource, and the chain, then appends the receipt trait. No filler or redundancy.

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

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

An output schema exists, so return values need no elaboration, and annotations cover safety and idempotency. Chain scoping and the signed-receipt output are disclosed; minor gaps remain around failure behavior for invalid or non-contract token addresses.

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

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

Schema coverage is 100%, so all three parameters are already documented, making 3 the baseline. The description adds marginal value by explaining that decimals are read from the token, which contextualizes the optional decimals override, but gives no syntax or format detail beyond the schema.

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

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

States a specific verb and resource (balanceOf for an ERC-20 token), pins the chain to Base, and clarifies that both raw and formatted values are returned. It does not explicitly differentiate itself from the sibling balance_check, so it falls just short of a 5.

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

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

The Base/ERC-20 scoping implies when the tool applies, but there is no explicit when-to-use, when-not, or named alternative (e.g., balance_check for native/other-chain balances). Usage must be inferred from the scope 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?

Annotations already cover read-only/idempotent/open-world safety, and the description adds genuinely non-structured context: the rate comes from a static table (staleness implication), the result includes the inverse, and it carries a signed receipt. It does not explain what the receipt is for or how it should be verified, leaving one behavioral gap.

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

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

Two sentences, zero filler, and the most decision-relevant fact (static, not live) is front-loaded before the return-shape details.

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 a full output schema and safety annotations, the description covers what it does, how it differs from live feeds, and what it returns. The only omission is the meaning/use of the 'signed receipt' (e.g. whether receipt_verify should be used), which leaves a minor loose end.

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

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

Schema description coverage is 100% with both required params (base, quote) documented and exemplified, so the schema already carries the parameter meaning. The description only implies base/quote via 'fiat and stablecoin conversion rate' and adds no syntax or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('reference fiat and stablecoin conversion rate') and distinguishes itself from live-quote siblings (check_price, crypto_ticker) by explicitly saying 'from a static table, not a live feed'. It does not name a sibling directly, but the static-vs-live framing is enough for an agent to route correctly.

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 'static table, not a live feed' clause functions as an explicit when-to-use/when-not discriminator against the live-price siblings, which is real routing guidance. It stops short of naming alternatives or stating prerequisites (e.g. supported symbol set, staleness expectations), so it isn't a full 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 readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context by specifying the validation method: structural layout plus a mod-36 cross-sum checksum, which clarifies what 'validate' means here.

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

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

A single sentence that is front-loaded with the purpose and is free of filler. Every clause adds information needed to understand what the tool does.

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 rich annotations and an output schema, the description is sufficiently complete. It covers purpose and validation logic, and the output schema handles return-value details, so no critical information 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 single gstin parameter is already documented. The description adds value beyond the schema by breaking down the GSTIN structure (state code, PAN, entity code, 'Z') and noting the checksum, giving the agent a clear mental model of the input.

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

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

States a specific verb ('Validate') and resource ('Indian GSTIN'), and immediately names the exact format it checks (2-digit state code + PAN + entity code + 'Z') and the checksum algorithm. This distinguishes it from sibling validators like iban_check or swift_bic_check by the precise identifier type.

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 offers no when-to-use guidance, no prerequisites, and no explicit alternatives. It does not tell the agent to choose this over batch_validate for single checks or over india_supplier_check for broader supplier validation.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description adds real value beyond them by explicitly bounding what the result does NOT prove — account ownership, beneficiary identity, fraud absence — which is critical for an agent deciding how much to trust a positive result.

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

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

Two sentences, zero waste, with the positive capability front-loaded and the limitation following. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained here. Combined with the scope disclaimer and a single fully documented parameter, the definition is essentially complete for a stateless validator; only explicit sibling routing 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 and schema description coverage is 100% ('IBAN to validate; spaces allowed.'), so the schema fully documents the input. The description adds no syntax, formatting, or length details 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?

States a specific verb and resource ('Validate IBAN structure and MOD-97 checksum'), which immediately distinguishes it from siblings like swift_bic_check, gstin_check, and vat_mod97_check. The scope is narrow and unambiguous.

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

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

Usage is implied by the purpose — call it when you need IBAN format/checksum validation — but there is no explicit when-to-use guidance or routing against siblings such as vat_mod97_check or batch_validate. The second sentence is a scope disclaimer, not invocation guidance, so this is minimum viable rather than strong.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real value beyond that by clarifying what the check deliberately does NOT do (no registry lookup, no account verification), which prevents the agent from over-trusting the result.

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

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

Two tight sentences, front-loaded with what it does and then the scope boundary. Every clause earns its place with no filler.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. For a single-parameter format validator the description supplies exactly the missing context: the scope boundary and validation rule.

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 'ifsc' parameter, so the schema already documents it; baseline is 3. The description adds a small amount of semantic detail by noting the fifth-character-zero rule, which is param-relevant, but it does not describe accepted value shapes beyond what the schema provides.

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

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

States a specific verb (Check) and resource (the 11-character Indian IFSC format), and immediately bounds the scope by naming the detail it validates (the fifth-character zero). The negative clause 'No bank-branch registry lookup or account verification' clearly separates it from richer verification tools in the sibling set.

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

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

It gives explicit when-not guidance ('No bank-branch registry lookup or account verification'), telling the agent this is pure syntactic validation rather than a lookup. It does not name a specific sibling alternative, so it falls short of a full 5, but the exclusions are unambiguous.

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

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

Annotations already cover read-only and idempotency, so the bar is lower; the description adds genuine value by disclosing that these are four deterministic structural checks rather than registry-backed verifications, and that output comes as a single receipt. Mild tension with openWorldHint=true, since pure structural/checksum validation ordinarily needs no external system, but this is inferential rather than a direct contradiction.

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

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

Three short sentences, zero filler, and the payload ('One call, one receipt: GSTIN + PAN + UPI VPA + IFSC') is front-loaded before the supporting scope and audience notes.

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

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

With an output schema present, return values need no explanation, and annotations carry the safety profile, so the description is close to sufficient. The one gap is that it never says how to use it with partial input (all parameters are optional, and it is unclear whether one identifier alone yields a useful result).

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

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

Schema description coverage is 100%, so each of the four identifier parameters is already documented with format hints (character lengths, optionality). The description confirms the four checks map to those identifiers but adds no format, syntax, or partial-input semantics beyond the schema, 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 names the exact resources checked (GSTIN, PAN, UPI VPA, IFSC) and frames the tool as a bundled verification call for an Indian counterparty, which implicitly separates it from the single-identifier siblings like gstin_check and ifsc_check. The verb is somewhat implicit ('checks') but the scope is unambiguous.

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

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

It states a clear usage context: cross-border procurement where the buyer is an agent that cannot open an INR account, which explains why this consolidated pack exists. It does not, however, state when to prefer it over sibling packs (batch_validate, vendor_onboarding_pack) or any exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and determinism are covered structurally. The description adds almost nothing beyond that: "Preflighted for agent tool call pipelines" is a positioning claim, not behavioral detail, and it says nothing about failure behavior, error granularity, or whether validation stops at first error.

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

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

Two short sentences with the core action front-loaded. The second sentence is vaguer marketing-flavored padding, but the total length is minimal and nothing is buried.

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

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

An output schema exists, so return values need not be explained, and both required parameters are fully described in the schema with an example. What remains missing is usage routing against the similar batch_validate sibling, which a definition this simple could reasonably have included.

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 with clear descriptions plus a worked example, so the schema carries the burden. The description adds no syntax, format, or dialect guidance (e.g., which JSON Schema draft) beyond restating that data is checked against schema. Baseline 3 is appropriate.

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

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

The description states a specific verb+resource: "Validate JSON data payloads against schema definitions." That is unambiguous and an agent can immediately tell what it does. It does not differentiate from the sibling batch_validate, which appears to be the closest alternative, so it falls short of a 5.

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

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

"Preflighted for agent tool call pipelines" gestures at a usage context but never states when to call this versus batch_validate or why a pipeline should preflight with it. There are no exclusions and no named alternative, so the guidance is essentially absent beyond a slogan.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint. The description adds meaningful behavioral context beyond that: despite openWorldHint=true, this is a pure offline format/checksum check with no external registry call, no registration-status lookup and no identity verification — a real clarification of the tool's actual 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 sentences, zero waste, with the core action front-loaded and the scope exclusions immediately after. Nothing needs to be trimmed.

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

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

For a single-parameter validator with an output schema and full annotations, the description covers what is checked and what is explicitly out of scope. Only minor gaps remain (nothing on error/return signaling), which the output schema largely absorbs.

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 'lei' parameter is fully documented in the schema. The description reinforces the 20-character length and MOD-97 algorithm but adds no format or normalization detail beyond that, 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 precise verb+resource: validating a 20-character LEI with MOD-97 check digits. The second sentence draws explicit boundaries ('No registry lookup, active-registration check or legal-entity identity verification'), which separates it from registry/identity siblings like sanctions_address_screen or vendor_onboarding_pack.

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 negative scoping ('No registry lookup, active-registration check or legal-entity identity verification') tells the agent exactly when this tool is insufficient, which is genuine routing guidance. It stops short of naming the alternative tool for those excluded cases, so it is not a full 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 readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is partly covered. The description adds valuable behavioral context beyond annotations: the result is advisory and not verified identity, fraud clearance, or authorization to release funds, and it notes a receipt-hash dependency. This helps an agent understand the limits of the output.

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 tight sentences with no filler, and the advisory caveat is front-loaded after the core action. However, 'domain-age evidence' is vague and the receipt-hash requirement is stated without supporting context, slightly weakening precision.

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

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

An output schema exists, so return values need not be explained. But for a complex 8-parameter composite guard, the description does not say how inputs combine, what 'mismatch signals' means, or how to choose this tool over dedicated sibling checks. The stated receipt-hash requirement is not represented in the input schema, creating ambiguity 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 all eight optional parameters are documented in the input schema. The description groups them as 'supplied identifiers, domain-age evidence and mismatch signals' but adds no per-parameter meaning, format, or combination rules beyond what the schema already provides.

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

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

States a specific verb 'Evaluate' and objects 'identifiers, domain-age evidence and mismatch signals', which gives a general sense of purpose. However, it does not differentiate this tool from sibling checks such as lei_check, iban_check, vat_mod97_check, or sanctions_address_screen, nor does it clarify whether it aggregates them or replaces them.

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

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

No explicit guidance on when to use this tool versus the many dedicated sibling verification tools or vendor_onboarding_pack. The phrase 'Requires a preceding receipt hash' is a prerequisite, but it does not establish context, exclusions, or alternatives for invocation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds genuinely useful non-annotation context: statelessness, no quota/account, and the crucial trust caveat that a valid receipt does NOT prove funds moved or any business claim. That semantic boundary is valuable behavioral disclosure beyond the annotations.

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

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

Three tight sentences: what it does, the operational guarantees, then the trust-boundary caveat. All front-loaded and every sentence earns its place.

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

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

With an output schema present, return values need no explanation. The description covers scope (any issuer), cost (free), state (stateless), and the meaning/limits of a valid result — everything 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 description coverage is 100% and the schema itself enumerates every receipt field with an example, so the description carries no extra parameter burden. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('verifies a signed XDR-1 receipt from ANY x402 service') and describes the exact mechanism (recomputes canonical digest, recovers signer, compares to declared signer). This is clearly distinguishable from the sibling checking tools (iban_check, gstin_check, etc.).

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

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

Usage context is implied by 'from ANY x402 service' and 'free forever', but the description never states when to use this versus batch_validate or the other validation siblings, nor any prerequisites or exclusions. Adequate but with a clear routing gap.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing that the check is deterministic, backed by a local curated blocklist, incomplete in coverage, and non-authoritative on a negative result. These are exactly the behavioral traits an agent needs before relying on the output.

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

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

Three sentences, front-loaded with the core action, then scope exclusions, then the caveat. No filler, and the most decisive information leads.

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

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

An output schema exists, so return values need no explanation, and the description fully covers scope, determinism, coverage limits, and the non-clearance caveat. Nothing an agent needs to call and interpret this tool correctly is missing.

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

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

Schema coverage is 100% and the single 'subject' parameter is already documented as an EVM address or ISO country code/jurisdiction name. The description reinforces the accepted input types but adds no syntax, formatting, or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource: deterministic screening of EVM addresses and jurisdictions against a curated local blocklist. It explicitly scopes itself to address- and jurisdiction-level checks and rules out name-based screening, letting an agent distinguish it from siblings like iban_check or swift_bic_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?

Gives clear when-not guidance ('NOT name-based screening and NOT a complete OFAC SDN check') and a strong caveat that absence of a match is not clearance, directing use as one informational compliance input. It stops short of pointing to an alternative tool when a full name-based SDN check is actually needed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful scope disclosure: it is a structural/country-code check only and does not assert bank existence, live routing, or beneficiary identity. That is exactly the kind of limitation an agent needs before treating a pass as meaningful, though it says nothing about error behavior or partial matches.

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

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

Two short sentences, front-loaded with the affirmative scope and immediately followed by the exclusion. Every clause earns its place and nothing is padded.

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

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

An output schema exists, so return-value detail is unnecessary in the description, and the single parameter is fully documented in the schema. The description covers purpose and limits adequately; the only minor gap is the absence of any pointer to complementary tools for the capabilities it disclaims.

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 a single required parameter, and the schema itself documents the 8-or-11-character format and tolerance for spaces/dashes. The description adds no syntax or format detail beyond that, 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 (check) and resource (SWIFT/BIC structure and country code), which is enough to separate it from sibling validators like iban_check, ifsc_check, and lei_check. It does not explicitly name those siblings or contrast scope with them, 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?

The description defines the tool's boundary via negation ('does not establish bank existence, active routing or beneficiary identity'), which implies the appropriate use case for pre-validation. However, it gives no positive when-to-use framing and names no alternative tool for the cases it disclaims, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new context: 'Deterministic' (identical input yields identical output) and 'Result carries a signed receipt', which tells the agent the output is externally verifiable (relevant to receipt_verify). It stops short of explaining what the flags mean or rate limits.

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

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

One compact sentence plus two short clauses, front-loaded with the deterministic-facts claim and immediately followed by the critical disambiguation and receipt note. No filler; every clause carries information.

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

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

An output schema exists, so return values need no elaboration, and annotations cover the safety profile. The description adequately frames what the tool does and what it is not. A minor gap remains around how to read the selectors/flags, but overall it is complete for its complexity.

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

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

Schema description coverage is 100% and the single enum parameter is documented ('Only base is supported'), so the schema carries the semantics. The description adds no address format or chain detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb+resource (Base contract facts) and enumerates exactly what is returned: ERC-20 metadata, proxy slots, owner(), privileged-function selectors and flags. It also disambiguates from the misleading name by stating 'Not a safety verdict', which separates it from siblings like sanctions_address_screen or erc20_balance.

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 'Not a safety verdict' implies a usage boundary (don't use this for safety screening) but does not name an alternative sibling or state the positive condition that selects this tool over checking a balance or price. Usage is 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.

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

Annotations cover read-only/idempotent/open-world, and the description adds two traits beyond them: the chain scope (Base, which narrows the openWorldHint) and that the result carries a signed receipt, implying verifiability. It stops short of describing rate limits or failure modes, so it is good but not exhaustive.

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

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

Two front-loaded sentences with no filler: the first carries the purpose and scope, the second the output trait. Efficient, though the receipt phrase is slightly terse and could be clearer.

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

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

With an output schema present the description need not explain return values, and annotations carry the safety profile. Chain scope and the receipt trait round it out; only the absence of sibling routing guidance keeps it from being fully complete.

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

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

Schema coverage is 100% and the single address parameter is fully documented ('EVM address, 0x-prefixed'). The description adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource pair: outbound transaction count (nonce) and a contract-vs-EOA check for an address, scoped to Base. It is clear what the tool returns, though it does not explicitly differentiate itself from siblings like balance_check or token_contract_risk.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer that this is for checking activity level or whether an address is a contract versus balance/token tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety/idempotency profile is covered. The description adds that this is an offline format/checksum validation rather than a VIES registration lookup, which is useful context, but the bulk of its content is negative scoping that overlaps usage guidelines.

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 tightly packed sentences with the positive purpose front-loaded and the exclusions following. Appropriately sized for a single-parameter validator, though the second sentence reads as a list of negatives rather than tightly structured prose.

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

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

An output schema exists, so return values need no explanation, and the single parameter is fully documented in the schema. The description covers scope and exclusions completely; only the meaning of a failed check (versus a malformed input) is left to the output schema.

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

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

With a single parameter and 100% schema description coverage, the schema already documents the vat_number field, its format and the optional BE prefix. The description's 'BE only' and VIES exclusion concern the tool's scope rather than adding parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb (Check) and resource (Belgian VAT format and MOD-97 checksum) and bounds the scope with 'BE only'. It distinguishes itself conceptually from other validators via 'not VIES, other EU VAT formats', though it does not name a specific sibling 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 clear negative guidance: 'not VIES, other EU VAT formats, registration status or tax compliance', which tells the agent when this tool is the wrong choice. It lacks an explicit positive statement of when to prefer it over a live registry lookup, but the exclusions are unusually complete.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful scope context beyond them: it performs format/structure validation only and explicitly does not perform ownership, registry or fraud clearance, which is exactly the boundary an onboarding agent needs.

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

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

Two sentences, zero filler. The capability statement is front-loaded and the scope caveat follows immediately, earning each clause.

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

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

An output schema exists, so return-value detail is correctly omitted, and the scope limitation is stated. The one gap is that all four parameters are optional and the description never says whether any subset (or none) may be supplied or how partial input is handled.

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

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

Schema description coverage is 100%, so the four parameters are already documented individually (including 'BE mod-97' and 'UK company number'). The description restates the same field list without adding format, accepted-value, or partial-submission guidance, 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 ('Check supplied IBAN, LEI, Belgian VAT and UK company-number fields') and the phrase 'in one result' distinguishes it from the single-identifier siblings like iban_check, lei_check and vat_mod97_check. An agent can tell this is a bundled multi-field validator 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?

'Structural checks only; no ownership, registry or fraud clearance' is an explicit when-not boundary that tells the agent this tool cannot satisfy due-diligence screening. However, it never names an alternative for identifier-by-identifier checks, so the 'when to use this vs the individual siblings' decision 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.