extract

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

With no annotations, the description properly discloses key behaviors: hallucination-guarded OCR, arithmetic verification, flat $0.05/document fee, and input validation before payment. It omits return format, error handling, and the exact payment flow, which are important for a paid tool.

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 that lead with the core value proposition, enumerate features, and include pricing and validation—all without redundancy. It is concise and well-structured.

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 and no annotations are provided, yet the description fails to mention return values, failure mode, or payment request/response behavior. For a complex billing pipeline, this leaves substantial gaps in what the agent needs to know.

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 only 33%, and the description adds meaningful context by explaining the 'enrich' parameter as optional issuer enrichment and implying 'url' refers to the PDF invoice. It does not discuss 'x_payment' beyond the schema's own detailed description, so compensation is partial.

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 a unified PDF invoice pipeline combining OCR, field extraction, arithmetic verification, and optional issuer enrichment. This distinguishes it from sibling tools like ocr_image or verify_invoice by emphasizing the all-in-one nature.

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 'One call' implies using this tool instead of invoking multiple sibling tools separately, but it does not explicitly name alternatives or provide when-not-to-use guidance. Usage context is implied rather than directly 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?

With no annotations provided, the description carries the full burden and does well: it discloses that unresolved lookups are never charged, per-field evidence and confidence are returned, and nulls are honest. It also includes pricing. This goes beyond a simple 'look up company' statement and gives useful behavioral context.

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

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

The description is compact with three focused sentences, front-loading the purpose and key benefits. It avoids unnecessary words. The only minor issue is the elliptical first sentence, but it remains efficient and readable.

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 no annotations and no output schema, the description provides a reasonable overview but lacks explicit usage guidance and details on the output structure. It mentions evidence and confidence, but not the exact fields or format. It is adequate but not fully complete for a tool with this complexity.

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 only 33%, but the description adds meaning for the 'company' parameter by specifying it accepts name/domain/URL. However, 'country_hint' is not mentioned at all, and 'x_payment' is adequately described in the schema. The description partially compensates for low coverage but leaves country_hint ambiguous.

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 conveys that the tool takes a company name/domain/URL and returns a verified profile, referencing specific registries (GLEIF LEI, Japan NTA). This distinguishes it from sibling tools like jp_company_profile, though the grammar is slightly awkward without an explicit verb. It effectively communicates the core function.

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 company verification and enrichment via primary sources, but it does not explicitly state when to use this tool versus alternatives like jp_company_profile or extract_url. It provides context (primary sources, registries) but lacks exclusionary guidance or alternative comparisons.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions auto JS rendering, robots.txt compliance, pricing tiers, and caching behavior (half price for cached results). These go beyond a basic summary and provide useful operational context, though it lacks details on error handling or rate limits.

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, well-structured sentence that front-loads the core purpose ('Extract a web page to clean Markdown + metadata') and appends key behavioral and pricing details without unnecessary 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?

Given the absence of an output schema and annotations, the description reasonably covers the essential aspects: what it does, return type (Markdown + metadata), behavioral constraints (robots.txt, JS rendering), and payment information. It does not address error conditions or authentication details, but for a relatively simple extraction tool, the information provided is fairly 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?

The schema only describes x_payment, leaving url and mode without descriptions. The description adds context by explaining the pricing difference between fast and rendered modes, which hints at the mode parameter's semantics, but it does not explicitly define each enum value or the URL format. The low schema coverage is only partially compensated.

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: 'Extract a web page to clean Markdown + metadata' with a specific verb and resource. It also adds distinguishing behavioral context (auto JS rendering, robots.txt respected) that sets it apart from document parsing siblings like parse_document 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 implies use for web page extraction, but provides no explicit guidance on when to use this tool over alternatives such as parse_document, structured_extract, or ocr_image. There are no mentions of exclusions or specific scenarios where this tool is preferred.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists the contents of the catalog and adds the note 'Free', but does not describe the return format, whether authentication is required, pagination behavior, or any error scenarios. This is minimal behavioral transparency.

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 purpose and enumerates what is included. Every word adds value, including the 'Free' note, with no fluff 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 zero-parameter catalog tool with no output schema, the description provides sufficient context about what the agent can expect. It lists all key content areas, though it does not specify the structure or handling of the catalog data. This is nearly complete for 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 tool has zero parameters, so the schema fully defines the input requirements. The description does not need to explain parameters, and the baseline of 4 for zero-parameter tools 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 it is the Mart402 product catalog with all products, prices, payment config, error codes, and rate limits. The verb 'get' plus the resource 'catalog' makes the purpose unambiguous and distinguishes it from sibling tools which are all 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?

No explicit guidance on when to use this tool or alternatives is provided. However, the description implies it should be used when the full product catalog is needed, and none of the sibling tools appear to serve a similar purpose. The context is clear but not explicitly 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?

With no annotations, the description carries the full burden. It adds useful context like 'for free' and ties usage to prior paid responses, but it does not disclose potential error behavior, authentication needs, or whether the operation is read-only. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the action, the payment context, and the parameter semantics.

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

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

For a one-parameter retrieval tool with no annotations or output schema, the description covers purpose, parameter source, and cost. It could mention return format or limitations, but the tool's simplicity makes the description reasonably 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?

The schema only says receipt_id is a required string. The description adds meaning by explaining that every paid response carries this ID, clarifying the parameter's origin and role. It does not specify format or validation, but it goes 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 clearly states the tool re-fetches a previously paid result by receipt ID, using a specific verb and resource. It distinguishes itself from sibling extraction/parsing tools by focusing on retrieving past results rather than processing new input.

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

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

