extract

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

Despite annotations carrying readOnlyHint/openWorldHint/idempotentHint/destructiveHint, the description adds substantial non-obvious behavior: a flat $0.05 charge per document, hallucination-guarded OCR (an accuracy guarantee), input validation occurring before any payment, and the x402/USDC payment scheme details. This goes well beyond what the annotations disclose and is genuinely actionable for an agent deciding whether and how to 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?

A single dense sentence front-loads the core value proposition ('One call:') and then delivers each distinct fact — pipeline stages, optional enrichment, pricing, and the validation-before-payment guarantee — without any filler. Every clause earns its place and nothing is redundant with the schema.

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 paid, side-effecting pipeline with full schema coverage, the description covers the essential operational facts: what the call performs, the cost model, and the payment-requirement discovery flow. The main gap is the absence of output/return-value documentation (no output schema exists), though the 'field extraction + arithmetic verification' phrasing lets an agent reasonably infer the result shape.

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 input schema already documents url, enrich, and x_payment thoroughly (including the omit-to-get-requirements behavior). The description reinforces the enrich parameter ('optional issuer enrich') and the input type (PDF/web page) but adds no new parameter-level meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a precise verb+resource ('parse PDF invoice') and enumerates the full pipeline: hallucination-guarded OCR, field extraction, arithmetic verification, and optional issuer enrichment. This distinguishes it from the individual siblings (parse_document, verify_invoice, ocr_image, structured_extract) by signaling it is the consolidated one-call version of those stages.

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 'One call:' framing implies this is the full pipeline, hinting an agent should use individual siblings when only a single stage is needed, and the x_payment semantics describe how to discover payment requirements without charge. However, no sibling or alternative is named explicitly and there are no when-not conditions, leaving routing to inference.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description discloses genuinely useful behavioral traits: $0.03/company pricing, 'unresolved lookups never charged', 'honest nulls' failure behavior, and per-field evidence + confidence output. No contradiction with annotations; in fact, the 'never charged' guarantee and paid nature align with readOnlyHint=false.

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

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

The core transformation is front-loaded in the first sentence, and pricing is compactly stated. It loses a point for redundancy: 'GLEIF LEI / Japan NTA' and 'per-field evidence' each appear twice, so the description could be tightened without loss of 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?

With no output schema, the description compensates well by conveying output shape (verified profile with per-field evidence, confidence, honest nulls), billing behavior, and source registries. The payment flow is mostly delegated to the x_payment schema description. It is slightly incomplete on explicit differentiation from jp_company_profile and on output structure details, but for a complex paid enrichment tool it covers the essentials.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minor value by saying 'pass country_hint jp for Japanese companies,' slightly extending the schema's 'ISO country hint for registry lookups,' but this is marginal and largely redundant with the schema's own 'e.g. jp' example.

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 transformation: company name/domain/URL to a verified profile, citing concrete registries (GLEIF LEI, Japan NTA). The 'Choose this when...' clause and registry-grounded framing effectively set it apart from siblings like jp_company_profile and verify_invoice without needing to open 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?

'Choose this when you have a company NAME or DOMAIN and need a registry-grounded profile...' is explicit when-to-use guidance, and it gives a concrete parameter hint ('pass country_hint jp for Japanese companies'). It stops short of a full 5 because it names no explicit when-not-to-use cases or alternative 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?

The description adds meaningful behavior beyond annotations: auto JS rendering, robots.txt respect, and pricing including cached-result discounts. It also explains the rendered-versus-fast trade-off, which helps set expectations. No contradiction with the annotations.

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

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

The description is two concise sentences with no filler. The core action is front-loaded, followed by high-value behavioral and pricing details.

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

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

The description covers the output format, rendering behavior, robots handling, and pricing. It relies on the schema for payment details and mode semantics, which is reasonable given the schema's thoroughness. Minor gaps include lack of explicit response structure or error behavior, but these are not critical.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds the output format context (Markdown + metadata) but does not explain parameter-specific semantics beyond what the schema 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?

The description states a specific action and resource: extracting a web page into clean Markdown plus metadata. This clearly differentiates it from sibling tools like pdf_info or ocr_image, which target different input types and outputs.

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

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

Usage is implied: use this when you need a URL's content as Markdown. However, there is no explicit guidance on when to choose this over siblings such as structured_extract or parse_document, and no stated exclusions or special cases.

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 destructiveHint=false, covering the safety profile; the description adds the response contents but no behavioral traits such as response format, errors, or cost implications. It does not contradict the annotations, but it contributes little beyond what annotations and the content list already imply.

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 states the resource and its contents, followed by a one-word cost qualifier. There is no filler or repetition; every phrase contributes.

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

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

For a zero-parameter, read-only, non-destructive catalog fetch with rich annotations, the description captures the main contents an agent needs to know. It could be more explicit about the response shape or the meaning of 'payment config', but these are minor for a tool this simple.

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 tool has zero parameters and schema description coverage is 100%, so parameter semantics are effectively complete by default. The description's content list (products, prices, payment config, error codes, rate limits) reinforces what the returned data will contain rather than documenting individual parameters.

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 resource ('Mart402 product catalog') and enumerates its contents (products, prices, payment config, error codes, rate limits), making the tool's purpose evident. It lacks an explicit verb and does not contrast with siblings such as get_sample or search_x402_services, so it stops short of full differentiation.

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 get_catalog over alternatives or when not to use it. 'Free.' hints at access cost but does not form a real usage condition, and the sibling list includes nearby catalog/search tools without any routing information.

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 readOnlyHint, idempotentHint, and destructiveHint as false. The description adds that the operation is free and that receipt IDs come from previous paid responses, which provides useful context about the data source and cost side effects beyond the structured annotations. No contradiction with annotations.

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

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

