JPVerify

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds real context beyond them: a per-call price of $0.005 USDC via x402 on Base, and the explicit limitation that a missing postal code is never inferred. It does not cover failure modes, error responses, or latency, which keeps it short of a 5.

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

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

The English text is front-loaded and well structured (purpose, use-when, returns, cost), but the entire payload is then mirrored verbatim in Japanese, roughly doubling length without adding information a capable model needs. The Use-when clause also restates the purpose sentence rather than extending it.

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

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

With no output schema, the description correctly enumerates the return fields (hierarchy components, confidence, match hierarchy, geocoder and postal evidence) and states the pricing and non-inference guarantee. The main remaining gap is input-side guidance: format expectations for `address` and the effect of `response_language` on the returned English rendering.

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 0% for two parameters. The description says nothing about the `address` parameter's expected script or format (Japanese characters vs romaji) or the length bound, and it never explains the `response_language` enum values ja/en/both, even though output language is the one ambiguity an agent would need clarified.

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 first sentence names a specific verb (normalize), a specific resource (Japanese address), and the output shape (canonical hierarchy with English rendering), which distinguishes it from extraction siblings like jp_receipt_extract. It never explicitly contrasts with the nearest sibling, jp_address_validate, so the boundary is inferred rather than stated.

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

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

"Use when: You need Japanese address normalization or standardization, whether or not the input contains a postal code" gives a clear triggering condition and pre-empts the most likely confusion (postal code presence). However, it names no alternative tool and no exclusion that would route an agent to jp_address_validate 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds information annotations cannot carry: the response status set, the confidence/scope/reason fields, and the pricing model ($0.005 USDC per successful call via x402 on Base), which is a real cost/authorization consideration.

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 English portion is reasonably front-loaded: purpose, use case, return values, price. But the entire block is duplicated verbatim in Japanese, roughly doubling length for the same content, and the parameter names are never mapped explicitly to the input 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 6-parameter, zero-required, evidence-merging tool with no output schema, the description does explain the return statuses and what signals come back. However, it is incomplete on inputs: an agent cannot tell from description or schema what shape 'postal_evidence'/'geocode_evidence' objects take, what 'strict' changes, or how 'required_level' (1-8) affects the verdict.

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 0% across 6 parameters, so the description carries the full burden. It only alludes to three inputs (parsed address, postal evidence, geocode evidence) and says nothing about 'address', 'strict', or 'required_level' (an integer capped at 8), leaving the most confusing parameters unexplained.

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

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

States a specific verb and resource (validate a Japanese address) plus the evidence sources it combines (parser, postal, geocoder) and the outcome taxonomy (exact/partial/ambiguous/conflict/unverified). It never names or contrasts with jp_address_normalize or other siblings, so differentiation is left to the agent.

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?

A 'Use when' clause gives one positive trigger: needing a single evidence-based quality decision combining the three evidence types. There is no 'do not use when', no routing to jp_address_normalize for plain normalization, and no guidance on when partial evidence inputs are acceptable.

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/destructiveHint=false, so the safety profile is covered; the description goes further by disclosing that calls are paid ($0.03 default, $0.10 with enrich) in USDC via x402 on Base, and that only successful calls are charged. It also discloses the verification boundary of the output, which no annotation conveys. This is exactly the kind of non-obvious operational context the description should carry.

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 English text is front-loaded with purpose, then when-to-use, then return scope, then price — a sensible order with no filler. The full Japanese mirror doubles the length, which is defensible for a Japan-focused service but does add bulk without new information for an English-reading agent.

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 10-parameter, paid, no-output-schema tool the description covers cost, output scope, input modality, and the enrich trade-off, which is most of what an agent needs. The notable gap is that zero parameters are required, yet the description never states that at least one of front image, back image, or Base64 must be supplied, nor how conflicting image sources are handled.

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

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

Schema coverage is 70%, and front_image_url/back_image_url/max_pages carry no schema description at all; the description compensates by stating the tool accepts a front/back HTTPS image URL or a small Base64 payload. It also ties enrich=true to a registry pre-check of the organization, though the schema's own enrich description already states the same rule and the costs, so part of this is duplication rather than added meaning.

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 concrete verb and resource plus the accepted input modalities: 'Read a Japanese business card (front/back HTTPS image URL or small Base64)'. It also delimits scope by stating what is excluded ('no corporate-number or NTA issuer verification'), which separates it in practice from jp_company_verify and the invoice-registry siblings. It stops short of naming those siblings, so an agent must infer the routing rather than read it.

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?

