openfang-rail

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. The description adds useful behavioral context: it is a deterministic pipeline, requires one payment, and emits a signed receipt covering the whole batch. That goes beyond the annotations and informs the agent about side effects and cost semantics. It doesn't detail failure behavior or whether the call fails as a whole, but the added context is strong.

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 information-dense and front-loaded with 'HIGH-THROUGHPUT DETERMINISTIC PIPELINE', immediately setting the tool apart. Every sentence adds value: what it runs, how many, the payment model, why it's useful. Slightly shouting-heavy capitalization costs a little polish, but the content is well-ordered and not bloated.

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

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

For a tool with a rich input schema, output schema, and clear annotations, the description captures the essential operational context: batching, payment, receipt, and target use case. It lacks an explicit statement about what happens on partial failures (e.g., does one invalid item fail the entire batch?) and doesn't mention its relationship to autonomous_commercial_pipeline, but these are relatively minor given the schema and annotation coverage.

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

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

Schema description coverage is 100%: the single 'items' parameter is documented with type, min/max, and nested properties. The description adds the batching context ('up to 50', 'one paid call') which maps to the maxItems constraint, but it doesn't repeat or enhance the per-item field semantics. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description uses a specific verb ('Run') and resource ('up to 50 business identifier checks') and clearly differentiates this from the single-check sibling tools by emphasizing the batch pipeline ('ONE paid call', 'one voucher, one settlement, one signed XDR-1 receipt'). An agent can immediately distinguish batch_validate from its siblings like iban_check or vat_mod97_check 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?

It states a clear primary use case ('essential for autonomous batch invoice processing') and implies when to use the batch tool over individual checks (10x cheaper per item, up to 50 checks in one paid call). It does not explicitly list exclusions (e.g., 'use single-check tools for fewer than N items'), but the context is strong enough to route an agent correctly.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint), so the bar is lowered. The description adds the behavior that the check is algorithmic – structure and mod-36 cross-sum checksum – implying that this is a format-only validation rather than a database lookup. It does not explicitly disclaim that registered/active status is not verified, but the algorithm detail is sufficient context.

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

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

The description is a single, action-first sentence with no filler. It packs the two validation criteria compactly after the main verb-object, and every phrase 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?

For a simple single-parameter check with an output schema and safety annotations, the description covers the mechanics of the check. The only gap is an explicit reminder that registration status is not verified, which is a minor caveat given the algorithm-based description.

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

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

The schema already documents the single parameter with 100% coverage ('15-character Indian Goods and Services Tax Identification Number'), so the baseline is 3. The description enriches this by decomposing the GSTIN into state code + PAN + entity code + 'Z', giving agents a tangible sense of valid input composition.

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 the specific verb 'Validate' with a clearly delimited resource, 'Indian GSTIN', and names the exact validation criteria (structure and mod-36 checksum). This distinguishes the tool from the sibling family of check tools (iban_check, abn_check, etc.) because the scope is unambiguously India-specific GSTINs.

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 provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools. Usage context must be inferred entirely from the tool's name and the specific identifier type it targets, which is adequate for a family of one-format-per-tool check utilities but leaves routing entirely to the agent's common sense.

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

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

Beyond readOnly/idempotent annotations, it discloses deterministic behavior, checksum-only verification, the signed offline-verifiable receipt, and explicitly warns that a valid checksum does not imply ownership or absence of fraud. This is meaningful behavioral context not present in annotations.

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

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

The description is front-loaded with the core deterministic validation behavior and every sentence earns its place: scope, timing/limitation, anti-pattern warning, and receipt capability.

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 a single fully documented parameter, rich annotations, and an output schema, the description adds the remaining essential context: determinism, scope, limitation, and offline verification. No critical information is missing 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?

The schema fully describes the single 'iban' parameter including spaces allowed, so the baseline is 3. The description adds no parameter-level detail beyond confirming ISO 13616 and structure/checksum scope.

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 ('validates'), resource ('international bank accounts (ISO 13616)'), and algorithm ('MOD-97-10 checksums'), and clearly limits scope to structure and checksum. This distinguishes it from other validation siblings by stating exactly what it does and does not certify.

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

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