The entire description is one concise sentence that immediately states the core action and the key constraint (free, by receipt id), with no redundant phrasing. It is perfectly front-loaded and 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 simple retrieval tool with a single parameter and no output schema, the description is sufficient. It explains when the tool is relevant and where the receipt_id comes from. The return value is implied to be the previously paid result, which is clear from the context. Minor gap: it doesn't explicitly state what the response looks like, but this is not essential given the tool's simplicity.

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 receipt_id, including its format (rcpt_...). The description only repeats that the receipt id is used, adding no new semantic information beyond what the schema already declares. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the action (re-fetch), the resource (a previously paid result), and the mechanism (by receipt id). It explicitly notes the result is free and that every paid response carries a receipt_id, which distinguishes this tool from payment- or generation-focused siblings. The purpose is unambiguous and specific.

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 tool when you have a receipt_id from a previously paid response and want to retrieve the result without paying again. It implies the alternative is to re-run the original paid operation, though it doesn't explicitly name a sibling tool. It does not provide exclusions, but the guidance is sufficient for a focused retrieval 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 declare readOnlyHint=true and idempotentHint=true, so the description only needs to add context beyond safety. It adds that samples come from real production runs and are marked sample:true, and that they reveal the response shape – useful behavioral context beyond annotations.

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

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

The first sentence is concise and front-loaded with purpose, but the second sentence repeats the entire enum list verbatim, which duplicates the schema and adds length without new information. This reduces conciseness, though the structure itself is 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 low-complexity tool with one required parameter and no output schema, the description adequately explains what the tool does, its purpose, and the available products. It does not describe the exact return structure, but it promises to show 'the exact response shape', which is sufficient given the absence of an output schema.

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

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

Schema description coverage is 100% and the parameter is an enum with a clear description 'Product id (see the enum)'. The description repeats the full list of products, adding no additional meaning beyond what the schema already provides. Baseline 3 is appropriate when the schema fully defines the parameter.

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 a free recorded sample response for a paid product, from real production runs marked sample:true, to preview the exact response shape before paying. This is a specific verb (get sample), resource (paid product responses), and distinguishes it from the many sibling tools that actually process data.

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 states 'before paying anything', which gives clear context for when this tool should be used (pre-purchase preview). It does not name an alternative tool or explicitly say when not to use it, but the purpose is unambiguous enough to guide 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?

The description adds significant behavioral context beyond annotations: it states the cost ($0.01/call), determinism, that it cites primary sources, and that errors/unverified rules are never billed. This is not present in the annotations (which only declare readOnlyHint false, idempotentHint true, etc.). No contradictions with annotations.

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

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

The description is concise and well-structured: it opens with the core purpose, then pricing, then behavioral guarantees. Every sentence adds value without redundancy or fluff.

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

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

Given the tool has 8 parameters and no output schema, the description should clarify the return value or the two modes (payment requirements vs execution). While the parameter description for x_payment explains the payment flow, the tool-level description does not mention what it returns when executed. The core purpose is clear, but an agent might not know if the result is a number or a breakdown, which is a notable gap.

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

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

Schema coverage is 100%, so all parameters are documented. The description adds meaning by explaining that 'previous month salary' is used for the withholding table lookup and that the official rate table is applied, connecting parameters to the calculation logic. However, it does not elaborate on each parameter or the payment flow, so it only slightly adds beyond the schema.

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

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

The description clearly states the tool computes 'Bonus net pay' from 'social insurance and withholding tax' using an 'official rate table' and 'previous month salary'. This is specific and action-oriented, and the reference to 'bonus' distinguishes it from sibling tools like jp_payroll_net which handle regular payroll.

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 for bonus calculations by mentioning 'based on previous month salary', but it does not explicitly state when to use this tool versus alternatives like jp_payroll_net or jp_social_insurance. There is no 'use this when...' or exclusion of other tools, so the guidance is only implied.

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 provide idempotentHint:true, readOnlyHint:false, and destructiveHint:false, but the description adds meaningful independent context: deterministic behavior, citation of primary sources, and a guarantee that errors/unverified rules are never billed. It also adds pricing information not present in annotations. No contradiction 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 two tight sentences. The first front-loads every core capability; the second adds pricing and trust signals. Every sentence earns its place, and 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 5-mode, 10-parameter tool with no output schema, the description gives a strong high-level summary but does not clarify which parameters apply to which mode or what return shape to expect. The schema documents individual parameters, but an agent still has to infer combinations like mode=add with date+days or mode=deadline with kind+base_date. This is a moderate completeness gap.

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 covers all 10 parameters with 100% description coverage, so the description does not need to restate parameter meanings. It adds high-level mode categories like 'deadline' and 'wareki', but no additional syntax or cross-parameter guidance beyond the schema. Baseline 3 is appropriate.

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

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

The description names five concrete capabilities: Japanese holidays, business-day arithmetic, statutory filing deadlines with holiday shift, and wareki conversion. It clearly identifies the resource and domain, though it lacks a single imperative verb like 'calculate' or 'return'. The listed capabilities distinguish it from the many jp_* sibling 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 usage context by listing the main operations, but it never states when not to use the tool or which sibling might be a better alternative. Given the large sibling set of Japanese tax/payroll tools, explicit routing would be valuable. The context is clear, but exclusions are absent.

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 communicate idempotency and non-destructiveness escort, and the description adds pricing ($0.03/site) and the site-based scope. However, it does not mention possible failure modes, rate limits, or what happens when the URL is not a company site. This is adequate but not deeply transparent.

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 just two sentences, with the core behavior and output fields stated first, followed by pricing and the alternative tool. Every clause earns its place, and there is no redundant restating of the title or schema.

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 two-parameter tool with full schema coverage and no output schema, the description provides sufficient context: what it does, which fields it extracts, when to use it, and how to route to an alternative. A sample output or failure behavior would be nice but is not essential given the simplicity.

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 url and x_payment. The description adds context that the url should be a Japanese company's own site, which slightly clarifies the main parameter, but it does not need to expand on the parameters because the schema handles that well.

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's function: converting a Japanese company's own website into a standard profile JSON with specific fields (name, address, representative, capital, contact). It explicitly distinguishes itself from enrich_company, so an agent can identify when to use 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?

