openfang-rail

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

Annotations already declare read-only and idempotent behavior, so the bar is lower. The description adds meaningful context by specifying the exact weighting scheme, clarifying that this is a local checksum validation and not format-only or database verification.

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 concise sentence that front-loads the purpose and includes the necessary algorithmic detail. There is no redundant text or repetition 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?

For a one-parameter read-only checksum validator with an output schema, the description is complete. It states the resource, the algorithm, and implicitly scopes the check to checksum validity, which is exactly what an agent needs to call it correctly.

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

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

Schema coverage is 100%: the single param aba_routing is fully described as a 9-digit US bank routing number. The description adds no further parameter detail beyond the checksum context, 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 a specific verb ('Validate'), a precise resource ('US ABA routing number'), and the exact method ('(3,7,1)-weight mod-10 checksum'). This clearly separates it from sibling validation tools like luhn_check or iban_check.

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

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

The intended use case is implied: an agent should use this tool when asked to validate a US ABA routing number via checksum. However, there are no explicit 'use this instead of X' or 'do not use when...' guidelines, even though many sibling checks exist.

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

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

Annotations already cover readOnly, idempotent, and openWorld false, lowering the bar. The description adds the important constraint that this is only a checksum validation, not a registry lookup, which sets correct expectations about what the tool does not do.

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 carries purpose, resource, country, algorithm, and length, with zero filler. The title and description do not redundantly restate each other to an excessive degree.

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 one required parameter, an output schema, and annotations that establish safety and idempotency, nothing needed to call this tool correctly is missing. The description fully explains the tool's scope.

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 one parameter is well documented with format and space allowance. The description augments this by stating the checksum criterion a valid value must satisfy.

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 ('Validate'), a resource ('Australian Business Number'), and the validation method ('mod-89 checksum') in a single sentence. This clearly distinguishes abn_check from sibling tools like vat_mod97_check or company_number_format.

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 resource is named explicitly, so an agent can infer when to use it: whenever an Australian Business Number needs checksum validation. It does not list alternatives or exclusions, so it stops short of a 5, but the context is unambiguous enough for a 4.

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 meaningful behavioral context: it returns 'raw units and decimals provenance' and is 'preflighted so you never pay during an RPC outage'. This goes beyond the structured annotations without contradicting them.

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 with no wasted words. The core scope is front-loaded, followed by key behavioral details and the preflight safety guarantee.

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 full input schema, an output schema, and annotations covering read-only/idempotent behavior, the description supplies the remaining essential context: combined ETH + token coverage, default token, raw units/decimals, and RPC-outage protection. Nothing critical 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?

Schema description coverage is 100%, so the schema already documents address and token_address well. The description reinforces that token_address defaults to USDC on Base but does not add substantial new meaning 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 states a specific verb and resource: 'On-chain balance snapshot: native ETH balance plus one ERC-20 token balance (defaults to USDC on Base)'. This clearly distinguishes it from sibling tools like erc20_balance, which likely covers only token balances, and crypto_ticker, which is not an on-chain snapshot.

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

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

The description gives clear context: use this when you need both native ETH and one ERC-20 token balance, with a default of USDC on Base. However, it does not explicitly state when to prefer this over alternatives like erc20_balance or when not to use it, leaving some inference to the agent.

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

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

Annotations readOnlyHint=true and idempotentHint=true already tell the agent the call is read-only and idempotent. Beyond that, the description discloses the paid nature, the single-voucher/settlement flow, and the signed XDR-1 receipt for the entire batch, which is genuinely useful behavioral context not present in the structured fields.

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

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

Two sentences carry the core capability, pricing, and billing behavior without fluff. The enumeration of 17 check types is a bit long but serves as a quick inventory for the agent; however, this list partially duplicates the schema enum and could 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?

With one parameter, a rich schema, and an output schema present, the description covers the essential operational details: max count, cost model, and per-batch receipt. It does not explain partial-failure behavior, but the output schema likely covers per-item results, so nothing critical seems 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?

