code402

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description adds substantive economics beyond them: one voucher, one settlement, one signed XDR-1 receipt covering the whole batch. That billing/settlement behavior is exactly the kind of context the agent cannot infer from annotations. It does not state failure semantics for a partially invalid batch, 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?

Dense single block with the throughput and one-payment points front-loaded; every clause carries information. The all-caps framing and marketing superlatives ('10x cheaper') are slightly stylistic overhead but do not obscure the meaning.

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 description covers batch size, supported checks, and the one-payment model. Missing only edge-case behavior (what happens when some items fail validation in a batch), which is a minor gap for this tool.

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

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

Schema description coverage is 100% and the enum already lists every supported validator, so the description's enumeration of IBAN/LEI/VAT/... duplicates structured data rather than extending it. Baseline 3 is appropriate; no syntax or constraint detail (e.g. per-item error behavior) is added.

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: run up to 50 identifier checks in one batch call, enumerating the exact validator types supported. It is clearly distinguishable from the single-check siblings (iban_check, lei_check, etc.) by its batching scope.

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

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

Gives a clear when-to-use context ('essential for autonomous batch invoice processing') and a cost rationale ('10x cheaper per item'), which implies the alternative is issuing many single-check calls. It never explicitly names the sibling single-check tools as the alternative for small jobs, so it stops short of full routing guidance.

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

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

Annotations already declare 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 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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial context beyond them: deterministic checksum-only scope, the critical limitation that a valid checksum does NOT establish ownership/beneficiary identity/absence of fraud, and the offline-verifiable signed receipt return. This is exactly the disclosure a fraud-sensitive validator needs.

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

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

Front-loads the definition (validates, standard, algorithm) before the scope caveat and the anti-pattern warning. Dense but every clause carries weight; slightly long but none of it is filler, so just shy of a 5.

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

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

For a single-parameter validator with annotations covering safety and an output schema covering the receipt, the description supplies the remaining essentials: determinism, checksum-only scope, the fraud-misattribution caveat, and the return artifact. Nothing an agent needs to call it correctly is missing.

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

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

Only one parameter with 100% schema description coverage ('IBAN to validate; spaces allowed'), so the schema already carries the semantics. The description adds no format or syntax detail beyond the schema, 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 (validates) plus resource (international bank accounts / IBANs), names the exact standard (ISO 13616) and algorithm (MOD-97-10), and clearly scopes the operation to structure and checksum only. An agent can distinguish this from siblings like swift_bic_check or batch_validate without opening the schema.

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

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

Gives clear context ('before payout') and an explicit negative directive against validating with LLM regexes, which tells the agent when not to hand-roll the check. However it does not route to sibling alternatives (e.g., batch_validate for bulk, or receipt_verify for the returned receipt), so routing guidance is partial.

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

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

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds the RBI format rule and the fact that it emits a signed XDR-1 receipt, which is useful workflow context beyond the annotations, though nothing about rate limits or failure 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?

Three compact sentences, each carrying distinct payload (what, format, workflow need, output), with the core action front-loaded and zero 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-only validator with an output schema and full schema coverage, the description supplies everything needed to select and invoke it correctly; return-value detail is rightly 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 100% schema coverage the baseline is 3, but the description goes further by spelling out the BBBB0NNNNNN pattern and the always-zero 5th character, adding real constraints beyond the schema's generic '11-character' note.

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

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

States a specific verb (validate) and resource (Indian IFSC) plus the exact structural rule it enforces, so an agent can tell it apart from siblings like iban_check, swift_bic_check, or gstin_check 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?

'Required for India bank payouts' gives a clear context for when to reach for this tool. It does not name alternatives or exclusions, but the domain constraint is explicit enough for correct routing.

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/openWorldHint, so the bar is lower; the description adds that validation is deterministic and that a signed XDR-1 receipt is returned, which is meaningful behavioral context for a compliance tool. It could say more about failure modes or what the receipt attests to, but it adds real value 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, front-loaded with the core action and the usage triggers. The all-caps 'CRITICAL B2B KYB CHECK' is slightly promotional but not wasteful, and every sentence contributes.

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-only, idempotent validation tool with an output schema and rich annotations, the description supplies purpose, standard, usage triggers, and return-format hint. Nothing needed to invoke it correctly is missing.

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

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

With a single parameter at 100% schema coverage, the baseline is 3; the schema already documents the 20-character LEI string. The description only reinforces the identifier standard (ISO 17442), adding 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 (validates), a precise resource (Legal Entity Identifiers per ISO 17442), and the exact validation mechanism (ISO 7064 MOD-97-10 check digits). This clearly separates it from the many sibling checks (iban_check, gstin_check, vat_mod97_check) that validate other identifier standards.

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

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

Gives explicit when-to-use triggers: before entering contracts, issuing contractor payments, or verifying corporate counterparties. It does not name an alternative or state when NOT to use it (e.g., versus batch_validate), so it stops short of full routing guidance.

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

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

Annotations already cover read-only, open-world and idempotent behavior, and the description adds real value beyond them: external RDAP domain-age lookups, disposable-email screening, cross-jurisdiction BEC mismatch detection, and the signed XDR-1 compliance receipt. It stops short of explaining what happens when no parameters are supplied or how failed/partial screens are reported.

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

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