The description gives explicit selection criteria: use this when you have the URL of a Japanese company's own site, and use enrich_company for name/domain lookups with country_hint jp. This leaves no ambiguity about when to choose this tool over its alternative.

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

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

Beyond the annotations, the description discloses meaningful behavior: it costs $0.01/call, is deterministic, cites primary sources, and never bills for errors or unverified rules. This adds practical operational context that annotations do not provide, while remaining consistent with the idempotentHint and openWorldHint annotations.

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

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

The description is two sentences with no filler. It front-loads the tool's scope and immediately follows with pricing and reliability guarantees, every clause earning 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 tool with nine parameters, nested objects, multiple modes, and no output schema, the description gives solid high-level orientation but leaves mode-to-parameter mapping and return behavior to the schema. It is adequate but not fully complete for an agent deciding how to construct a correct call across all four modes.

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 itself documents each parameter. The description adds high-level context by naming the four modes and some tax-domain concepts, but it does not explain how parameters combine per mode or add meaning beyond the 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 names the resource ('Consumption tax') and enumerates four specific capabilities: per-rate invoice rounding, qualified-invoice validation, simplified taxation, and 20% special. It does not use an explicit verb like 'calculates' or 'validates', but the capability list makes the tool's purpose clear and distinguishes it from sibling JP tax 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 gives no explicit guidance on when to use this tool versus alternatives such as jp_crypto_tax or jp_retirement_tax, nor does it state when not to use it. Usage is only implied by the topic and mode names, so the agent must infer the appropriate selection context.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, and openWorldHint=true, but the description adds valuable context beyond these: it states that the tool is deterministic, cites primary sources (NTA FAQ), and that errors/unverified rules are never billed. It also discloses the $0.05/call pricing, which is not in annotations. This is meaningful behavioral information.

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 extremely concise at about 40 words, front-loads the core purpose, and packs in billing, determinism, and verification details without redundancy. Every sentence adds value: purpose, methodology, verification, pricing, and error policy—all in a tight, scannable format.

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 calculation tool with 7 parameters and no output schema, the description does not explicitly describe the return format (e.g., a breakdown of tax amounts, rates, or a report). It gives a hint via 'incremental income tax as reference' and points to /catalog for transaction spec, but the output remains underspecified. An agent would not fully know what to expect without additional assumptions.

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% description coverage for all 7 parameters, and the tool description adds no additional parameter-level detail. The description does mention that other_taxable_income_yen returns incremental income tax as reference, but that is already in the schema. With full schema coverage, the description does not need to compensate, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Japan crypto-asset tax') and names the exact computation method (NTA total-average or moving-average). It clearly distinguishes this from sibling tax tools like jp_payroll_net or jp_consumption_tax by focusing on crypto assets. The mention of sell/spend/exchange as disposals further pins down the domain.

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 (for calculating Japanese crypto tax) but offers no explicit when-not-to-use guidance or alternatives. It does not contrast with other jp_* tools, so an agent must infer its scope. While the purpose is clear, the lack of explicit routing leaves some ambiguity.

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 non-read-only, open-world, idempotent, and non-destructive hints. The description adds valuable behavioral context: 'deterministic, cites primary sources' and the billing policy of never charging for errors. This goes beyond the annotations and helps the agent trust the output quality.

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 extremely concise and front-loaded with the core purpose ('Income-wall analysis'), followed by cost and behavioral notes. Every clause adds value with zero filler. Ideal structure for an AI 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?

The tool has no output schema, so the description should at least hint at what the agent can expect in return. It does not mention result format, error behavior, or any limitations beyond billing. While the purpose is clear, the lack of return-value context leaves a gap for a computation tool with such niche functionality.

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 four parameters are already well-documented. The description mentions the types of income walls, which indirectly relates to annual_income_yen, but it does not add syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool performs 'income-wall analysis' covering tax, social insurance (1.06M/1.30M), spousal and student-dependent walls. This is specific and distinguishes its scope from generic tax tools, though it does not explicitly name sibling alternatives.

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 context 'income-wall analysis' implies when to use it, but there are no explicit exclusions, alternatives, or conditions for selecting this tool over siblings like jp_social_insurance or jp_payroll_net. The description gives no direct comparison.

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

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

The description adds valuable behavioral context beyond the minimal annotations (idempotentHint, readOnlyHint false). It discloses determinism, citation of primary sources, and a billing guarantee (errors/unverified rules never billed). This enriches the agent's understanding of reliability and cost behavior, though it does not mention any side effects or prerequisites beyond 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?

The description is three sentences with zero filler: first sentence states the core function, second gives cost, third covers reliability. Key information is front-loaded, and every sentence earns its place. Exemplary conciseness.

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?

No output schema exists, so the description should explain what is returned. It lists outputs (schedules, total interest, prepayment effect) but does not describe format, units, or edge cases. Given moderate complexity (6 params, nested object), it could benefit from more detail on output structure or assumptions, though it is adequate for a straightforward calculation 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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description mentions level payment/principal and prepayment effect, which map to the method enum and prepayment object, but it does not add new meaning beyond the schema; it simply restates concepts already documented there.

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 mortgage schedules with two methods (level payment/principal), total interest, and prepayment effect. It distinguishes from sibling tools like jp_tax and jp_bonus_net by narrowing to mortgage-specific calculations. The verb is implied but obvious from context.

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?

There is no explicit guidance on when to use this vs alternatives. The purpose implies it should be used for mortgage schedule calculations, but no alternative is named and no exclusions are provided. The mention of cost/determinism might help an agent decide based on those factors, but not directly about tool 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?