The input schema has full description coverage for the only parameter, items, including the {tool, value} shape and max/min bounds. The description enumerates the acceptable check types, but these are already in the schema enum, and it adds no new parametric meaning beyond what the schema provides, 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?

The description opens with a specific verb and resource: 'Run up to 50 identifier checks in ONE paid call,' so the agent immediately knows it is a batch execution tool. It also distinguishes itself from the many single-check sibling tools by emphasizing the batch scope and the one-payment model.

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

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

The description makes the batch-vs-single tradeoff explicit with 'one voucher, one settlement' and 'at 50 items, 10x cheaper per check than single calls,' which tells an agent this is the cost-efficient route for multiple validations. It does not explicitly state when to choose a single-check sibling instead, but the context strongly implies that for one check you would not use a batch 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?

Annotations already establish the operation is read-only and idempotent. The description adds a non-obvious behavioral guarantee: it is preflighted to avoid payment during an RPC outage, which is useful cost/safety context. There is nothing that contradicts 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?

Two short sentences with no filler. The first sentence front-loads the output fields and scope, and the second adds risk-relevant behavior. 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?

With one optional, fully documented parameter, an output schema, and read-only/idempotent annotations, the description covers the essentials: what is returned, the default, and a unique behavioral safeguard. It is complete enough for an agent to invoke correctly, though 'Base' might benefit from explicit clarification as the network name, keeping this at a 4 rather than 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?

The sole parameter block is 100% covered in the schema, including formats and default 'latest.' The description's 'Latest (or specified)' restates the default without adding syntax or semantic detail, so the baseline of 3 applies.

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

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

Description clearly identifies the resource returned (Base block header) and lists its fields (number, timestamp, transaction count, base fee), which distinguishes it from sibling tools that check balances, transactions, or formats. It lacks an explicit verb like 'retrieve' or 'fetch,' and does not mention alternatives, so it is clear but not maximally differentiated.

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 guidance on when to choose this tool over alternatives, nor any exclusions or side-by-side comparisons with siblings. The only hint is that it can return specified or latest block info, which is self-evident. This is a minimal-viability omission.

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 mark the tool as read-only and idempotent; the description adds an important behavioral boundary by stating format-only validation and excluding existence checking. This helps the agent set expectations and distinguishes this operation from lookup or verification tools.

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, front-loaded sentence that states the exact operation and its limitation without wasted words. Every word contributes to understanding the tool’s purpose and boundary.

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 one fully documented parameter, a provided output schema, and annotations covering read-only and idempotent behavior, the description is complete for safe invocation. The explicit 'not existence' qualification closes the main ambiguity, making the tool self-sufficient.

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 describes the single parameter fully as '8 digits, or 2 letters + 6 digits', giving 100% schema coverage. The description adds no additional parameter detail, but none is needed 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?

Description uses a specific verb ('Validate') with a clearly identified resource ('UK Companies House number format') and clarifies it does not check existence. Among the sibling validation tools, this uniquely targets Companies House format, so an agent can distinguish it from e.g., ein_format_check or isbn_check.

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

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

The description implies the correct use case: validating UK company number format, not entity existence. It does not explicitly name an alternative or state when-not-to-use, but the clear scope ('not existence') provides sufficient contextual guidance for an agent.

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

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

Annotations already provide readOnlyHint and idempotentHint; the description adds useful behavioral context by explicitly stating 'Pure function — no external calls, no ML' and detailing stop-word exclusion for the word frequency computation. This goes beyond the structured annotations and clarifies side-effect-free behavior without contradicting them.

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 compact sentence that front-loads the core purpose, lists concrete outputs, and ends with the pure-function guarantee. Every clause contributes useful information with no repetition or 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, pure, deterministic utility with an output schema and clear annotations, the description covers the essential behavior: what is computed, how stop words are handled, the hashing algorithm, and the absence of external dependencies. Nothing critical is missing for an agent to select and invoke it correctly.

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

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