Three dense, front-loaded sentences with no filler; the mandatory-usage cue leads and the check list follows. The all-caps prefix and packed enumeration make it slightly shouty but still efficient.

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

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

With an output schema, full annotation coverage and a fully described parameter set, the description only needs to convey purpose, checks and the compliance artifact, which it does. The remaining gap is the absence of guidance on minimum required inputs given that all eight parameters are optional.

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

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

Schema coverage is 100%, so the baseline is 3, but the description ties checks to specific inputs (IBAN checksum to recipient_iban, domain age to vendor_domain, CRN/LEI format to company_number/lei) and even gives a decision threshold ('<30d = scam'), which adds meaning beyond the schema text.

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 counterparty before releasing invoice payments, contractor payouts, or wires') and enumerates the exact checks performed, so an agent knows precisely what the tool does. It does not explicitly differentiate itself from narrower siblings like iban_check or lei_check that cover a subset of the same signals, which keeps it 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 'MANDATORY ... before releasing invoice payments' framing and the 'Check Before You Send' title give clear context for when to invoke it. No when-not conditions or explicit routing to/from siblings are stated, so it is clear but incomplete on alternatives.

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 establish readOnly, idempotent, openWorld, so the safety profile is covered. The description adds genuinely new behavior: the validation is structural/ISO 9362 only, and it emits a 'signed XDR-1 receipt', which signals an audit artifact is produced. It does not clarify whether the bank/country are checked against a live registry, which is the one 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?

Three sentences, each earning its place: what is validated, when to run it, and what is returned. The action and the precondition are front-loaded 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-value detail is unnecessary, and the annotations cover safety. The only remaining question an agent might have — whether a structurally valid but nonexistent BIC would pass — is left unstated, which keeps this just below a full 5.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds interpretable meaning by decomposing the BIC into bank code, ISO country, location, and optional branch segments, helping the agent understand what each portion of the input represents. It adds no format or syntax detail beyond the schema's own '8 or 11 characters; spaces/dashes allowed'.

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 (Validate) and a specific resource (SWIFT/BIC code) and enumerates the ISO 9362 components checked (bank code, ISO country, location, optional branch). This is clearly distinguishable from sibling validators such as iban_check, lei_check, or gstin_check 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?

It gives explicit timing and motivation: 'Run before foreign wire transfer dispatch to prevent routing rejection.' That tells the agent when the tool belongs in a workflow. It stops short of naming when NOT to use it or which sibling validator to prefer for a non-SWIFT identifier, 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, covering the safety profile. The description adds that the check is deterministic and returns a signed XDR-1 receipt—useful behavioral context beyond the annotations, but no details on authentication, rate limits, or error behavior.

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

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

The description is front-loaded with the core purpose but includes marketing-style benefit claims ('Eliminates cross-border invoicing errors, invalid billing, and tax audit penalties') that do not add operational value. The signed receipt detail is useful, but the overall text could be tightened.

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

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

Given the low complexity (one required parameter), the presence of annotations and an output schema, the description covers the essentials: what it does, how it does it, and that it returns a signed receipt. It lacks usage guidance, but the tool is otherwise well-enough specified to be invoked 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 single parameter is fully documented in the schema. The description adds no parameter-level information beyond what the schema provides, making the baseline score of 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 (validates), resource (EU/BE VAT identifiers), and mechanism (MOD-97 checksums), making the tool's function immediately clear. However, it does not explicitly differentiate itself from the many sibling validators (e.g., gstin_check, iban_check), so it falls short of a 5.

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

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

The description emphasizes benefits ('Eliminates cross-border invoicing errors...') but provides no explicit when-to-use guidance, prerequisites, or alternatives. It does not help an agent decide between this tool and the other validation tools in the sibling list.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, covering the safety profile, so the bar is lower. The description adds that the call is 'signed' and returns an audit-ready report plus an XDR-1 receipt, but gives no detail on what signing entails, auth requirements, or failure modes for a 4-input screen.

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

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

A single front-loaded sentence with a colon that immediately names the operation, followed by benefit/context. Dense but efficient; the marketing framing ('Saves 50%', 'Clearing Shield') is padding rather than 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 not be explained, and annotations cover safety and idempotency. The description conveys purpose, context and output artifacts, though it leaves the all-optional-parameter case and any prerequisites unaddressed.

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

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

Schema coverage is 100% and every parameter carries its own description, so the schema does the heavy lifting. The description adds nothing about parameter format, combinations, or what happens when none of the entirely optional fields are supplied, so it cannot exceed the baseline.

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

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

States a specific verb and resource: screens four named vendor identifiers (IBAN, LEI, VAT, UK company number) in one call. It implicitly distinguishes itself from the individual *_check siblings via 'Saves 50% vs individual checks', but never names them, so the differentiation is inferential rather than explicit.

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

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

Gives a clear usage moment — 'before funds move' and 'to defend against invoice fraud' — which tells the agent when this screening is warranted. It does not state when NOT to use it or explicitly name the single-check alternatives an agent should prefer for narrow needs.

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