Beyond annotations, the description discloses determinism, a $0.015/call charge, legal-source citation, and a billing guarantee ('errors and unverified rules are never billed') — genuinely useful behavioral context. It does not contradict annotations: idempotentHint=true aligns with 'Deterministic,' and readOnlyHint=false is consistent with the paid computation. Minor gap: it never states what non-read side effect (the charge) entails.

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: purpose and legal grounding first, then pricing and trust guarantees. Every clause earns its place, and the front-loading lets an agent grasp scope immediately.

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 dual-mode design is clear from the description plus the mode enum, but there is no output schema and the description never hints at the return format — a meaningful gap for a paid tool where an agent should know what it gets for $0.015. For a moderately complex 6-param tool with nested objects, this leaves the output contract unspecified.

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

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

Schema coverage is 100%, so the schema already documents all six parameters. The description adds legal framing (Art.37, rounding notice, Article-36) that helps interpret mode and the overtime-related params, but it does not map legal concepts to specific fields. Baseline 3 is correct since the schema carries the burden.

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-resource pair: 'Overtime premium pay' plus a distinct 'Article-36 limit check,' both anchored to the Labor Standards Act Art.37 and the official rounding notice. This clearly distinguishes it from JP siblings (jp_payroll_net, jp_bonus_net, jp_payslip_audit) and tells an agent it handles overtime-specific Japanese wage computation.

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 two functions (pay and Article-36 limit check) and the legal scoping give an implied usage context, but no explicit when-to-use vs alternatives guidance and no exclusions. An agent must infer that this is the overtime-specific tool among the payroll siblings rather than being told directly.

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 idempotency and destructive-safety; the description adds valuable behavioral detail: determinism, citation of primary sources, exact NTA table, and a 'never billed for errors' policy. It does not contradict annotations, and the added payment/billing context goes beyond 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?

The description is compact and front-loaded with the core function, followed by the exact-table claim and pricing/accuracy guarantee. Every sentence adds distinct information with no filler.

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

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

The tool has 8 parameters and no output schema, yet the description plus full schema coverage makes its purpose, scope, and result type clear. The lack of an explicit return-format description is a minor gap, but the description's determinism, pricing, and source-citation details make it sufficiently complete 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?

Input schema covers 100% of parameters, so the baseline is 3 and the description need not restate them. It adds broad meaning (gross salary and the tax components) but supplies no param-level detail beyond the schema.

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

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

The description states a clear transformation ('annual gross salary to net take-home') and names the exact components (social insurance + income tax + resident tax), which distinguishes it from siblings like jp_bonus_net and jp_payroll_suite. The 'Exact NTA Beppyo-5 table' further anchors its specific scope.

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

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

The description implies use for annual salary-to-net calculations but gives no explicit when-to-use guidance or exclusions. It never names alternatives such as jp_bonus_net for bonus-only calculations or jp_payroll_suite for broader payroll needs.

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 idempotency, read-only status, and destructiveness, so the description doesn't need to restate those. It does add useful context by disclosing the flat $0.05 cost, which is behaviorally relevant. However, it doesn't describe what the call actually returns or whether any records are created, so it adds only modest context beyond the annotations.

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

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

The description is a single compact sentence that front-loads the core outputs and ends with the pricing detail. Every clause adds information, and there is no redundant filler. It is an excellent example of concise, scannable content.

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?

This is a complex 7-parameter tool with nested objects, no output schema, and many payroll-related siblings, yet the description only gives a high-level component list. It doesn't explain the output shape, clarify vague terms like 'income walls,' or discuss the payment flow despite the x_payment field being central to the call. The schema fills input semantics, but the description leaves too much for the agent to infer.

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?

All 7 parameters have descriptions in the input schema, so the schema carries the semantic load. The tool description itself provides no additional parameter-level detail, such as how 'income walls' relate to annual_gross_yen or how dependents affects the calculation. A baseline 3 is appropriate since the schema already explains the parameters.

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's scope: it computes net salary, social insurance, income walls, and optional bonus together in one call. It is not a bare tautology, and the listed components distinguish it from sibling tools like jp_payroll_net or jp_social_insurance. However, it doesn't explicitly differentiate itself from those siblings or name alternatives, so it falls short of a 5.

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

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

The phrase 'in one call' implies the tool is meant for bundled payroll calculations, which provides some usage context. But it never states when to prefer this suite over individual tools like jp_payroll_net, jp_social_insurance, or jp_bonus_net, nor does it give exclusions or prerequisites. The guidance is implied rather than explicit.

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

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

Annotations already provide readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: deterministic behavior (matching idempotency), citation of primary sources (supporting open-world), and a billing guarantee that errors/unverified rules are never billed. This goes beyond what annotations convey and clarifies cost and correctness expectations.

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

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

The description is two concise sentences with zero filler. The purpose is front-loaded, followed by pricing and behavioral notes. Every clause adds value, and it is appropriately sized for the tool's complexity.

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

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

For a tool with 6 parameters (including a nested payslip object) and no output schema, the description provides a clear overview of the audit process and output verdicts (match/explainable/mismatch). It mentions pricing and determinism, but does not detail the full output structure or edge cases. Given the complete parameter schema and the core behavior explained, this is adequate but not exhaustive.

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 every parameter has a description in the schema. The tool description does not add parameter-specific meaning beyond the schema; it mentions 'recompute statutory premiums and withholding tax' which indirectly relates to parameters like prefecture and age, but does not elaborate. Baseline 3 is appropriate given full schema coverage.

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

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

The description states a specific verb ('Audit'), a clear resource ('a Japanese payslip'), and the exact outcome (recompute premiums/tax and diff with per-item verdicts). It also adds pricing and determinism, which helps distinguish it from sibling payroll tools that compute rather than audit.

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: when you have a Japanese payslip to audit. However, it does not explicitly mention when not to use it, nor does it name any alternative sibling tools like jp_payroll_net or jp_social_insurance. The guidance is inferred from the purpose rather than stated directly.

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

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