An explicit 'Use when' clause enumerates the exact fields that should trigger this tool (person, role, department, company, phone, email, address). The 'Returns ... no corporate-number or NTA issuer verification' line acts as an implicit exclusion toward the verification siblings. An explicit 'if you also need registry/NTA verification, use jp_company_verify' statement is the only missing piece.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: a per-success price ($0.005 USDC) settled via x402 on Base, which is a payment gate the annotations do not express, plus an explicit list of returned fields. It stops short of saying what happens on a no-match or payment failure.

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

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

The English text is well front-loaded (purpose, then 'Use when', 'Returns', 'Price' labels), which is easy to scan. But the entire block is then repeated verbatim in Japanese, doubling length without adding information for an agent, and the 'Returns' section partly duplicates what the caller could infer from the response.

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

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

With no output schema, the description rightly enumerates the returned fields (corporate number, legal name/address, active/closed status, match evidence), and it discloses the paid-call model, so the main call-time questions are answered. The remaining gaps are the address-only mismatch with the schema's anyOf and the unspecified no-match behavior, which matter for a verification tool whose whole value is the negative case.

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 0%, so the description must carry parameter meaning; it covers three of the four inputs (name, 13-digit corporate number, address) but says nothing about response_language and its ja/en/both options, which the agent can only discover from the enum. It also implies address-only verification is possible, while the schema's anyOf requires name or corporate_number — a misleading signal about which argument combinations are valid.

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 first sentence names a specific verb (verify), a specific resource (Japanese company), the three accepted identifier types, and the authoritative source (NTA registry). This distinguishes it clearly from siblings such as jp_address_normalize or jp_business_card_extract, which handle adjacent but different resources.

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 'Use when: You need a Japanese company or corporate-number lookup' line gives clear positive selection context. However, it never names an alternative or exclusion — for example, whether jp_counterparty_check or jp_supplier_resolve should be preferred for risk/sanctions or vendor-onboarding flows — so the agent must infer boundaries from sibling names alone.

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, non-destructive, open-world, so the description correctly spends its words elsewhere: cost ($0.05 USDC per successful call via x402 on Base), that only projected/processed evidence is returned and raw provider payloads never are, and that member-state outages leave coverage insufficient. It still omits failure/refund behavior when a check is unsuccessful despite charging "per successful call".

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

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

The labeled structure ("Use when:", "Returns:", "Price:") is well front-loaded and scannable, with no filler in the English block. The full Japanese restatement roughly doubles the length and adds no information for an English-reading agent, though it is plausibly a deliberate bilingual contract.

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?

Returns, pricing, and safety profile are adequately covered given the readOnly annotations and the absence of an output schema. What remains thin for a 5-parameter, zero-required tool is parameter-level guidance (country_code, response_language, and mutual-exclusion rules among vat_id/participant_id), which no other structured field supplies.

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 0% — the schema offers only titles and types — so the description must carry parameter meaning. It implicitly maps name (name match), vat_id (VAT validity) and participant_id (Peppol discoverability), but leaves country_code (presumably the VAT prefix, 2 chars) and the response_language enum (ja/en/both) entirely unexplained, and never clarifies that all five parameters are optional in the schema despite the "and/or" 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?