The description implies when to use the tool: when a receipt ID from a previous paid response is available. It provides clear context but does not explicitly name alternatives or state when not to use it, though the sibling list makes alternatives obvious.

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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals that samples come from real production runs and are marked sample:true, and it promises to expose the exact response shape. This covers the key read-like behavior and inherent nature of the sample, though it does not explicitly state error handling or non-mutating characteristics.

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, with two sentences that pack high information density. The first sentence front-loads the purpose and value proposition, and the second efficiently lists available product identifiers. There is no redundant or filler 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?

For a simple tool with one parameter and no output schema, the description provides complete context: what the tool does, why it is useful, and which product values are accepted. The promise of seeing the exact response shape addresses the lack of an output schema, making the description sufficient for an agent to know what to expect.

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

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

The input schema only defines 'product' as a string with no description, leaving it completely ambiguous. The description compensates by enumerating valid values: ocr, enrich, verify, structured, jp-company, document-pipeline, pdf-info, meal-vision, portrait-analysis. This is essential for correct invocation and significantly adds meaning beyond the schema.

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

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

The description clearly defines the tool as a free recorded sample response retriever for paid products, using the specific verb 'get' and resource 'sample response'. It also differentiates from sibling tools by listing the specific product categories it covers and framing itself as a preview mechanism rather than the actual product execution.

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

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

The description implies the tool should be used to preview a paid product's response before paying, providing clear context for when to invoke it. It does not explicitly state alternatives or exclusions, but the phrase 'before paying anything' effectively communicates its intended use case relative to the actual paid product 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?

With no annotations, the description carries the full burden. It discloses important behavioral traits: determinism ('Deterministic'), sourcing ('cites primary sources'), and a billing policy ('errors and unverified rules are never billed'). It also states the cost ($0.01/call). This goes beyond what schema provides and is valuable for agent decision-making.

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, front-loaded with the core purpose, followed by cost and reliability guarantees. Every sentence adds unique value with no redundancy or filler.

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

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

For a tool with 8 parameters and no output schema, the description gives some context (rate table, previous month dependency, billing rules) but does not elaborate on how parameters interact or what the output format is. It is enough to understand the general purpose, but incomplete for a complex Japanese tax calculation without explicit documentation of edge cases or return values.

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 only 13%, so the description must compensate. It adds meaning by connecting the calculation to 'social insurance and withholding tax (official rate table, based on previous month salary),' hinting at the role of parameters like previous_month_after_si_yen. However, it does not explain individual parameters like age, dependents, or prefecture, leaving gaps that schema also does not fill for 87% of 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 function: 'Bonus net pay: social insurance and withholding tax (official rate table, based on previous month salary).' It identifies the specific resource (bonus net pay) and the key inputs (rate table, previous month salary), distinguishing it from sibling tools like jp_payroll_net which likely handles regular salary.

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-related net pay calculations, but does not explicitly state when to use this tool over alternatives or when not to use it. It mentions a dependency on 'previous month salary,' which provides some context, but lacks explicit exclusions or alternative tool comparisons.

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?

With no annotations, the description must carry transparency. It discloses determinism, citation of primary sources, and a billing policy ('errors and unverified rules are never billed'). This adds useful behavioral context, but it omits potential side effects like billing implications, required authentication, or how the tool handles edge cases. The 'cites primary sources' could imply quality assurance, but it's not a direct behavior.

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

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

The description is a single sentence that packs multiple capabilities and policies. It is efficient and front-loaded with the main functions. However, it crams so much into one sentence that it feels rushed; a structured breakdown of modes would be clearer. Still, it earns a 4 because there is no 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 10 parameters, 1 required, no output schema, and no annotations, the description is far from complete. It does not explain the required 'mode' parameter, expected date formats, what 'kind' refers to, or how 'saturday_off' affects calculations. The tool appears complex (multiple functions), yet the description provides only a high-level teaser without operational details.

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 only 10% (only x_payment has a description). The description names high-level functions (e.g., 'business-day arithmetic', 'wareki conversion') but never maps them to specific parameters like mode, date, days, etc. It does not explain how parameters interact or what values are expected. This is a significant gap for a tool with 10 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 lists the tool's capabilities: Japanese holidays, business-day arithmetic, statutory filing deadlines with holiday shift, and wareki conversion. It conveys a specific multi-purpose role and differentiates from sibling tools like jp_company_profile or jp_consumption_tax by focusing on dates and deadlines. However, it lacks a single verb+resource phrasing and doesn't explicitly state what the primary output is.

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 on when to use this tool versus alternatives. The description lists functions but does not mention prerequisites, typical use cases, or any exclusions. It does not explain which mode to choose for what purpose, nor does it reference sibling tools for 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?

With no annotations provided, the description must disclose behavioral traits. It does mention the cost ($0.03/site), which is a key operational detail. However, it does not disclose deeper behaviors like payment flow, error handling, or rate limits. The schema partially covers payment via the x_payment description, but the description itself adds only the cost.

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 that packs the core purpose, output fields, and cost with no unnecessary words. It is front-loaded and easy to parse, earning a perfect score for 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?

Given the absence of an output schema and annotations, the description should provide a fuller picture. It does list the output fields, which helps, and it mentions cost. However, it does not describe the payment process (covered in schema), failure modes, or any limitations. For a tool with only one required parameter and a straightforward output, this is adequate but not thorough, so a score of 3 is appropriate.

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 50% (only x_payment has a description). The description compensates somewhat by implying that the `url` parameter should be a Japanese company site, adding meaning beyond the bare schema. However, it does not elaborate on URL format or other possible parameters. For x_payment, the schema already provides full semantics, so the description adds no value 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 identifies the resource (Japanese company site) and the output (standard profile JSON with specific fields like name, address, representative, capital, contact). However, the verb is implied rather than explicit (e.g., 'extract' or 'convert'), preventing a perfect score. The cost mention adds context but does not replace a clear 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 description clearly implies when to use the tool: given a Japanese company website URL, you get a structured profile JSON. It does not explicitly exclude alternatives or mention siblings, but the context is unambiguous enough for an agent to select this tool for this specific task. Lack of exclusions prevents a score of 5.

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

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