The description adds valuable non-annotation context: $0.02/call pricing, determinism, citation of primary sources, exact rounding behavior, and a guarantee that errors/unverified rules are never billed. These details go beyond the annotations and help an agent set expectations for cost and reliability. There is no contradiction with the annotation flags.

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 filler. The domain and core rules are front-loaded, followed by cost and reliability facts. Every clause earns its place and supports tool selection and invocation.

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 selection and invocation, the description covers purpose, cost, reliability, and key domain behaviors, while the schema covers parameters and the payment handshake. However, with no output schema, the description does not explicitly state what the result contains beyond hinting at primary-source citations, leaving a moderate gap in the return contract.

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 adds domain context for years_of_service and payout_yen via the deduction/half-taxation framing, but it does not add meaning for x_payment, disability, or is_officer beyond what the schema already says. This is the expected baseline when the schema carries the parameter details.

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 the Japanese retirement income tax calculation and lists concrete behaviors: deduction by years of service, half-taxation rules, and exact withholding rounding. This separates it from bonus, payroll, and social-insurance siblings, though it lacks an explicit verb like 'calculates' and does not name a comparison sibling.

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 case is implied by the title and opening phrase 'Retirement income tax', so an agent can infer when to choose this tool. However, it gives no explicit guidance about when not to use it or which sibling alternative might be more appropriate for related scenarios.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds valuable behavioral context: deterministic results, cites primary sources, errors and unverified rules are never billed, and the $0.01/call pricing. It also discloses the x_payment behavior implicitly through the schema. This goes beyond 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?

Three sentences with zero waste. The core purpose is front-loaded, pricing is stated, and the deterministic/source-citing behavior is compressed into a single clause. 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 tool with 5 parameters, full schema coverage, and no output schema, the description is quite complete. It explains the source, the pricing, the deterministic behavior, and the payment flow. The only gap is that it doesn't describe the return value shape, but with no output schema and a clear domain (premiums), an agent can infer the result. A 4 is fair.

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 all 5 parameters. The description adds context about the grade table lookup and the payment scheme (x_payment) that helps an agent understand the billing behavior. It doesn't add much per-parameter detail beyond the schema, but the baseline is 3 with full coverage, and the description's mention of the grade table and payment requirements adds meaningful context.

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 ('calculates' implied by 'Monthly social insurance premiums'), a precise resource (official Kyokai-Kenpo grade table FY2026), and a distinguishing scope (monthly premiums). It clearly differentiates from siblings like jp_bonus_net, jp_payroll_net, and jp_consumption_tax by naming the exact source table and period.

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 monthly social insurance premiums are needed from the official grade table. It doesn't explicitly name alternatives or exclusions, but the specificity of 'monthly social insurance premiums' and 'official Kyokai-Kenpo grade table' gives clear context. A 4 is appropriate because it lacks explicit when-not-to-use guidance but is otherwise clear.

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

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

Beyond the annotations, the description discloses the $0.05/image cost, the 3-run consensus behavior with spread and item agreement, and measured calibration accuracy (26/30). This gives the agent realistic expectations about price and output uncertainty. There is no contradiction with the annotations because charging and analyzing do not conflict.

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

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

Every sentence carries distinct value: core purpose, output features, calibration evidence, consensus behavior, and cost. It is dense but front-loaded and contains 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?

Given the complex output and payment flow, the description covers outputs, uncertainty, and cost well. However, it does not explicitly state that one of image_url or image_base64 must be supplied, and the lack of an output schema leaves the exact JSON shape partly to inference.

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 each parameter already has a strong description, including the x_payment omission flow. The tool description adds no parameter-level meaning beyond what the schema provides, 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 opens with a specific verb and resource: 'Analyze a meal photo to itemized nutrition JSON'. It also enumerates concrete outputs like dishes, portions, kcal, macros, and confidence, making the tool's role unmistakable and clearly distinct from OCR/receipt/document 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 first clause effectively states the intended use: when a meal photo needs a nutrition breakdown, this is the tool. It does not explicitly name alternatives or exclusions, but the meal-photo/nutrition framing gives clear selection context among the 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?

The description adds behavioral context beyond annotations by disclosing the flat fee ($0.05/image) and the dual-engine/calibration process, which annotations do not cover. However, readOnlyHint: false implies possible side effects, and the description does not clarify what those are beyond charging, nor does it mention any limitations or prerequisites.

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

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

The description is two concise sentences that front-load the core purpose ('OCR one image to text') and then pack additional differentiators and pricing efficiently. There is zero wasted verbiage; every clause adds 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?

Given the tool's moderate complexity (4 parameters, none required, no output schema), the description combined with the schema provides sufficient information for an agent to call it correctly: how to specify the image (url or base64), language, and the payment mechanism. It lacks explicit error or rate-limit info, but that is not critical for a simple call. The pricing and process details fill gaps not covered by annotations.

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

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

Schema coverage is 100% for all 4 parameters, so the baseline is 3. The description adds context about language strength (Japanese-strong) and pricing, but does not add any parameter-specific semantic details beyond what the schema already provides. It does not explain the relationship between image_url and image_base64 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?

The description states a specific action ('OCR one image to text') with a clear resource, and adds unique differentiators (dual-engine consensus, calibrated confidence, per-segment corroboration) that distinguish it from general document tools like document_pipeline or parse_document. The focus on a single image makes the scope 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 explicit guidance is given on when to use this tool over alternatives. The phrase 'Japanese-strong' implies suitability for Japanese text but does not explicitly say 'use this for Japanese images' or mention any exclusions or sibling comparisons. An agent would have to infer usage context.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavior beyond annotations: the 12-week window, the weekly series, trend, volatility, and badge, and the fact that it covers any x402 operator from the Market402 index.

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 behavior is front-loaded, and the use case is stated immediately after. Every part of the description 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 lookup tool, the description is complete: it states what is returned, the coverage window, the source index, and when the agent should call it. The absence of an output schema is mitigated by listing the return components.

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 is already described as an operator domain. The description adds value by clarifying that the operator must be an x402 operator from the Market402 index, which is more specific than 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 identifies the tool as providing a free 12-week measured score history for an x402 operator, naming the specific data series included. It is specific about the resource and scope, and its focus on operator history distinguishes it from the many service-lookup 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 gives clear usage context: 'Check a seller's record before your agent pays an unfamiliar endpoint.' It does not explicitly name alternatives or state when not to use the tool, but the trigger condition is concrete enough 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?