Uses a specific verb ("Check") plus a precise resource ("a known EU VAT ID and/or Peppol participant") and enumerates the three outputs: VAT validity, name match, Peppol discoverability. It is clearly separable from the jp_address_*/jp_invoice_* siblings by domain, but it never explicitly contrasts itself with the closest overlaps (jp_company_verify, jp_invoice_issuer_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 "Use when:" clause states the condition for selection (need separate VAT validity, returned-name matching, and Peppol reachability evidence), and the caveat that "VIES is known-ID validation and member-state outages are insufficient coverage" functions as a when-not signal. It gives no explicit routing to a sibling alternative, 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 cover readOnly, idempotent and non-destructive; the description goes beyond them by disclosing the paid-call model ($0.01 USDC per successful call via x402 on Base) and the input ceilings (small Base64, max 1–2 PDF pages). What it does not disclose is failure behavior (e.g. what happens on an unreadable scan or when payment fails), which for a paid OCR call would matter.

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 English block is well front-loaded (purpose, when-to-use, returns, price), but the entire description is then repeated verbatim in Japanese, roughly doubling length with no added information for an agent that already read the first half. Every sentence earns its place in the English block; the mirrored block does not.

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

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

With no output schema, the description carries the return-value burden and does so at a category level (invoice fields plus format, arithmetic, tax, completeness, review status). Combined with the fully described 7-parameter schema and the paid-call disclosure, this is nearly complete; only concrete output shape or error semantics are absent.

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

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

Schema description coverage is 100% and every parameter already carries bilingual descriptions, so the baseline is 3. The description adds only a coarse restatement of the three input modes ('text, HTTPS file URL, or small Base64') with no new syntax or selection rules beyond what the schema 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?

States a specific verb and resource ('OCR a Japanese billing invoice') plus the exact validation scope (local date, tax, arithmetic, T-number checks) and the explicit negative scope ('no registry lookup'). That negative scope separates it cleanly from siblings like jp_invoice_extract_and_verify, jp_invoice_issuer_check and jp_receipt_extract without opening any schema.

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

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

A 'Use when' clause names the situation: Japanese billing-invoice OCR with deterministic quality checks and no registry lookup. The exclusion of registry lookup implicitly routes verification needs to a sibling, though it never names that alternative, so the agent must infer it from the sibling list.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. Beyond that, the description discloses pricing ($0.05 USDC per successful call), x402 payment on Base, and returned components including an explicit review signal. It does not explain failure behavior or rate limits, but it adds substantial operational 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 front-loads purpose and then uses labeled sections for use case, returns, and price. The English/Japanese duplication is redundant for an agent and roughly doubles length, though the structure remains clear.

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 complex OCR-plus-registry resolution tool with no output schema, the description covers purpose, use case, major return categories, and pricing. It leaves the meaning of the 'review signal' and failure behavior underspecified, but input constraints are fully covered by the schema.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description only loosely signals that issuer name/address may be supplied for comparison and that OCR input is supported; it adds no format, precedence, or validation detail beyond the schema.

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

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

The opening sentence gives a specific three-step verb sequence—OCR, validate locally, and resolve the issuer against NTA registries—for a Japanese billing invoice. The composite scope clearly separates it from single-purpose sibling tools such as invoice extraction or issuer-only checks.

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 says to use it when you need invoice OCR plus issuer name/address comparison or completion using NTA public data. It does not state when not to use it or name alternative siblings, so routing between related tools still requires some 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 readOnly, idempotent, non-destructive, and open-world behavior. The description adds genuinely useful context beyond that: what is returned (OCR fields, registry fields, comparison results, resolved values), an explicit scope limit (phone numbers are not registry-compared), and the pricing model ($0.03 USDC per successful call via x402 on Base). It does not cover failure behavior or what happens on a mismatch, so it is strong but not exhaustive.

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

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

The text is front-loaded with the core action, then cleanly labeled sections for usage, return values, and price. The full English/Japanese duplication doubles the length, but that is a deliberate localization choice rather than padding. Every English sentence carries information.

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

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

There is no output schema, so the 'Returns:' enumeration is doing real work by telling the agent what comes back. Combined with the pricing and the phone-number exclusion, an agent has enough to call this correctly and interpret the result. It stops short of describing error or non-match behavior, which matters for a verification tool.

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

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

Schema description coverage is 0%, so the description has to carry parameter meaning. It effectively explains registration_number, supplier_name, and address by describing the comparison it performs. It never mentions response_language or that address and supplier_name are optional, so it only partially compensates for the absent schema 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 states a specific verb and resource: verify a T-number and compare issuer name and address against Japan's NTA registries. That is concrete and actionable. It does not, however, distinguish itself from close siblings like jp_invoice_registration_verify or jp_company_verify, so an agent cannot tell from the text alone which one to pick.

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 'Use when:' line gives a clear precondition: extracted issuer fields needing T-number, company-name, and address comparison. That is enough context to know when it applies. There is no explicit exclusion or routing to an alternative sibling tool, which keeps it 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 readOnly, idempotent, non-destructive, open-world behavior, so the description's added value is the commercial and payment model: $0.01 USDC per successful call via x402 on Base. It also lists the return fields (registration status, corporate number, registered name, dates), useful since there is no output schema. It does not restate the schema's nuance that shape-invalid input is rejected before payment.

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?

Content is well front-loaded and chunked into purpose, use-when, returns, and price. The full Japanese duplication doubles the length without adding new information, though it is defensible for a Japanese-market tool.

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

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

For a two-parameter read-only lookup with no output schema, the description covers purpose, trigger condition, returned fields, and cost/payment mechanism—everything an agent needs before invoking it.

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 registration_number pattern, normalization rules, and the paid-vs-rejected distinction documented in the schema itself. The description adds only the 'T + 13 digits' restatement, so baseline 3 applies.

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

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

The description names a specific verb and resource—verify a Japanese qualified-invoice registration number (T + 13 digits) against the NTA registry. The clause 'You already have a ... number' distinguishes it from extraction-oriented siblings such as jp_invoice_extract_and_verify, so an agent can pick correctly without inspecting 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?

It gives an explicit triggering condition ('Use when: You already have a Japanese T+13-digit qualified-invoice registration number'), which implicitly excludes cases needing extraction first. It does not name a specific alternative tool or state when-not-to-use, which keeps it 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?

Goes well beyond the annotations by disclosing per-call price ($0.03 USDC via x402 on Base), the external NTA registry verification step, and that returned validation is deterministic with field status and review signals. It does not say what happens when a T-number fails registry lookup or how errors/partial OCR are reported, which keeps it from a 5.

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

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

The English text is well front-loaded with labeled 'Use when:', 'Returns:', 'Price:' blocks and zero filler. However, the entire description is then duplicated verbatim in Japanese, roughly doubling token cost for an agent that only needs one rendering.

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

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

With no output schema, the description compensates by enumerating return contents (structured fields, deterministic validation, field status, review signals) and discloses cost and validation limits. For a 7-parameter, multi-source-input tool it is nearly complete, missing only failure-mode behavior.

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 one-of input source rule, page limit, size ceiling and language enum are already fully documented in the schema. The description adds only indirect meaning (that T-number checks relate to registration fields) and no syntax or format detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb+resource ('OCR a Japanese receipt') plus the validation scope (local amount, tax, T-number, NTA registry lookup), which is enough to separate it from jp_business_card_extract or jp_address_validate. It never explicitly contrasts itself with the adjacent jp_invoice_extract / jp_invoice_extract_and_verify siblings, so an agent must infer the receipt-vs-invoice boundary from the noun alone.

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 'Use when:' line gives a clear triggering context (Japanese receipt/領収書 OCR with tax, amount, T-number and format checks), repeated in Japanese for the same audience. There are no explicit exclusions or 'use X instead' routing to the invoice/verification siblings, so it stops short of full when-not guidance.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world, and the description still adds genuinely new behavior: per-call pricing and payment rail ($0.01 USDC via x402 on Base), the four possible outcome statuses, and the feature-flag gated gBizINFO enrichment. The caveat that this is not a legal or KYB determination is useful scoping, though it does not say what happens on payment failure or partial evidence.

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

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

Front-loaded with the purpose, but the 'Use when' line repeats the first sentence almost verbatim, and the full text is duplicated in Japanese, roughly doubling length. The gBizINFO disclaimer is worded defensively and could be compressed.

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 8 parameters at 0% schema description coverage and no output schema, the description should be doing the parameter work and it does not. Nothing explains the JP/GB country_code enum (odd for a Japan-focused tool), response_language, identifiers, or the relationship between t_number and registration_number.

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 parameter intent is implied clearly by the domain evidence categories (company, qualified-invoice/t_number, address) and by the request/response language and country coverage context, so an agent can map likely inputs without field-level docs. Deducted because the schemas still lack per-field descriptions and no input examples are given, leaving edge semantics (identifiers, registration_number) to inference.

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

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

States a concrete resource and scope: a supplier check combining company, qualified-invoice and address evidence, with a resolution status. It is distinguishable from single-signal siblings at the conceptual level, but it never names the boundary against jp_company_verify, jp_counterparty_check or jp_invoice_issuer_check, so an agent must infer which one to pick.

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 'Use when' clause exists but largely restates the opening sentence (a combined evidence check), giving only an implied context rather than a decision rule. There are no exclusions, no prerequisites, and no pointer to the sibling tools an agent should consider instead for a single-signal lookup.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context by stating the tool is free and describing what the response contains, but it says nothing about rate limits, auth requirements, or catalog freshness.

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 lead word 'Free.' is front-loaded and the two modes are described in one compact sentence. The full bilingual restatement doubles the length, which is defensible for the audience but is still redundant text.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does so for both modes. For a zero-required-parameter discovery tool, nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the single optional question parameter is already documented with an example. The description still adds meaning by explaining the effect of supplying a question (a single recommended tool plus suggested input) versus omitting it (the full catalog).

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 resource (the JPVerify tool catalog) and states exactly what it returns: prices, use_when guidance, example inputs, and how x402 payment works. It also covers the second mode, where a natural-language question yields the single recommended tool plus suggested input, which clearly separates it from the sibling verification/extraction 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?

It gives clear context for both modes: call with no question to browse the catalog, or pass a question to get one recommended tool. It does not explicitly say when to skip this tool and call a sibling directly, so the routing guidance is implied rather than stated.

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