With no annotations, the description carries the full burden. It conveys determinism, citation of primary sources, and a non-billing policy for errors or unverified rules. It also mentions a per-call cost. This adds valuable behavioral context beyond the schema, though it does not address potential side effects or data mutations (it appears to be a read/calculation tool).

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 brief and front-loads the purpose, but it condenses multiple capabilities into a single run-on sentence. Pricing and determinism are mixed in without clear separation. It is not overly verbose, but structure could be improved with clear sections or bullet-like 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 7 parameters, high complexity (nested objects), no output schema, and low schema coverage, the description is insufficient. It provides a high-level overview but omits critical details like mode values, line input structure, as_of format, and return expectations. An agent would struggle to invoke it correctly without additional documentation.

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 only 14% (only x_payment is described). The description does not explain any of the seven parameters (mode, as_of, lines, etc.) nor map features to inputs. It fails to compensate for the low schema coverage, leaving the agent guessing about parameter meanings.

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 indicates this tool deals with Japanese consumption tax, listing specific features like invoice rounding and qualified-invoice validation. It distinguishes from sibling tools (jp_bonus_net, jp_payroll_net, etc.) by focusing solely on consumption tax. It does not explicitly state 'calculate' or 'compute', but the intent is evident.

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 tool versus alternatives. It does not mention prerequisites, exclusions, or when not to use it. The description simply lists features without contextual usage instructions.

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?

With no annotations, the description fully discloses pricing ($0.05/call), determinism, source citation, and the guarantee that errors and unverified rules are never billed. This goes beyond basic expectations and clearly communicates the tool's trustworthy and safe behavior.

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

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

The description is compact—three sentences—and all information is valuable: purpose, methods, pricing, and reliability. It is front-loaded with the core functionality and avoids 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 7 parameters, no output schema, and low schema coverage, the description lacks essential operational details. It does not explain the output format, how to structure transactions, or the permissible method values. The description is insufficient for an agent to correctly invoke the tool without additional information.

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 only 14%, and the description provides minimal explanation of parameters like year, as_of, method, opening, transactions, and other_taxable_income_yen. It mentions methods and disposal types but does not clarify how to populate the transaction array or the meaning of 'opening'. The description fails to compensate for the low 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 explicitly states the tool computes Japan crypto-asset tax, specifying the NTA total-average or moving-average method and details on disposals and fees. It clearly distinguishes from sibling tax tools by focusing on crypto-assets, with a specific verb and 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 clearly indicates the domain (Japan crypto-asset tax) and provides context on methods and scope, but does not explicitly mention when not to use or alternatives. Since many sibling tools exist, excluding non-crypto tax scenarios could be helpful, but the context is clear enough for a 4.

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

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

With no annotations, the description carries the full transparency burden. It discloses that the tool is deterministic, cites primary sources, never bills for errors/unverified rules, and has a per-call cost of $0.02. This gives agents crucial behavioral context about reliability and pricing. It does not cover rate limits or authentication, but for a paid deterministic analysis tool, the disclosed traits are valuable and exceed baseline 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 three short sentences, front-loaded with the core purpose, then pricing, then behavioral guarantees. Every sentence earns its place with no fluff. The structure is clear and scannable, making it easy for an agent to quickly grasp the tool's value proposition.

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 4 parameters, no output schema, and no annotations, the description should provide more context about expected outputs and parameter semantics. It mentions thresholds but not what results are returned (e.g., threshold values, comparison, advice). Parameter usage is not explained. The description is too sparse for a tool with such low schema coverage, leaving significant gaps for an agent to guess.

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 only 25% (only x_payment has a description). The tool description does not explain parameters like 'year' or 'as_of', which are likely dates. Annual_income_yen is self-explanatory from the name, but the others are ambiguous. Since the schema leaves most parameters undocumented and the description does not compensate, agents will struggle to correctly set inputs.

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 it performs 'income-wall analysis' with specific domains (tax, social insurance, spousal and student-dependent walls). It names the exact thresholds (1.06M/1.30M), distinguishing it from other JP financial tools like jp_social_insurance or jp_tax_calculators. The verb 'analysis' together with the resource (income walls) makes the purpose crisp 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 this tool (for Japanese income threshold analysis) but does not explicitly state when not to use it or mention alternatives. Sibling tools like jp_social_insurance cover related topics, but no comparison or exclusion is provided. The usage is understandable from context but lacks explicit guidance on selection among similar 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 states it is 'Deterministic, cites primary sources; errors and unverified rules are never billed,' which gives some reliability context. However, without annotations, it lacks explicit side-effect info, output structure, or authentication requirements. It does not mention whether the tool is read-only or has other hidden behaviors.

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 short sentences, front-loaded with the core functionality. It includes cost and reliability in a compact manner with no fluff. Every word serves a purpose, making it highly concise and well-structured.

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 tool with 6 parameters, nested objects, a payment mechanism, and no output schema. The description is minimal, lacking parameter explanations, output details, usage prerequisites, and how the x_payment system interacts with the tool. Given the complexity, a much richer description is needed.

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 only 17% (only x_payment has a description). The description mentions 'level payment/principal' and 'prepayment effect' but does not map these to the actual parameters like method or prepayment. It fails to explain principal_yen, annual_rate, months, method, or how the nested objects are used, leaving agents without essential parameter meaning.

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

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

The description clearly states the tool's function: 'Mortgage schedules (level payment/principal), total interest, prepayment effect.' This provides a specific verb and resource scope, indicating exactly what the tool computes. The cost and reliability details are secondary yet reinforce the purpose.

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

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

The description offers no guidance on when to use this tool, prerequisites, or how it relates to other sibling tools. It does not suggest alternatives or explain scenarios where this is appropriate. The only operational detail is the $0.005/call cost, which is not usage guidance.

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

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