Beyond annotations, the description adds valuable behavioral context: 'hallucination-guarded OCR for scanned pages, Japanese-strong' and the fact that the price is fixed. It does not contradict annotations (readOnlyHint=false, idempotentHint=true) and aligns with the paid nature implied by the x_payment parameter.

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 waste. The primary purpose is front-loaded, followed by a necessary prerequisite and a cost note. 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 tool with 2 parameters, no output schema, and clear annotations, the description covers the essential aspects: what it does, the prerequisite, and the OCR specifics. It does not describe return structure in detail, but 'structured Markdown' gives a sufficient idea. It lacks explicit alternative routing, but that is not critical given the context.

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 description does not add new meaning beyond the schema. It repeats the quote_id origin and price fixed, but does not elaborate on x_payment behavior beyond what the schema already states. 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 clearly states the action ('Parse a quoted PDF to structured Markdown') with a specific resource and output format. It also distinguishes the tool by mentioning OCR capabilities and language support, which differentiates it from siblings like pdf_info or structured_extract.

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 a clear prerequisite ('Get quote_id from quote_parse first') and a key behavioral condition ('price is fixed by the quote'). It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to know when to use 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 cover idempotency (idempotentHint=true) and non-destructiveness (destructiveHint=false), so safety is disclosed. The description adds the $0.001 cost and the 'before you pay' positioning, which is valuable beyond annotations. 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?

A single, front-loaded sentence that states the purpose, deliverables, and cost with zero filler. 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 simple tool with no output schema, the description lists the return facts and pricing. Combined with annotations and full schema coverage, an agent has enough to call it correctly. It could mention error cases or the payment flow, but those are minor gaps.

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

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

Schema description coverage is 100%, so both parameters (url and x_payment) are already fully documented. The description adds no parameter-specific meaning, 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 clearly states the tool provides PDF facts (pages, metadata, per-page text volume, scanned-or-not estimate) and positions it as a cheap pre-parsing step. It distinguishes itself from full parsing but doesn't explicitly name sibling tools like pdf_pages, so it's 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 phrase 'before you pay for parsing' implies this is a preliminary check, but no explicit alternatives or when-not-to-use guidance is given. The agent must infer when to use this vs. pdf_pages or parse_document. Usage context is present but not explicit.

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

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

Beyond the annotations, the description adds meaningful behavioral context: 'Deterministic' guarantees reproducible output and aligns with idempotentHint, and '$0.003' discloses cost, which is important for an agent deciding whether to invoke it. It does not describe side effects like fetching URLs, but the simple merge semantics make this a minor gap.

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

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

The description is extremely concise: one front-loaded sentence communicates the core operation, constraints, and ordering, followed by two short high-value facts (determinism and price). There is no filler or repetition of schema details.

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

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

For a low-complexity tool with two parameters and no nested objects, the description covers the operation, constraints, and cost, while the schema handles payment parameter semantics. The only notable absence is the explicit return format (e.g., the merged PDF binary), but this is reasonably implied by 'Merge 2-10 PDFs into one.'

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 of both parameters, including the detailed x_payment behavior. The description reinforces the 'in order' semantics and 2-10 range already present in the schema but adds no new parameter-level 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 is explicit and specific: 'Merge 2-10 PDFs into one, in order' names the verb, the resource, the count constraint, and the ordering guarantee. This clearly distinguishes it from sibling tools like pdf_info and pdf_pages, which inspect or process individual PDFs rather than combining them.

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

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

The description implies its usage context—combining multiple PDFs into a single document—but it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites such as URL accessibility or payment requirements. The usage is inferred from the operation itself rather than explicitly guided.

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

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

The description adds 'Deterministic, $0.002', which is not in annotations, and clarifies that it creates a new PDF (non-destructive). Annotations already include idempotentHint and destructiveHint, so the description adds value by specifying determinism and cost, though it doesn't detail error handling or authentication requirements beyond the schema.

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

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

The description is a single concise sentence that front-loads the action and output, followed by a brief note on determinism and cost. There is zero redundancy, and every phrase serves a 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 relatively simple tool with no output schema, the description adequately indicates the output (a new PDF) and mentions cost/determinism. It does not specify the exact return structure (e.g., URL vs. file) or potential edge cases, but given the tool's simplicity and the presence of schema descriptions, it is sufficiently 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% with descriptions for all three parameters. The tool description reiterates '1-based ranges' but adds no new meaning beyond the schema. The description does not elaborate on 'url' or 'x_payment' beyond what schema provides, so it adds minimal value in parameter semantics.

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 ('Extract'), a resource ('pages from a PDF'), and the output ('a new PDF'). It clearly differentiates from siblings like pdf_merge (merging) and pdf_info (information extraction) by focusing on page-range extraction.

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 (extract specific pages) but does not explicitly contrast with alternatives or state when not to use it. It lacks explicit routing guidance such as 'use pdf_merge for combining PDFs' or 'use pdf_info for metadata'. The intended use case is clear, but no explicit when/when-not guidance is provided.

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 provide readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: 'No identification; images not stored' discloses privacy/storage behavior, 'Flat $0.05/call' discloses pricing, and 'measured pixel colorimetry' and 'deterministic rule table' explain the analytical approach. No contradiction with annotations. It could mention handling of failed or low-quality images, but the disclosed behaviors are substantial.

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 sentence with multiple clauses, but it is well-structured: purpose first, then method, then output, then privacy and pricing. It front-loads the primary action and packs a lot of information without verbosity. The sentence is dense but readable, and every clause adds value. No filler or redundant phrasing.

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

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