Schema coverage is 100% and the sole parameter 'text' is already well described in the schema, including arbitrary length and exact-input hashing. The tool description adds no new parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description states a clear operation ('deterministic text digest') and enumerates the exact outputs: word count, top-5 frequent words, first sentence, and keccak-256 hash. It is readily distinguishable from the sibling validation/lookup tools, though it does not explicitly name an alternative or contrast itself with one by name.

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

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

The description implies usage: it is a pure, deterministic utility for text analysis and hashing, which is appropriate given the text input. However, it does not explicitly state when to use this tool versus alternatives or mention exclusions/limitations such as unsuitable text formats.

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 convey read-only and idempotent behavior. The description adds useful behavioral context: 60s server-side caching, automatic ticker mapping, use of the public CoinGecko API, and preflighting to avoid paying during outages. This goes beyond the structural annotations and helps an agent understand edge-case 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 dense sentences with no filler. The primary purpose is front-loaded, followed by caching and outage behavior. Every sentence contributes meaningful 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?

For a one-parameter read-only tool with a full input schema and an output schema, the description covers the essential operational details: price type, currency, API source, ticker mapping, caching, and outage handling. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100% and the single symbol parameter is already well described. The description adds value by explaining that common tickers are mapped to CoinGecko ids automatically and by providing an example, which clarifies accepted input formats beyond the schema alone.

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 clearly states the tool returns the current USD spot price for a symbol via CoinGecko, which identifies the verb-like operation, resource, and output. The mention of automatic ticker-to-id mapping further clarifies scope and differentiates it from the many validation/check siblings.

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 to use it: whenever a current crypto spot price is needed. It also provides context about caching and outage resilience, but does not name explicit alternative tools or when-not-to-use conditions. This is clear context without 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 and idempotentHint, and the description adds meaningful behavioral detail about the checks performed: country code presence, digit count, and forbidden leading zero. It does not describe the exact return value, but an output schema exists and the operation is a simple read-only validation.

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 compact sentence with the validation criteria front-loaded. There is no redundant wording or filler, making it easy for an agent to quickly parse the tool's purpose.

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 read-only/idempotent annotations and an output schema, the description fully covers what is validated and under what rules. No critical information needed to invoke the 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 phone parameter already has a description and example. The tool description adds value by explicitly defining the E.164 structural constraints that the parameter must satisfy, going beyond the schema's generic 'International phone number' phrasing.

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 ('Validate') and a concrete resource ('a phone number's E.164 structure'), then enumerates the exact validation rules: +CC, 8-15 digits, no leading zero. This clearly differentiates it from sibling format validators such as luhn_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?

The description clearly identifies the validation target and criteria, so an agent can infer when to use this tool. It does not explicitly name alternatives or when-not-to-use conditions, but the E.164-specific rule set provides strong contextual 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 read-only, idempotent behavior. The description adds algorithmic transparency by specifying the exact checksum calculation (odd positions x1, even positions x3), making it clear the tool only mathematically validates the barcode rather than confirming real-world product existence.

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, tightly worded sentence that front-loads the core purpose and immediately gives the algorithmic detail. There is no filler or repetition of the schema or annotations.

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 validator with full schema coverage, an output schema, and read-only/idempotent annotations, the description provides enough context. The checksum algorithm is specified, and no critical behavioral detail needed to call the 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%; the parameter `code` is fully described in the schema as a 13-digit EAN-13 barcode with spaces/dashes allowed. The tool description adds no new parameter meaning 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 ('Validate'), a specific resource ('an EAN-13 barcode'), and the validation mechanism ('mod-10 checksum'). This clearly distinguishes it from generic check tools like luhn_check by specifying odd/even position multipliers.

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

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

The description implies when to use the tool: when validating an EAN-13 barcode. However, it does not explicitly state when not to use it or mention alternatives such as luhn_check or ean-specific registry checks, leaving some 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 and idempotentHint. The description adds a crucial behavioral trait: since no public checksum exists, the tool only validates format and cannot confirm a real EIN. This prevents agents from over-interpreting results and goes beyond the structured 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?

Two short sentences with no filler. The core action and the key limitation are both front-loaded. Every word 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 validation tool with a high-coverage schema, a true output schema, and read-only/idempotent annotations, the description covers the essential behavioral caveat (no checksum). No missing information that would prevent 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 coverage is 100%; the property description already includes '9 digits; dashes/spaces allowed.' The description's format pattern (NN-NNNNNNN) and example reinforce the hyphen placement but add little beyond what the schema already provides. 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 the verb 'Validate' with resource 'US Employer Identification Number FORMAT' and specifies the exact format pattern (NN-NNNNNNN). The caveat 'No public EIN checksum exists' distinguishes it from sibling checksum-based validators (e.g., luhn_check, vat_mod97_check).

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

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

The description implies when to use it—when format validation for a US EIN is needed—but does not name alternatives or state when not to use it. The 'No checksum' note hints at a limitation but doesn't explicitly route the agent to sibling tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavior beyond that: it returns both raw and formatted values, reads decimals on-chain with a labeled common-list/18 fallback, and preflights calls so the user avoids paying during an RPC outage. This is meaningful transparency for an RPC-backed read.

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 sentences with no fluff. The core function is front-loaded, and the parenthetical about decimals plus the preflight note both earn their place by adding decision-relevant behavior.

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 output schema and annotations, the description is largely complete: it covers the token contract scope, decimals behavior, formatted results, and cost protection. It could be slightly fuller by mentioning supported networks or explicit exclusions, but none are critical for an ERC-20 balance lookup.

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 covers all parameters with 100% description coverage, so the description does not need to repeat parameter semantics. It adds slight context around decimals fallback via the phrase 'common-list/18 fallback is labeled,' but this mostly mirrors the schema's decimal override description.

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: 'Raw + formatted ERC-20 balanceOf for an address at any token contract.' This clearly differentiates the tool from generic balance checkers like balance_check by scoping it to ERC-20 tokens at a specified contract address.

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

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

The description implies the use case: retrieve an ERC-20 token balance for a holder address at a particular token contract. It does not explicitly name alternatives or state when not to use the tool, though the ERC-20 scoping provides some context against sibling tools.

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

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

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?

Annotations already cover readOnly and idempotent hints, so the bar is lower. The description adds meaningful behavior beyond annotations: validation is offline, has no bank lookup, and uses a specific algorithm, which tells the agent exactly what this tool will and will not do.

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 tight sentence delivers the core action, the exact validation standard, and a critical limitation ('offline, no bank lookup'). Every part adds decision-relevant value with no waste.

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 one fully documented required parameter, an output schema present, and annotations covering read-only/idempotent behavior, the description provides all essential context: what is validated, how, and what is explicitly out of scope.

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

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

The single parameter is fully documented in the schema (100% coverage) with type, requirement, description, and an example including spaces. The description does not need to repeat parameter details, 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?

The description uses a specific verb ('Validate'), names the exact resource ('an IBAN'), and states the validation method ('ISO 13616 structure and MOD-97-10 checksum'). The 'offline, no bank lookup' qualifier also distinguishes it from lookup-oriented bank tools among the siblings.

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 signals when to use this tool: when an IBAN needs structural/checksum validation without bank involvement. It does not name alternatives or explicit exclusions, but 'offline, no bank lookup' gives enough context to avoid choosing it for account-status or balance inquiries.

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, so the description doesn't need to repeat those. It adds useful behavioral detail by specifying the exact pattern (BBBB0NNNNNN) and the invariant 5th character, making what the validator checks explicit.

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 short, front-loaded sentence conveys the action, the target, and the critical validation rule with no filler. Every token 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, read-only validator with an output schema and full schema coverage, the description provides all necessary call context. Nothing material 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?

The input schema already describes the single 'ifsc' parameter at 100% coverage. The description goes further by explaining the internal format rule (5th character always 0), which adds meaning beyond the schema's '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?

The description uses a specific verb ('Validate'), identifies the exact resource ('Indian IFSC'), and gives the RBI structural rule. This clearly differentiates it from sibling validators like aba_routing_check, abn_check, and gstin_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 establishes clear context: use this tool when validating an Indian IFSC against RBI structure. It doesn't explicitly name alternatives or non-use conditions, but the target code type is distinctive enough to guide selection among many format-check siblings.

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 and idempotentHint=true, so the safety profile is covered. The description adds concrete algorithm details (mod-11,1,3-weight mod-10), making the deterministic behavior transparent without promising side effects or extra 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 a single,front-loaded sentence that names the action and scope immediately, then adds only the algorithm details needed to disambiguate. There is no filler or repetition.

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

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

For a one-parameter, deterministic validation tool with an output schema and read-only annotations, this description is complete. The agent can understand what it validates, how it validates, and the schema covers inputs and outputs without the description needing to repeat return semantics.

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 has 100% coverage; it already tells the agent the ISBN can be ISBN-10 or ISBN-13 and that dashes/spaces are allowed. The description adds no parameter-specific meaning beyond that, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Validate') and a precise resource ('ISBN-10/ISBN-13 checksum'), and even names the exact algorithms (mod-11 and 1,3-weight mod-10). This clearly differentiates it from generic sibling tools like luhn_check or ean13_check without requiring schema inspection.

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 establishes the tool's context: validating ISBN-10/ISBN-13 checksums. It gives enough information for an agent to select it among many sibling check tools, but it does not explicitly mention alternatives or exclusion cases, so it stops short of a 5.

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

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

Annotations already declare the tool read-only and idempotent, so the bar is lower. The description adds meaningful behavioral detail by specifying the structure check and the Luhn mod-10 computation with the A=10…Z=35 conversion, making the validation logic transparent beyond what annotations provide.

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

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

The description is a single, focused sentence that communicates the core functionality and algorithm without any filler. It is front-loaded with the primary action and resource.

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

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

Given a single parameter, a detailed schema description, an output schema, and readOnly/idempotent annotations, the description fully covers what an agent needs to understand the tool's behavior. No missing context is critical 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 coverage is 100% and the parameter description already details the 12-character format and allowed spaces. The description adds value by explaining the transformation to numeric values, which is relevant to the validation semantics and not present in the schema field description.

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 ('Validate') with a well-defined resource ('ISIN (ISO 6166)') and explicitly names the validation method (structure plus Luhn mod-10 over the converted string). This clearly separates it from generic checkers like luhn_check and other instrument-specific validators among the siblings.

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 states the tool validates an ISIN, which gives an agent direct context for selecting it. It does not explicitly call out alternatives or exclusion cases, but the specialized resource and algorithm make the intended use 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 declare readOnlyHint and idempotentHint, and the description adds behavior beyond that by specifying the exact validation scope: ISO 17442 structure plus ISO 7064 MOD-97-10 check digits. It does not describe error handling or invalid-input behavior, but the existing output schema reduces that burden.

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 entire description is a single front-loaded sentence with no filler. Every word contributes to explaining the tool's purpose or validation method.

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

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

For a simple single-parameter, read-only validator with an output schema and clear annotations, the description is complete. It states what is validated, which standards apply, and the specific algorithm involved, so an agent has enough information to call the tool correctly.

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

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

The input schema already describes the 'lei' parameter as a 20-character Legal Entity Identifier, giving 100% schema coverage. The description adds value by naming the applicable ISO standards and the MOD-97-10 check-digit rule, which deepens the agent's understanding of what valid input must satisfy.

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 ('Validate') and a clearly defined resource ('Legal Entity Identifier'), and it adds the governing standards (ISO 17442 + ISO 7064 MOD-97-10). This makes the tool's purpose unambiguous and distinguishes it from the many sibling check tools by naming a unique 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 makes the usage context clear: use this tool when you need to validate a Legal Entity Identifier. It does not explicitly contrast with sibling tools or state when not to use it, but the unique resource name provides enough context for an agent to select it appropriately.

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. The description adds the algorithm behavior (Luhn mod-10), the card-style domain, and a safety warning about real card numbers, going beyond what annotations provide.

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

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

Two short sentences with no filler. The core action and algorithm appear first, followed by a critical safety warning. 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, idempotent validator with an output schema, this description captures purpose, algorithm, acceptable input, and a critical real-world usage caution. No missing information would prevent 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?

Input schema covers 100% of the single parameter and already documents digit length and allowed spaces/dashes. The description reinforces the 12-19 digit scope and adds the algorithmic and privacy context, adding value 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 action ('Validate'), a precise input class ('any 12-19 digit number'), and the algorithm (Luhn mod-10). The 'card-style checksums' qualifier distinguishes it from sibling validation tools without needing to open schemas.

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?

Clearly implies the tool is for Luhn/card-style checksum validation and adds an explicit privacy guardrail ('Never submit real card numbers'). It does not explicitly name sibling alternatives or describe when not to use it, but the context is strong enough for correct selection.

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 convey read-only and idempotent behavior. The description adds useful context beyond those annotations by specifying that this is a deterministic rule engine and that the score is explainable, which helps set expectations about consistency and interpretability.

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, tightly packed sentence with no filler. It front-loads the core purpose and follows with the key behavioral qualifiers, making it easy for an agent to parse quickly.

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 100% parameter schema coverage, the presence of an output schema, and annotations covering safety traits, the description is largely sufficient for correct invocation. The only meaningful gap is the lack of explicit routing guidance among related rental tools, but that is more a usage-guideline issue than a completeness issue.

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 parameters are already well-documented individually. The description adds the useful grouping 'red-flag signals,' but it does not provide additional meaning beyond what the schema already states.

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 clearly states the tool computes an explainable rental-fraud risk score from listing red-flag signals, which is a specific resource and function. It distinguishes itself from siblings like rental_verdict by emphasizing 'risk score' rather than a verdict, though it stops short of naming 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 intended context is implied: use this when you have rental listing signals and need a fraud risk score. However, it gives no explicit guidance about when not to use it or which sibling tools (e.g., rental_verdict, rent_deposit_guard) should be chosen instead.

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 convey read-only, idempotent behavior. The description adds 'signed' as a behavioral trait, which is useful but unexplained—an agent cannot tell whether this means a cryptographic signature or simply an authoritative verdict. No contradiction with annotations exists.

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, concise sentence that places the core 'combined verdict' idea first. It earns its place, though it could include a bit more operational guidance without becoming 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?

Given the 10-parameter complexity and existing output schema, the description is minimally adequate but does not explain how the optional inputs affect the verdict or clarify the 'signed' aspect. An agent can likely call it correctly using the schema, but selection guidance and behavioral nuance are thin.

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 every parameter. The description only groups parameters into deposit, landlord entity, and listing risk categories, which adds little beyond the schema's 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 clearly identifies the tool as producing a combined rental due-diligence verdict covering deposit, landlord entity, and listing risk. It distinguishes itself from narrower sibling tools through the 'combined' framing, though it lacks an explicit verb like 'computes' or 'returns'.

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

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

The description implies use case: when a combined verdict across deposit, landlord entity, and listing risk is needed. However, it does not explicitly mention when to prefer this over sibling tools such as rent_deposit_guard, rental_listing_risk, or lei_check, nor does it state any exclusions or 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=true and idempotentHint=true, covering safety and repeatability. The description adds meaningful behavioral detail by specifying the verification logic: IBAN checksum validation, country alignment, and a pre-viewing flag. It does not contradict annotations and gives agents a clearer idea of what the guard evaluates.

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 compact sentence, front-loaded with the rental deposit context. Every element maps to a parameter or check, and there is no wasted wording.

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 read-only three-parameter tool with full schema descriptions, an example, and an output schema, the description and structured fields are largely sufficient. The main gap is the lack of explicit guidance on when to choose this over related rental or validation siblings.

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

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

Schema description coverage is 100%, so the baseline is already met. The description adds value by linking deposit_iban to checksum validation, property_country to country alignment, and deposit_before_viewing to the pre-viewing flag, clarifying how each parameter participates in the tool's logic.

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 domain and the specific checks performed: IBAN checksum, property/deposit country alignment, and pre-viewing flag. It distinguishes this from generic IBAN validation by tying it to rental deposit safety, though it lacks an explicit verb like 'validates' or 'assesses'.

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 'Rental deposit safety' gives clear domain context, and the listed components imply the conditions it evaluates. However, it does not explicitly say when to prefer this tool over siblings like iban_check, rental_listing_risk, or rental_verdict, so routing is partly left to inference.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying exact checksum behavior, clarifying that validation is purely algorithmic rather than a lookup against external data. This goes beyond the structured annotations without contradicting them.

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?

Single sentence, front-loaded with the core purpose, no filler. The checksum weights are compactly embedded rather than elaborated unnecessarily. Every part of the 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?

The tool has one well-documented parameter, an output schema, and annotations covering read-only/idempotent behavior. The description's precise checksum specification fully disambiguates the operation for a simple validation tool. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100% and the parameter is already described as a '7-character SEDOL code.' The tool description does not add significant new parameter-level detail beyond framing it as a UK/Ireland security identifier, so the 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 uses a specific verb ('Validate') and resource ('UK/Ireland security identifier') and names the exact method: the (1,3,1,7,3,9)-weight mod-10 checksum. This distinguishes it clearly from sibling identifier checks such as isin_check or isbn_check, even without opening their schemas.

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 states the intended use: validating SEDOL codes for UK/Ireland securities. It does not explicitly name when-not-to-use cases or alternatives, but the geographic/resource scope gives enough context to route an agent toward this tool versus other 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 mark the tool as read-only and idempotent. The description adds useful behavioral context: it is scoped to ~48h of Base blocks, covers both sent and received USDC transfers, and is preflighted so the user never pays during an RPC outage. This goes beyond what the annotations provide.

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

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

The description is two tight sentences with no filler. It front-loads the core purpose and data returned, then adds the preflight benefit. Everything included 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 one-parameter, read-only tool with an output schema present, the description is complete: it specifies the asset, network, time window, data shape, and a cost/outage safeguard. Nothing needed for correct invocation is missing.

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

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

The schema provides 100% coverage for the single address parameter, including the 0x-prefix format requirement. The description does not add parameter-specific detail beyond what the schema already states, so the baseline of 3 is appropriate.

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

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

The description states exactly what the tool does: it returns USDC transfers sent and received by an address over the last ~48h of Base blocks, including counts, volumes, and sample transaction hashes. This specific scope clearly distinguishes it from generic siblings like tx_activity or balance_check.

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

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

The intended use case is clear: performing an on-chain counterparty check for USDC settlement activity on Base. It does not explicitly name alternative tools or give when-not-to-use guidance, but the asset and time-window scoping is strong enough for an agent to infer appropriate usage.

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 is covered. The description adds behavioral value by clarifying that validation is against ISO 9362 structure, which signals a syntactic check rather than a registry or existence lookup. This is useful context beyond what annotations alone provide.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, target, and standard immediately, then adds only the clarifying structural details. Every element 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 validation tool with an output schema, the description is largely sufficient. It captures the validation target and method, while the schema documents the accepted input format. A slightly stronger description might explicitly state that it does not verify BIC existence, but the 'by ISO 9362 structure' phrasing already communicates that reasonably.

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 description already covers the bic format well (8 or 11 characters; spaces/dashes allowed), so the baseline is 3. The description goes further by explaining the semantic composition of a BIC — bank code, ISO country, location, optional branch — which helps an agent understand the input domain beyond raw format constraints.

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 begins with a specific verb and resource: 'Validate a SWIFT/BIC code by ISO 9362 structure.' It names the exact standard and enumerates the structural components (bank code, ISO country, location, optional branch), making it clearly distinct from sibling validation tools like iban_check or 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?

The intended use is implied: use this tool when you need to validate a SWIFT/BIC code. However, the description does not explicitly mention when to prefer this over sibling validators, nor does it state any exclusions or limitations such as 'this only checks structure, not whether the BIC is registered.'

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 this tool read-only and idempotent. The description adds useful operational context: it uses eth_getCode and nonce, and is preflighted so users do not pay during an RPC outage. 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?

Two dense sentences: the first front-loads the functional outputs, the second adds the important preflight behavior. No filler or repetition.

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

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

With one well-documented parameter, an output schema, and annotations covering read-only/idempotent behavior, the description covers scope, method, heuristics, and outage-related safeguards. Nothing essential 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?

The single parameter is fully documented in the schema with format details ('EVM address, 0x-prefixed'). With 100% schema description coverage, the description does not need to add parameter-level semantics beyond what already exists.

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 resource (EVM address) and concrete outputs: total outbound transaction count, contract check via eth_getCode, and a first-funded heuristic. This clearly distinguishes it from sibling balance/validation tools.

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

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

The description implies use for on-chain activity snapshots, but it does not explicitly state when to choose this tool over sibling tools like balance_check or erc20_balance. No alternatives or exclusions are named, so routing must be inferred from the described outputs.

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 annotations already provide readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the useful qualifier 'structural' to indicate this is a checksum-level check, not a registry lookup, which goes slightly beyond the annotations. It does not describe failure behavior, but the output schema likely covers result details.

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 compact phrase that front-loads the essential concepts: the structural nature of the check and the BE mod-97 family. There is no filler or redundant elaboration.

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 tool with a clear input schema and an output schema, the description is largely sufficient. The main gap is the lack of explicit usage guidance against siblings, but the low complexity and strong annotations keep the definition complete enough for 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 has 100% description coverage, with vat_number already explained as an EU VAT ID using the BE mod-97 checksum with an optional BE prefix. The tool description adds no further parameter-level information, so the schema-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 clearly identifies the checked resource as a VAT number and specifies the exact algorithm family (BE mod-97), so an agent can distinguish it from generic checks like luhn_check or abn_check. It lacks an explicit verb like 'validates' or 'verifies', and 'structural' is not expanded, but the core 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?

No guidance is given about when to choose this tool over alternatives. The description does not state that it only checks structure/checksum rather than registration status, nor does it mention sibling tools such as gstin_check or luhn_check that might be confused with it.

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 provide readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavior beyond that: it is a signed call, checksums each identifier, produces a single verdict and receipt, and bundles multiple checks. This gives the agent a clear sense of what happens when invoked.

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. The core purpose and the main differentiator (one call, one verdict, one receipt, half price) are front-loaded, and every clause adds value.

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 bundled validation tool with an output schema and safety annotations, the description covers the key context: what identifiers are involved, what the user gets (verdict + receipt), and the economic benefit. It could be more explicit about when to prefer this over individual sibling checks, but overall it is adequately 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%, so each parameter is already documented by name and optionality. The description adds only high-level context ('each checksummed, one verdict') without providing additional per-parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description names a specific verb ('Screen'), a specific resource ('a vendor's identifiers'), and the exact set of identifiers (IBAN, LEI, VAT, UK company number). It also distinguishes itself from the individual check tools by highlighting the bundled, single-call nature and the price advantage.

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 to use this tool: when multiple vendor identifiers need to be screened in one call rather than through separate checks. The phrase 'Half the price of four single checks' communicates the trade-off versus alternatives, though it does not explicitly list alternative tool names or state when NOT to use it.

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