No annotations are provided, so the description carries the full burden of disclosure. It adds meaningful behavioral context: deterministic output, cites primary sources, never bills for errors/unverified rules, and has a $0.015/call price. However, it doesn't disclose return format, whether both calculations happen in one call, or payment charge semantics beyond what x_payment implies.

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

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

Three short sentences front-load the core function, then add pricing and trust guarantees. No filler; every clause carries information. The structure is clean and efficient.

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

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

For a complex tool with 6 parameters, nested objects, and no output schema, the description is insufficient. It fails to explain input structure (e.g., how hours are grouped, what modes exist) or outputs (e.g., what a limit check result looks like). The behavioral guarantees are useful, but major operational gaps remain.

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 only 17% (only x_payment is described), and the description does not compensate by explaining the other parameters. It names the domain (overtime, monthly salary, scheduled hours), but provides no meaning for 'mode', 'hours', 'monthly_overtime_hours', or 'monthly_scheduled_hours'. The agent must guess how these fields relate to the calculations.

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

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

Description clearly identifies the domain and function: Japanese overtime premium pay per Labor Standards Act Art.37 plus Article-36 limit check. While it lacks an explicit verb like 'calculate' or 'compute', the legal resource and specific scope distinguish it from sibling payroll tools (e.g., jp_bonus_net, jp_payroll_net). It could be stronger by stating what the tool returns, but the core purpose 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?

No explicit guidance on when to use this tool versus alternatives. It implies use for overtime wage calculations, but doesn't mention exclusions or when to prefer sibling tools like jp_payroll_suite. The 'Article-36 limit check' phrase hints at scope, but the agent is left to infer the appropriate 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?

With no annotations, the description carries the full burden and discloses critical behavior: deterministic results, citation of primary sources, $0.02/call pricing, and a billing guarantee that errors/unverified rules are never charged. This gives the agent confidence in reliability and cost, though it does not cover the free discovery-call flow described in the x_payment 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?

Four short sentences deliver purpose, authority, cost, and reliability with zero redundancy. The first sentence front-loads the core operation, and every subsequent 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 8 parameters, nested dependents, no output schema, and no annotations, the description is too sparse. It omits input semantics for most parameters, return format, and integration details like the payment flow. An agent would need to inspect the schema and probe to use this tool correctly.

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

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

Schema coverage is only 13% (only x_payment has a description), and the description does not compensate. It clarifies annual_gross_yen as the primary input and hints at resident tax for prefecture, but leaves age, year, dependents, and annual_bonus_yen unexplained. The description adds little over the raw schema for most 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 precisely states the tool's function: converting annual gross salary to net take-home, listing the exact deduction components (social insurance, income tax, resident tax). It also distinguishes itself from sibling tools like jp_bonus_net (bonus-focused) and jp_payroll_suite (suite-level), making its specific scope 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 implies its use for annual gross salary net calculations but does not explicitly state when to prefer it over alternatives or provide exclusions such as 'for bonuses use jp_bonus_net'. The scope is clear, but no direct usage guidance is given beyond the core input.

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?

With no annotations, the description carries the full behavioral disclosure burden, but it only discloses the flat $0.05 price. It does not explain that omitting x_payment may produce payment requirements instead of computed payroll results, what the return shape is, or what assumptions/limitations apply.

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 short and front-loaded, mentioning core capabilities and pricing in two sentences. It loses some points because 'Japan payroll suite' mostly echoes the tool name and the terseness causes gaps in clarity and behavioral guidance.

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 computation tool with nested objects and no output schema, but the description gives no output format, calculation basis, input requirements beyond the required schema, or payment flow. The x_payment behavior in the schema hints at an important conditional flow that the description does not clarify.

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 only 14%, and the description barely compensates. annual_gross_yen, prefecture, dependents, age, and previous_month_after_si_yen are not semantically explained; only x_payment has schema-level context. The description's broad terms do not clarify how the parameters interact.

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 what the tool covers: net salary, social insurance, income walls, and bonus in a single call. This distinguishes it from sibling tools like jp_payroll_net, jp_social_insurance, and jp_bonus_net, though it is phrased as a label rather than a clear verb 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?

There is no explicit guidance on when to use this tool versus the more granular sibling tools. 'In one call' weakly implies a combined path, but it never explains when to choose this suite over jp_payroll_net, jp_social_insurance, or the other dedicated 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 discloses critical behavioral aspects: it is deterministic, cites primary sources, errors and unverified rules are never billed, and the cost is $0.02/call. It also explains the payment mechanism via x_payment header and the option to omit it to receive payment requirements without being charged. This is rich transparency beyond any annotations (none provided), covering reliability, billing, and authentication in an unusually thorough manner.

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: the first packs the core functionality and per-item verdicts, the second adds billing and reliability guarantees. Every word earns its place; it is front-loaded with the primary purpose and ends with important caveats without 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?

For a complex tool (auditing, statutory tables, multiple inputs, billing), the description covers essential aspects: what it computes, verdict types, determinism, citation, billing, and payment alternatives. No output schema exists, but the description's clarity about verdicts (match/explainable/mismatch) partially substitutes. The only missing piece is explicit guidance on required vs optional parameters, but the schema already marks prefecture and payslip as required, reducing need.

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 description provides substantial parameter context: it mentions 'statutory premiums and withholding tax' and 'official tables', which relate to prefecture, age, as_of, and standard_monthly_yen. It also explains the x_payment parameter's purpose in detail (payment header, optional, billing behavior). However, it does not explain payslip structure or the exact semantics of each parameter (e.g., age vs. as_of), but with 17% schema coverage, the description compensates better than baseline, scoring slightly above 3.

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 starts with a specific verb ('Audit') and resource ('Japanese payslip'), then details the auditing process: recomputing statutory premiums and withholding tax from official tables, diffing against actual amounts, and providing per-item verdicts. It clearly distinguishes itself from sibling tools like jp_payroll_net and jp_social_insurance by focusing on auditing existing payslips rather than calculating net pay or social insurance amounts.

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

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