Given the tool's complexity (image analysis, payment handling, multiple parameters) and no output schema, the description covers the essential return value ('4-season verdict with palette and style advice'), input constraints, privacy (no identification, no storage), and pricing. It also hints at the payment flow via the x_payment parameter description. It does not explicitly detail the output format (e.g., JSON structure), but the summary of the verdict is sufficient for an agent to know what to expect. Minor gaps like error handling are acceptable.

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 all five parameters. The tool description adds context about the purpose of images (1-3 portraits, different lighting recommended) which aligns with the images parameter description. However, it does not add new meaning beyond what the schema already provides for individual parameters. The baseline of 3 applies because the schema carries the load and the description does not materially compensate.

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's function: personal color analysis from 1-3 portraits, using specific methods (pixel colorimetry, cross-photo lighting consistency, deterministic rule table) and outputs a 4-season verdict with palette and style advice. It distinguishes itself from siblings like portrait_precheck and style_profile by emphasizing a deterministic rule table and explicitly stating 'No identification'. The verb+resource is specific and unambiguous.

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

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

The description implies when to use it (when you have 1-3 portraits and need color analysis) but does not explicitly mention alternatives or exclusions. It does not name sibling tools like portrait_precheck or style_profile as alternatives, nor does it state when NOT to use this tool (e.g., if you need facial recognition or a broader style profile). The input constraint '1-3 portraits' is clear, but the choice logic among siblings is left to inference.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds deterministic and no LLM, indicating consistent, non-AI results, plus a rate limit and free cost. This enriches the behavioral profile beyond the annotations without contradiction.

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

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

A single, front-loaded sentence conveys purpose, differentiation, and key constraints, followed by a rate limit. Every word earns its place; no filler or redundancy.

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

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

For a simple two-parameter tool with no output schema, the description adequately conveys what the tool checks and its deterministic nature. It does not specify the exact output format, but the agent can reasonably infer a boolean or status result. Rate limit is also mentioned. Slightly missing output details, but not critical for a precheck.

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 clear descriptions for image_url and image_base64. The tool description does not add any parameter-level meaning beyond what the schema already states, 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?

States a specific verb and resource: a free precheck that determines face detectability and photo quality (clipping/color cast) before paid portrait_analysis. Explicitly distinguishes itself from the sibling portrait_analysis by framing itself as a prerequisite.

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?

Tells the agent exactly when to use it: before paying for portrait_analysis, to avoid wasting money on an unanalyzable image. Also gives a concrete rate limit (10/hour/IP), which is a usage constraint. No ambiguity about its role.

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 (readOnly, idempotent, non-destructive), so the description's job is to add economics and workflow context; it does that by stating the call is free and is a pre-payment gate. It omits quote validity/expiry, rate limits, and authentication requirements, which would matter for a paid pipeline.

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: first the value proposition and payload contents, then the handoff instruction. No filler and the key information is front-loaded.

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 must name the return values, and it does (page count, route, final price, quote_id). For a simple one-parameter tool this is nearly complete; only quote lifetime and error/unsupported-input behavior are missing.

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

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

Only one parameter and schema description coverage is 100% ('PDF URL'), so the schema carries the parameter burden and the baseline is 3. The description adds no format constraints (size limits, public URL requirement, redirect handling) 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+resource ('free quote for PDF parsing') and enumerates exactly what the quote contains (page count, text/scan-OCR route, final price), which is far more than a restatement of the name. It implicitly separates itself from parse_document by positioning itself as the pre-payment step, though it does not explicitly distinguish itself from the similar-looking pdf_info or pdf_pages 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?

Gives a clear condition of use ('before any payment') and an explicit follow-up path: pass the returned quote_id into parse_document, including the endpoint hint. It does not spell out when this is unnecessary (e.g., if the caller already has a quote) or list non-PDF cases.

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

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

The description discloses key behaviors beyond the annotations: payment is charged, codes are single-use and non-expiring, supported languages (en/ja), and the warning 'Treat codes like cash'. These are not in the annotations and add useful context. It does not contradict the provided annotation hints (readOnlyHint=false, idempotentHint=true).

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 pack a lot of information (price, quantity, unit cost, language, expiry, cash-like warning) without unnecessary words. The core purpose is front-loaded ('Volume pricing for style_report') and the warning is a natural close. It is slightly dense but each clause earns its place.

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

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

With no output schema, the description appropriately states what the tool returns (10 single-use credit codes). It covers pricing, language, expiry, and the code-handling warning. The payment-flow details (e.g., omitting x_payment to get requirements) are already in the schema, so the description is sufficiently complete for an agent to call correctly.

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

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

Schema description coverage is 100%, and the x_payment parameter is already well-documented in the schema (base64 header, omission behavior). The description does not add parameter-level meaning beyond mentioning a '$19.90 payment' which aligns with the schema's payment concept. Since schema carries the full parameter semantics, 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 clearly identifies the resource (style_report) and the action (payment returns 10 single-use credit codes). It distinguishes report_pack from style_report itself by framing it as 'Volume pricing'. However, the verb is implicit ('returns' rather than an explicit 'purchase' or 'buy'), so it's slightly less direct than a fully specified action.

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 pricing comparison '$1.99/unit vs $2.99 single' implies usage when multiple style_report calls are needed, and the reference to style_report indicates a relationship to that sibling. But there is no explicit 'use this when' or 'use style_report for single calls' guidance, and no mention of when not to use it. The guidance is implied but not stated.

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 establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond annotations by stating that results are live-probed resources with a measured 402 Score and that the tool is free, which provides operational expectations without contradicting the annotation profile.

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

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

The description is three short sentences with the primary purpose front-loaded. 'Free.' is a concise, relevant cost signal, and every sentence adds distinct information without filler or redundancy.

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

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

For a two-parameter read-only search tool, the description covers the search target, result characteristics, and cost well. It does not detail the exact return structure or pagination behavior, but the 'measured 402 Score' hint gives agents a reasonable expectation of result contents. Given the absence of an output schema, slightly more explicit return formatting would be useful but is not critical.

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 3. The description reinforces the `q` parameter with the same capability examples already present in the schema, but adds no new meaning about `limit`, parameter formatting, or result constraints. It therefore does not exceed the baseline.

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

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

