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 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 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.