The description clearly defines the tool's scope (auditing Japanese payslips) and the context in which it should be used. It implicitly differentiates from sibling tools by focusing on 'recompute and diff' rather than calculation or estimation. However, it does not explicitly state when NOT to use it or mention alternatives, so it loses a point for not providing explicit exclusions.

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

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

With no annotations, the description carries the full burden. It discloses that the tool is deterministic, cites primary sources, and does not charge for errors or unverified rules, which is valuable behavioral context. It also notes the $0.02/call fee. This goes beyond a simple 'calculates tax' statement and provides transparency about reliability and billing.

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, dense sentence that front-loads the core purpose and includes pricing and behavioral notes. Every clause adds value without repetition or fluff. It is concise yet informative.

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 5 parameters (2 required), no output schema, and minimal schema coverage, the description is insufficient. It does not describe the output format, how to interpret results, or the relationship between parameters and tax rules. While it mentions deterministic behavior and sources, it lacks essential operational details for an agent to confidently invoke the tool.

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

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

Schema description coverage is only 20% (only x_payment is described). The description does not explain payout_yen, years_of_service, disability, or is_officer parameters, nor their expected formats or relationships to the tax rules. The mention of 'deduction by years of service' hints at years_of_service but does not provide sufficient detail for correct parameter usage.

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 retirement income tax with specific rules (deduction by years of service, half-taxation, rounding) and distinguishes it from sibling tax tools like jp_bonus_net and jp_payroll_net. The verb 'Retirement income tax' and the detailed scope leave no ambiguity about the tool's purpose.

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 retirement tax calculations and mentions the billing model, but it does not explicitly state when to use this tool versus alternatives like jp_payroll_suite. No when-not-to-use or exclusions are given, so the guidance is inferred 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?

With no annotations, the description carries the burden. It discloses deterministic behavior, citation of primary sources, billing rate ($0.01/call), and that errors/unverified rules are never billed—useful behavioral information beyond schema. It does not contradict annotations.

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

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

Two succinct sentences front-load the core purpose and add critical billing/reliability details. No wasted words, ideal length.

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 5 parameters, no output schema, and no annotations, the description is too sparse. It does not describe the return value (premium amount), nor the meaning of age and as_of, nor how the table is applied. Essential for correct invocation.

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

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

Schema coverage is only 20% (only x_payment has a description). The description mentions monthly remuneration and prefecture indirectly via domain context but does not explain age, as_of, or the required parameters' formats. It fails to compensate for low 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 it provides monthly social insurance premiums from the official Kyokai-Kenpo grade table (FY2026), a specific verb-resource pair that distinguishes it from sibling tools like jp_payroll_net or jp_bonus_net.

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 social insurance premium lookups but does not explicitly state when to use it versus alternatives, nor any exclusions. It provides context (official table, FY2026) but no direct guidance on 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?

With no annotations, the description carries full burden and excels: it discloses a 3-run consensus process, calibration on 30 weighed meals (26/30 contained truth), pricing ($0.05/image), and output details like spread and item agreement. This goes far beyond typical descriptions.

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 dense sentence that front-loads the main function and includes many useful details (calibration, consensus, pricing). It is slightly run-on but each phrase adds value, and it remains concise enough for quick reading.

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, but the description thoroughly explains the return format (itemized nutrition JSON with per-item confidence, kcal range, PFC ratios, etc.), accuracy calibration, and payment workflow. It misses only minor details like required image parameter semantics, but overall it is very complete for a tool of this complexity.

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 only 50%, and the description does not compensate for the undocumented image_url and image_base64 parameters. It does not explain how to supply the photo or clarify the relationship between these two fields. The hints parameter is well-documented in the schema, but that is already covered.

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

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

The description uses a specific verb ('Analyze') and resource ('a meal photo') and details the output as 'itemized nutrition JSON' with fields like dishes, portions, kcal, macros, and per-item confidence. This clearly distinguishes it from sibling tools like ocr_image or portrait_analysis.

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

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

The description clearly implies the tool is for meal photo analysis and provides a usage hint parameter ('cuisine/context hint') that measurably improves accuracy. However, it does not explicitly state exclusions or alternatives, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the burden. It discloses internal processing behavior (dual-engine consensus, confidence, corroboration) and adds pricing transparency ('Flat $0.05/image'). It doesn't cover error handling or auth, but for a simple OCR tool this is sufficient.

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

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

One sentence, front-loaded with the core action, then concise additional details. No wasted words 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?

No output schema exists, so the description should describe returns; it mentions 'to text' and confidence/corroboration, implying structure. However, it omits the dual image input methods and the payment flow (even though x_payment is in the schema), leaving contextual gaps for complete usage.

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 only 25% (only x_payment explained). The description adds little about parameters: 'Japanese-strong' hints at lang, but provides no explanation of image_url vs image_base64, leaving critical input ambiguity. It fails to compensate for the low 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?

Specific verb 'OCR' and resource 'image' clearly state the tool's function. The mention of 'dual-engine consensus, calibrated confidence and per-segment corroboration' adds distinctiveness and differentiates it from sibling tools like parse_document 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?

'Japanese-strong' implies primary use for Japanese text, but no explicit when-to-use vs alternatives. The cost point suggests budget considerations, but there's no clear guidance on choosing this over other OCR or parsing 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?

With no annotations, the description carries the burden and does well by disclosing that the tool is free, covers 12 weeks, and includes trend/volatility/badge data. It doesn't explicitly state read-only behavior or auth requirements, but 'history' strongly implies a non-destructive query, and the cost disclosure is valuable 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 two sentences, front-loaded with the core deliverable, and every word adds value. It avoids fluff and repeats no schema 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?