The description clearly identifies a specific verb ('Search') and resource ('Market402 verified index of the whole x402 economy'), and scopes the query by 'capability' with examples. It also conveys the result nature ('real, probed resource with a measured 402 Score'), which helps distinguish it from catalog-style siblings, though it does not name any sibling 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 description gives clear context for when to use this tool: searching for services by capability keyword like 'ocr' or 'market-data'. However, it does not mention alternatives or conditions where a sibling such as get_catalog or get_sample would be more appropriate, leaving the 'vs alternatives' aspect unaddressed.

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

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

Beyond the annotations, the description discloses the hybrid execution model (LLM + deterministic canonicalization) and a concrete cost of $0.03/call. Since readOnlyHint=false and idempotentHint=true, adding cost and processing-mode context helps set expectations. It does not describe failure modes or rate limits, but the extra behavioral context is meaningful.

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 full value: the primary action, the execution model, the price, and the routing guidance. It is compact, front-loaded, and every sentence earns its place.

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

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

For a 3-parameter tool with no output schema, the description plus input schema cover what an agent needs to select and invoke it: input URL, user schema, payment semantics, and alternatives. Minor omissions like output format details are acceptable because the tool's purpose implies returning the filled JSON.

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 url and schema well. The description adds context that the schema is user-provided, but it does not need to compensate for missing parameter documentation. This meets the baseline for high coverage.

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

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

The description states a specific verb-resource pair: fill YOUR JSON schema from any URL. It also distinguishes itself from company-profile tools by explicitly naming enrich_company and jp_company_profile as alternatives, making the tool's unique role unambiguous.

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

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

It gives explicit guidance: choose this when you have your own JSON schema to fill from any page, and use enrich_company or jp_company_profile for company profiles. This directly tells an agent when to select this tool over 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 signal idempotent, non-destructive behavior, and the description adds a concrete billing detail ('Flat $0.05/call') and input constraints not present in the annotations. It does not disclose error/edge-case behavior or what happens without a valid x_payment, but it does not contradict the annotations.

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

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

Three compact sentences front-load the verdict type, then give input constraints and pricing with no filler. Every element—output scope, input requirements, cost—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?

Without an output schema, the description does a reasonable job of naming return components (seasonal color, face-impression zone, body frame, integration rules) and the required inputs. It leaves payment-flow and error behavior to the schema/x_payment parameter, so it is not fully complete but is adequate for a complex paid 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?

The input schema covers all 7 parameters at 100%, so this dimension starts at baseline 3. The description adds useful meaning by translating parameters into product requirements (1-3 face photos; full-body and questionnaire optional) and clarifying that image_url/image_base64/body_image_url are ways to satisfy those requirements.

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 deliverable ('integrated styling verdict') and lists its components (seasonal color, face-impression zone, body frame, integration rules), so an agent can recognize this as a multi-signal style-analysis tool. It does not explicitly distinguish it from sibling tools like style_report or portrait_analysis, but the composite scope is clear.

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

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

The description provides explicit input requirements for when the tool is applicable: 1-3 face photos, optional full-body photo, and optional questionnaire. It does not state when to prefer style_profile over related siblings, but the context is clear enough to establish appropriate use.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false), the description discloses pricing, payment behavior (omitting x_payment returns requirements without charging), and the output format. It adds context about the report including 'honest confidence' and candidate conflicts. No contradiction with annotations; the English-language claim contradicts the schema's language enum but that is a schema conflict, not an annotation conflict.

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

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

The description is front-loaded with the main purpose and return format, then quickly covers target audience and pricing. It is efficient with three sentences, each serving a purpose. While a bit dense, it does not waste words and is easy to scan.

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 description lacks essential usage context: it does not state that images are required for a meaningful report (schema has no required fields), nor does it clarify behavior when no images are provided. It also omits error conditions or what happens with invalid input. The language discrepancy (English-only claim vs ja support) further adds confusion. Given 8 parameters and no output schema, more guidance is needed for an agent to call this correctly.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented in the schema. The description adds minimal extra meaning, only mentioning 'pass pack_code' which is already in the schema. It does not clarify relationships between parameters (e.g., image_url vs image_base64 alternatives, or mutual exclusivity of payment methods) 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 generates a client-ready PDF report with style analysis, including palette, outfit formulas, and draping boards, and returns report_pdf_base64 and full profile JSON. It is specific about the deliverable, though it doesn't explicitly name a sibling alternative like style_profile. A minor inconsistency: the description says 'English PDF report' while the schema allows language='ja', which could mislead an agent about supported languages.

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 context ('For agents serving human end-clients') which implies it is for final client-facing output, but it does not explicitly state when not to use it or name alternative tools. It also covers payment options (pack_code vs flat fee) but does not clarify prerequisites or edge cases like when to use style_profile for the underlying analysis.

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 indicate idempotent and non-destructive behavior, but the description adds meaningful details: it checks line-item totals, queries the official Japan NTA registry, and produces accounting-ready JSON. The explicit $0.015/call cost also sets accurate expectations about metering beyond what annotations convey.

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, opens with the core action, and packs the key verification checks, output type, and cost without wasted words. Every clause earns its place.

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

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

There is no output schema, so 'accounting-ready JSON' is somewhat vague about the exact return shape. Still, the explicit sub-checks, the schema coverage, and the cost/payment note give an agent enough information to understand the call's behavior and expected result.

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

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

Schema description coverage is 100%, so the schema already documents fields, x_payment, and line_items. The description's references to arithmetic consistency and line-item totals map loosely to those parameters but add no parameter-level syntax or format details 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 uses the specific verb 'Verify' and names the exact resource: extracted invoice fields. It lists concrete verification dimensions (arithmetic consistency, line-item totals, JP registration number check-digit, corporate-number existence via the NTA registry) and the accounting-ready JSON output, clearly distinguishing it from sibling extraction/parsing 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 this tool is used after invoice extraction, when extracted fields need validation. However, it never names an alternative or states when not to use it, so an agent must infer the routing among the many sibling parse/extract/JP-tax tools.

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