It states when to use ('before payout'), what it cannot establish (ownership, beneficiary identity, fraud), and warns against LLM regex validation. It does not name a sibling tool as an alternative, but it gives clear use/no-use context.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description adds that validation is performed by RBI structure—indicating a deterministic format check—and reveals the return artifact as a 'signed XDR-1 receipt.' This gives useful behavioral context that annotations alone do not provide, with no contradictions.

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

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

The description is three short sentences, each adding distinct value: the validation rule, the use-case context, and the return format. It is front-loaded with the verb and pattern, with no redundant 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 validation tool with full schema coverage, an output schema present, and readOnly/idempotent annotations, the description is fully adequate. It explains what the tool does, why it is used, and what it returns, leaving no critical gap for an agent to call it correctly.

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

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

The schema already documents the 'ifsc' parameter as an 11-character code, but the description enriches this with the exact RBI pattern (BBBB0NNNNNN) and the rule that the 5th character is always 0. This goes beyond the schema's minimal length description and clarifies the expected input format.

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 ('Validate') and resource ('Indian IFSC'), and defines the exact structural rule (BBBB0NNNNNN; 5th character always 0). This clearly distinguishes it from sibling validation tools like iban_check or swift_bic_check by pinning down the instrument type and country.

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 'Required for India bank payouts' gives a clear use case and context for when an agent should invoke this tool. It does not explicitly list alternatives or exclusions, but the India-specific framing is sufficient to guide selection among the many sibling checks.

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 signal read-only and idempotent behavior. The description adds value beyond those hints by specifying that the checks are deterministic, structural, and each state their own scope, while 'one call, one receipt' signals the expected response shape. No contradiction with 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 short sentences, each earns its place: the first states the offer, the second defines the behavioral nature, and the third gives the procurement context. There is no filler or redundant restating of schema fields.

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

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

Given the rich annotations, 100% parameter coverage, and presence of an output schema, the description is complete enough. It supplies the missing decision-making context: why this tool exists, when to use it, and what kind of result to 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?

Schema description coverage is 100%, so the schema already documents each parameter's format and optionality. The description lists the four identifiers and frames them as a combined verification pack, but it does not add parameter-level semantics 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?

The description names a concrete deliverable: one call returns a receipt of GSTIN, PAN, UPI VPA, and IFSC structural checks for an Indian counterparty. It clearly distinguishes itself from single-identifier siblings like gstin_check and ifsc_check by being a combined pack, even though those siblings are not named.

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

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

The description gives a clear intended context: cross-border procurement where the buyer is an agent that cannot open an INR account. It implies one call instead of four separate checks, but it does not explicitly state when NOT to use it or name alternatives like batch_validate or vendor_onboarding_pack.

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 and idempotentHint, and the description adds useful behavioral context: deterministic validation, the ISO 7064 MOD-97-10 algorithm, and a 'signed XDR-1 receipt' return. There is no contradiction with 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?

The description is compact and front-loaded with the critical purpose, followed by use cases and return value. The leading 'CRITICAL B2B KYB CHECK' is somewhat redundant with the title but does not introduce meaningful bloat.

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 validation tool with an output schema and supporting annotations, the description is complete: it defines the identifier standard, the algorithm, when to call it, and what it returns. No essential decision-making context is missing.

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

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

Schema description coverage is 100%, with the 'lei' parameter described as a '20-character Legal Entity Identifier.' The description adds the ISO 17442 standard and check-digit algorithm, but does not materially expand parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Deterministically validates Legal Entity Identifiers (ISO 17442) with ISO 7064 MOD-97-10 check digits for institutional entities.' This clearly distinguishes lei_check from the many sibling identifier-validation tools by naming the exact identifier standard and algorithm.

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

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

The description gives explicit trigger contexts: 'Call before entering contracts, issuing contractor payments, or verifying corporate counterparties.' It does not explicitly name alternative tools or state when not to use this check, but the LEI-specific scope makes the context unambiguous relative to sibling checks.

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, and open-world semantics. The description adds that it produces a signed XDR-1 receipt and lists the screening criteria (e.g., '<30d = scam'), which are useful behaviors beyond the annotations. It does not explicitly state failure handling, but this is a minor gap given the annotations and output schema.

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

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