Despite having no output schema, the description enumerates the returned fields (weekly series, trend, volatility, badge) and gives a concrete use case. For a single-parameter read-only tool, this is fully adequate.

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 a description for the 'operator' parameter, but the tool description adds meaning by specifying 'x402 operator from the Market402 index', which clarifies the expected format and domain context, going beyond the generic 'operator domain' 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 clearly states the tool returns a 12-week measured score history for an x402 operator, naming specific data elements (weekly series, trend, volatility, badge). It also frames the use case ('Check a seller's record before your agent pays an unfamiliar endpoint'), which distinguishes it from sibling tools like search_x402_services or get_catalog.

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 context for when to use the tool: check a seller's record before paying an unfamiliar endpoint. It doesn't name alternatives or exclusions, but the 'before you pay' guidance creates a clear decision rule, making it easy to select among 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?

With no annotations, the description carries the full burden. It discloses paid nature ('price is fixed by the quote'), OCR quality (hallucination-guarded), and language strength (Japanese-strong), but it does not explain the payment flow (e.g., omitting x_payment returns requirements) or error handling, leaving gaps.

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, front-loaded, and every word adds value. It efficiently covers purpose and prerequisite without 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?

No annotations or output schema exist, so the description should explain more about return format and behavior. It mentions 'structured Markdown' but lacks details on content or the payment flow, which is only in the schema. At a minimum, it covers the core purpose and prerequisite.

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

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

The schema has 50% coverage, with quote_id lacking a description. The description adds meaning by stating the quote_id comes from quote_parse, compensating for the gap. x_payment already has a detailed schema description.

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

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

The description clearly states the tool parses a quoted PDF into structured Markdown, specifies OCR for scanned pages, and highlights Japanese-strong support. This distinguishes it from siblings like ocr_image and quote_parse.

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 explicitly notes the prerequisite to 'Get quote_id from quote_parse first,' giving clear context for use. However, it does not explicitly state when not to use this tool or mention alternatives, so it stops short of full exclusions.

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

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

With no annotations, the description carries the transparency burden. It discloses the cost ($0.001) and lists the returned data, which is useful context. However, it does not explicitly state whether the operation is read-only or if any side effects occur, nor does it explain the payment requirement flow (left to the schema). The cost disclosure is a plus, but other behavioral traits remain opaque.

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 purpose, enumerates key output facts, and includes pricing. Every word contributes value; there is no fluff or repetition of schema details. It is appropriately sized for a simple tool.

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

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

The tool has no output schema and no annotations, so the description carries the full load for explaining what the agent gets. It lists the output facts and cost, which covers basics, but omits details about the payment flow (e.g., what happens if x_payment is omitted) and any potential error/edge-case behavior. For a paid tool, this is a noticeable 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 description coverage is only 50% (x_payment is described, url is not). The description adds no parameter information whatsoever. It does not mention the url parameter or clarify the x_payment optional/requirement behavior, leaving a significant gap that the schema and description combined fail to fill for the url 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 provides 'PDF facts' before paying for parsing, enumerating specific outputs (pages, metadata, per-page text volume, scanned-or-not estimate). This distinguishes it from siblings like parse_document or pdf_pages by positioning it as a cheap pre-parser check. Though it lacks an explicit imperative verb, the intent is unambiguous.

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

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

The phrase 'before you pay for parsing' provides clear usage context: use this tool as a low-cost preliminary assessment before committing to a more expensive parsing operation. It implies an alternative (full parsing) without naming it explicitly, and the $0.001 price reinforces the cost-sensitive use case. It does not state explicit exclusions or when not to use it.

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

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

There are no annotations, so the description carries the full burden. It adds valuable behavioral details (deterministic, in-order, $0.003 cost, 2-10 limit) but does not describe the output format or whether source PDFs remain unmodified, leaving some ambiguity.

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 short, front-loaded sentences with no filler. Both sentences earn their place: one communicates the operation and constraints, the other adds determinism and pricing.

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 merge tool without an output schema, the description covers key operation details, constraints, determinism, and cost. However, it does not explicitly state the return value or payment flow beyond the schema, leaving 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 schema describes x_payment well but leaves urls without a description. The tool description compensates by explaining the input is PDFs, limiting to 2-10, and specifying order, adding meaning beyond the raw 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 uses a specific verb and resource: 'Merge 2-10 PDFs into one, in order.' It clearly states the operation and scope, and is distinct from sibling PDF tools like pdf_info, pdf_pages, and ocr_image.

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 action and resource: use this when you need to combine multiple PDFs. It does not explicitly state alternatives or when-not-to-use, but the 2-10 count limit provides useful contextual guidance.

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

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

No annotations are provided, so the description must carry the transparency burden. It adds useful context: the operation is deterministic and costs $0.002, and it outputs a new PDF (implying the original is unchanged). However, it does not disclose other behavioral traits such as input size limits, error handling, or any authentication requirements, which would be expected for a paid tool.

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, information-dense sentence that defines the operation, range syntax, output, determinism, and cost. Every word adds value, with no filler or redundancy, making it highly concise and well-structured.

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 is a simple extraction utility with 3 parameters and no output schema, the description covers the core purpose but omits details about the return value (the new PDF), edge cases (invalid ranges), or any behavior beyond a basic successful extraction. For a paid tool, this is a moderate gap but not severe 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?

The schema only describes the optional x_payment parameter; url and pages have no descriptions (33% coverage). The description clarifies the pages format with the range example, adding meaning beyond the schema. However, it does not explain what url should contain (presumably a PDF URL), leaving a semantic gap for that 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 action ('Extract pages from a PDF') and specifies the range format (1-based ranges like 1-3,7), which distinguishes it from sibling tools like pdf_merge or pdf_info. This gives a specific verb+resource+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 when to use the tool (for extracting pages from a PDF) but does not explicitly mention when not to use it or suggest alternatives like pdf_merge for merging. The use case is clear from the wording, but no exclusions or sibling comparisons are 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It responsibly states 'No identification; images not stored', which addresses privacy and data retention. It also reveals the deterministic rule-table approach and flat fee ($0.05/call), adding valuable context about cost and behavior. It does not mention rate limits or authentication beyond the payment header, but the insights offered go well beyond a bare description.

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: two sentences that front-load the purpose and then provide key behavioral notes. Every sentence earns its place, covering methodology, output, privacy, and pricing 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?

For a tool with no output schema and no annotations, the description covers the essential context: what the tool does, the process, the outcome, privacy posture, and cost. However, it lacks specifics about the response format, error conditions, or explicit alternative tool selection. Given the complexity of the pipeline, it is quite complete, though 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 low (40%) and the description does not compensate. It mentions '1-3 portraits' but does not explain how the style parameter influences analysis, the difference between images/image_url/image_base64, or the x_payment header beyond what the schema already says. The description adds little semantic meaning to the parameters beyond hinting at the image count.

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 'personal color analysis from 1-3 portraits' and specifies the output: '4-season verdict with palette and style advice'. It is specific and distinguishes from sibling tools like meal_vision or document_pipeline by its unique focus and methodology (CIELAB/ITA colorimetry).

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 tool versus alternatives such as portrait_precheck or style_profile. The description implies use for color analysis from portraits, but does not state prerequisites, exclusions, or when to prefer a different tool. The schema suggests different lighting, but that is not in the description.

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?

No annotations, but description discloses deterministic behavior (no LLM), rate limiting, and specific checks (face, clipping/color cast). Could add return value details, but provides strong transparency for a read-only check.

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

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

Three dense sentences covering purpose, checks, and constraints. Front-loaded with key info, no 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?

Describes what the tool checks but omits how to invoke it (parameters) and what the return format is. With no output schema, the description should clarify output, but overall it's understandable for a simple 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 coverage is 0% and description never references image_url or image_base64. Parameter names are self-explanatory but no guidance on which to use or if both are acceptable.

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?

Clearly states it's a free precheck for portrait_analysis, checking face detection and photo quality. Distinguishes from sibling portrait_analysis by positioning as a preliminary gate.

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?

Explicitly says 'before paying for portrait_analysis', indicating the intended sequence and alternative. Mentions rate limit 10/hour/IP as a usage constraint.

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?

No annotations are provided, but the description discloses that the quote is free, includes page count/route/price, and returns a quote_id. It accurately communicates the tool's behavior without contradictions. Minor gap: no mention of side effects, but for a quote tool this is sufficient.

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 fluff. The first sentence states the purpose and quote contents; the second provides integration guidance. Every word contributes value.

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

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

For a single-parameter tool with no output schema, the description explains the purpose, what the quote includes, and how to use the result. It is complete enough for an agent to select and invoke the tool correctly, though it doesn't detail the output format.

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

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

The schema covers 100% of the parameter (url) with a clear description. The tool description does not add additional meaning about the parameter itself, 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 clearly states it provides a free quote for PDF parsing, listing specific quote contents (page count, route, exact final price). It distinguishes from sibling tools by explicitly referencing parse_document, indicating the quote is a precursor to parsing.

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 explicitly says 'before any payment' and instructs to use the returned quote_id with parse_document, providing a clear workflow. This implicitly defines when to use this tool versus the parse_document 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?

With no annotations, the description carries the full burden. It discloses the cost, what is returned (10 codes), the single-use nature, no expiry, and warns to treat codes like cash. However, it does not explicitly state that providing the payment header will trigger a charge or describe the cancellation/refund policy.

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, but it packs essential pricing, quantity, language options, and a caution. All content is relevant, though it could be better structured with line breaks.

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 one optional parameter and no output schema, the description covers the purpose, cost, return value, and constraints. It does not specify the format of the codes or error cases, but this may be acceptable given the schema's explanation of the payment requirement.

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 only parameter x_payment is fully described in the schema, and the description does not add parameter-specific details. Baseline 3 is appropriate given the 100% 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 this tool provides volume pricing for style_report, specifying a 19.90 payment returns 10 single-use credit codes. It distinguishes itself from the sibling style_report tool by framing itself as a bulk purchase option.

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 bulk orders by comparing unit price (1.99/unit vs 2.99 single), but does not explicitly state when to choose this over style_report or other tools. No alternative tools are named, so guidance is implicit.

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?

With no annotations, the description carries the burden for behavioral disclosure. It adds useful context: results are 'real, probed resource[s]' with a 'measured 402 Score' and the tool is 'Free.' However, it does not disclose potential limitations such as pagination, rate limits, or authentication requirements. It is a search operation, so mutation is not a concern, but the description could offer more on what happens during execution or response handling.

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 the first sentence stating the core purpose and the second adding quality and cost. It is front-loaded, concise, and every sentence adds value without 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 search tool, the description provides adequate context: it specifies the source (Market402 verified index), the query type (capability), and result characteristics (real, probed, with 402 Score). It lacks an explicit output schema or return format description, but the absence of an output schema and the simplicity of a search operation make this acceptable. The description could mention pagination or error behavior, but it is reasonably complete for the tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'q' parameter by indicating it takes capabilities ('by capability') and gives examples ('ocr', 'market-data'). However, it does not explain the 'limit' parameter beyond its schema default. The description adds meaningful semantics for the primary parameter but is incomplete for the full parameter set.

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: 'Search the Market402 verified index of the whole x402 economy by capability.' It uses a specific verb ('Search') and a specific resource ('Market402 verified index'), with examples ('ocr', 'market-data') that make the purpose immediately clear. This distinguishes it from sibling tools, which are all specific extraction or enrichment operations.

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

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

The description implies the tool is for discovering resources by capability, which is a distinct use case from the sibling tools that perform targeted extraction or parsing. However, it does not explicitly mention when not to use this tool or name alternative tools. The context is clear enough for an agent to infer appropriate usage, 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?

The description discloses the hybrid approach ('hybrid LLM + deterministic canonicalization') and the cost ('$0.03/call'), which adds some behavioral context. However, it does not mention authentication/payment requirements, error handling, rate limits, or what happens when the X-PAYMENT header is omitted. Since no annotations are provided, the description carries the full disclosure burden but falls short.

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 sentence plus a cost flag. It is front-loaded with the primary action and includes only essential extra information. Every word earns its place, with no redundant filler.

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

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

Given the tool's complexity (nested objects, no output schema, no annotations), the description is too sparse. It does not explain the expected return format, the payment flow (e.g., that omitting x_payment returns payment requirements), or how the schema parameter is used in more detail. This makes it insufficient for an agent to confidently invoke the tool without consulting external schema details.

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

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

The schema covers 67% of parameters with descriptions (schema and x_payment), but the tool description adds little beyond restating the concept of filling a JSON schema. The 'url' parameter has no schema description and the tool description does not clarify URL format or constraints. The x_payment parameter is adequately described in the schema, but the description fails to compensate for the remaining gaps.

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

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

The description uses a specific verb+resource pattern: 'Fill YOUR JSON schema from any URL' indicating a schema-guided extraction. It conveys the core functionality clearly. However, it does not explicitly distinguish itself from sibling tools like extract_url or parse_document, though the mention of 'YOUR JSON schema' implies a user-defined output format.

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

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

No guidance is provided on when to use this tool versus alternatives. It states generic capability ('from any URL') but does not mention exclusions, prerequisites, or when a different tool would be more appropriate. There is no explicit 'use when' or 'use instead' 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?

With no annotations, the description carries the burden. It discloses a flat fee of $0.05/call, required photo counts, and the analytical sources (colorimetry consensus, published geometry rules). It does not mention authentication or error handling, but the pricing and input constraints are useful behavioral context.

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

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

The description is two sentences that pack a lot of information without redundancy. It front-loads the core purpose before diving into specifics.

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?

Despite having no output schema, the description outlines what the verdict contains (color, face-impression, body frame, integration rules), giving the agent a clear sense of the return value. It also states pricing and input requirements. It lacks explicit output structure, but for a complex tool this is a reasonably complete overview.

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

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

The schema has only 14% description coverage, so the description must compensate. It clarifies that images should be face photos (1-3), body_image_url is for full-body, and questionnaire is optional, which adds value beyond the raw schema. However, parameters like style, image_url, and image_base64 are not addressed in the description, leaving some ambiguity.

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 specifies the tool's function as an integrated styling verdict, enumerating its components (seasonal color, face-impression zone, body frame, integration rules). This distinguishes it from sibling tools like portrait_analysis or style_report by emphasizing the integrated nature and specific inputs.

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 on when to use (when an integrated verdict is desired) and input requirements (1-3 face photos, optional full-body+questionnaire). It does not explicitly reference alternatives or situations where a sibling tool would be preferred, but the integrated scope implies its use case.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses pricing (flat $2.99/call, $1.99 with prepaid pack_code), the return format (report_pdf_base64 + full profile JSON), and output traits like 'honest confidence' and 'disclosed candidate conflicts.' It does not explicitly state side effects or permissions, but the read-only nature is implied and cost is a significant disclosure.

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 high information density. Key deliverable is front-loaded, and pricing/pack_code details are relevant. The enumeration of report contents could be trimmed, but overall it is efficient and well-organized.

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 tool's purpose, target audience, return format, and pricing. It does not mention prerequisites (e.g., whether a style_profile must already exist) or error handling for payment failures. Given the absence of an output schema, this is reasonably complete for a paid report tool.

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

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

Schema description coverage is 63%, meaning several parameters (style, image_url, image_base64) lack descriptions. The tool description adds context about pack_code and pricing, but does not compensate for the undocumented parameters or clarify how images are to be supplied. It provides minimal value beyond the schema.

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

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

The description clearly states the tool's function: rendering a style-profile analysis as a client-ready English PDF report with specific contents (palette, outfit formulas, draping boards) and returning it as base64 PDF plus JSON. It implicitly distinguishes itself as the final deliverable, but does not explicitly contrast with the sibling style_profile tool, so differentiation is present but not overt.

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 specifies the intended audience ('For agents serving human end-clients') and implies this is the polished output step, but does not explicitly state when to choose this over style_profile or when not to use it. No alternative tools or exclusion criteria are mentioned.

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?

No annotations are provided, so the description carries the burden. It discloses the cost ($0.015/call), specific checks, and that it accesses the official Japan NTA registry (an external call). It does not mention failure modes or data storage, but it provides substantial behavioral context beyond the tool name.

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: the first front-loads the purpose and scope, the second states cost. Every word earns its place, with no fluff 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?

Given the absence of an output schema and annotations, the description provides a reasonable overview (output as accounting-ready JSON, cost, verification types) but lacks details on error handling, payment flow, and the required format of nested parameters. It is adequate for tool selection but not fully complete for invocation.

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

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

Schema description coverage is only 33% (only x_payment has a description). The tool description mentions 'line-item totals' and 'arithmetic consistency', hinting at the use of line_items and fields, but it fails to define the expected structure of the 'fields' object or the 'line_items' array. This leaves agents with insufficient information to correctly populate those 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 a specific verb ('Verify') and resource ('extracted invoice fields') and details multiple verification aspects (arithmetic consistency, line-item totals, JP registration check-digit, corporate-number existence). This distinguishes it from sibling document-processing tools like parse_document 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?

Usage context is implied: use it when you have extracted invoice fields and need verification. However, there is no explicit guidance on when to use this tool vs alternatives, nor any exclusions or mention of alternative tools like parse_document or structured_extract.

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