The description is concise and front-loaded with the primary purpose. It uses a short sentence plus a list of checks and an output note, with no redundant filler. The title also reinforces the usage context without repeating the full description.

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 tool has 8 optional parameters and an output schema, the description is sufficiently complete: it specifies inputs (implicitly via check list), the checks performed, and the output (signed receipt). It does not detail the receipt contents, but that is covered by the output schema. Overall, an agent can call this tool correctly based on the description alone.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description enhances parameter understanding by explaining how parameters are used in the checks (e.g., vendor_domain for domain age and disposable email detection, declared_country for BEC mismatches), adding meaning beyond the individual field descriptions.

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

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

The description explicitly states the tool's core function: verifying counterparties before disbursements, and enumerates the specific checks (IBAN, domain age, email domains, CRN/LEI, BEC mismatches). This clearly differentiates it from sibling single-purpose checkers like iban_check or lei_check by positioning it as a comprehensive due-diligence guard.

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 signals mandatory usage ('MANDATORY', 'Check Before You Send') for pre-disbursement scenarios, implying it should be used before releasing payments. However, it does not explicitly name alternatives or contrast with the individual check tools, though the title and context make the intended use reasonably clear.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral details: the tool is stateless, free, has no quota, and performs no storage. It also discloses the exact verification algorithm and clearly limits the meaning of a valid receipt, preventing over-interpretation of results.

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

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

The description is three sentences with no filler. The first sentence front-loads the primary purpose and algorithm, the second adds operational constraints, and the third sets expectations for what the result means. Every sentence contributes information an agent needs.

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

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

Given the single parameter, full schema coverage, presence of an output schema, and annotations for read-only/idempotent behavior, the description covers all essential context. It explains the verification process, the statelessness, and the semantic limits of the result, leaving no critical gap for correct invocation.

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

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

Schema description coverage is 100%, so the single 'receipt' parameter is already fully documented in the schema, listing all required fields and optional extensions. The tool description adds context about what the tool does with the receipt, but it does not add new parameter-level detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource — 'verifies a signed XDR-1 receipt' — and explains exactly how verification works: recomputing the canonical digest, recovering the signer, and comparing it to the declared signer. It clearly distinguishes this from sibling format checks like iban_check or luhn_check by emphasizing ANY x402 service and the cryptographic nature of the receipt.

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 provides clear context for when to use the tool: verifying a signed XDR-1 receipt from any x402 service, with no account, quota, or storage required. It also explicitly states a when-not: it does NOT prove funds moved or any business claim. However, it does not name any alternative tools or more explicitly contrast this with related payment/verification 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?

The description is transparent about deterministic behavior and the curated local blocklist, but it contradicts the openWorldHint annotation. It says 'Absence of a match is not a sanctions clearance,' implying an open-world result, while openWorldHint is false, suggesting a closed-world result. This is an annotation 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?

The description is two concise sentences with no filler. The core purpose and scope are front-loaded, and the caveats follow immediately. 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?

For a single-parameter deterministic screen with an output schema and readOnly/idempotent annotations, the description fully covers scope, limitations, and follow-up usage. The only issue is the openWorldHint contradiction, which is already reflected in behavioral transparency.

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

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

There is only one parameter, subject, and schema description coverage is 100%. The schema already documents that it accepts an EVM address or ISO 3166-1 country code/jurisdiction name, so the description adds no additional parameter-level semantics. Baseline 3 is appropriate.

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

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

Description states a specific verb and resource: 'Deterministic screen of EVM addresses and jurisdictions against a curated local blocklist.' It explicitly distinguishes itself from name-based screening and a complete OFAC SDN check, so an agent can clearly understand what this tool does and does not do.

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 explicitly marks exclusions: 'NOT name-based screening and NOT a complete OFAC SDN check.' It also gives clear usage context: 'use as one informational input alongside your own compliance process.' This leaves little ambiguity about when to rely on the tool.

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

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

The description adds meaningful behavioral context beyond the annotations: it clarifies the check is structural (ISO 9362 format and country code), not a live network or bank existence verification, and states that it 'Returns signed XDR-1 receipt,' informing the agent about the output artifact. No contradiction with the readOnlyHint or idempotentHint annotations.

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

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

The description is three sentences with no wasted words. It front-loads the primary action and validation criteria, then adds usage context, and finally states the return behavior. 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?

For a single-parameter validator with strong annotations and an output schema, the description is fully sufficient: it explains what the tool does, when to use it, what it validates, and what it returns. There are no significant gaps an agent would need to fill.

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

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

The input schema already fully describes the only parameter 'bic' with details about length and allowed characters, so the description adds little new semantics. The mention of ISO 9362 structure is helpful but does not significantly enhance the parameter's meaning beyond what the schema provides, matching the baseline for high schema coverage.

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 ('Validate'), a specific resource ('SWIFT/BIC code'), and the exact standard used ('ISO 9362 structure'), listing the relevant components: bank code, ISO country, location, optional branch. This clearly differentiates it from sibling validation tools like iban_check or ifsc_check, even without naming 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?

The description gives explicit usage context: 'Run before foreign wire transfer dispatch to prevent routing rejection.' This tells an agent when to invoke the tool, though it does not explicitly mention exclusions or alternative tools. It is clear enough for selection in most scenarios.

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 read-only and idempotent behavior; the description adds that validation is deterministic and returns a signed XDR-1 receipt for accounting defense. This is useful behavioral context beyond the annotations, with no 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?

The core validation sentence is clear and front-loaded, but 'CRITICAL TAX COMPLIANCE CHECK' and 'Eliminates cross-border invoicing errors, invalid billing, and tax audit penalties' are marketing overclaims that do not add operational value. The description is short but not 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?

For a single-parameter read-only check with an output schema and annotations, the description is largely sufficient. It could be more precise about whether non-BE EU VAT numbers are accepted, since 'EU/BE' is ambiguous, but the schema's 'BE mod-97 checksum' phrasing partially resolves this.

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

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

Schema coverage is 100%: the single parameter 'vat_number' is already described as 'EU VAT id; BE mod-97 checksum (BE prefix optional).' The tool description adds no significant parameter-level meaning beyond the schema, so the high-coverage 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 opens with 'Deterministically validates EU/BE VAT identifiers with MOD-97 checksums,' giving a specific verb and resource. It clearly distinguishes this tool from sibling validation tools such as iban_check, gstin_check, and luhn_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?

It clearly frames the tool as a tax-compliance check for cross-border invoicing, so an agent can infer when to use it. However, it does not name alternatives or specify when not to use it, such as when a live VAT registration lookup is required.

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 idempotent behavior, so the description benefits from a lower bar. It adds meaningful behavioral context beyond annotations: the call is 'signed,' it produces an 'audit-ready compliance report' and a 'signed XDR-1 receipt,' and it is intended as a pre-payment fraud defense. No contradiction with annotations.

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

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

The description is compact and front-loaded: the core function appears first, followed by a cost-benefit statement and the compliance outputs. Every sentence contributes a distinct piece of information, with no filler or tautology.

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 and annotations covering read-only/idempotent safety, the description does not need to explain return values. It covers the main scenarios, outputs, and value proposition. The only minor gap is clarity around optional-parameter combinations, which is partially mitigated by the schema marking all parameters 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 description coverage is 100%, and the input schema already documents each parameter as an optional vendor identifier. The description restates the parameter set (IBAN, LEI, VAT, company number) but adds no semantic detail beyond the schema, such as whether at least one identifier is required or how combinations affect the result. 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 ('screens'), a clear resource (vendor IBAN + LEI + VAT + UK company number), and the combined one-call nature that distinguishes it from sibling individual-check tools. It also communicates the output artifacts (compliance report, XDR-1 receipt), making the tool's role unmistakable.

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 clearly implies when this tool is preferred: when multiple vendor identifiers need screening in one call, especially 'before funds move.' It positions the tool against the alternative ('Saves 50% vs individual checks'), though it does not explicitly name the sibling tools or state when NOT to use it, such as when only a single identifier check is needed.

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