docs

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

Goes beyond annotations by disclosing cost ($0.05/document), that inputs are validated before payment (no charge on invalid input), and that OCR is hallucination-guarded. Annotations already cover idempotency and non-destructiveness, so this adds real value; it could say more about failure modes or what the enrich step returns, but the paid-call semantics are unusually well covered.

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

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

Front-loaded with the pipeline summary, then cost, then selection guidance. Dense but every clause carries information; the parenthetical asides make it slightly busier than necessary, keeping it just short of a 5.

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

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

With an output schema present the return values need no explanation, and annotations cover the safety profile. The description supplies purpose, cost, selection rule, and alternative, so nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so all three parameters (url, enrich, x_payment) are already documented. The description echoes the optional enrich step but adds no syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource chain (parse PDF invoice, extract fields, verify arithmetic, optional enrich) and explicitly distinguishes itself from the sibling parse_document by input type ('for text only use parse_document'). An agent can select it without opening either schema.

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

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

Gives an explicit when-to-use condition ('when a PDF is an invoice/receipt and you want parse + field extraction + arithmetic verification in one paid call') plus a named alternative (parse_document) for the text-only case. Both the selection rule and the exclusion are 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?

Adds real behavior beyond the annotations: $0.03/company pricing, "unresolved lookups never charged", per-field evidence with confidence scores, and honest nulls. These are exactly the cost/quality characteristics annotations cannot express. It doesn't restate the idempotent/openWorld hints, and there is no contradiction with readOnlyHint=false (a paid call is reasonably non-read-only).

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

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

Front-loaded enough that the core purpose lands early, but it opens with a sentence fragment ("Company name/domain/URL to a verified profile...") and repeats "per-field evidence + confidence" in two separate places, wasting one of its few sentences.

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

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

With an output schema present, return values need no explanation, and the description supplies the sources, pricing, null/charge policy, and the country_hint trigger. The x402 payment flow is delegated to the x_payment schema field, which is acceptable but leaves the payment round-trip implicit in the prose.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates that the input is a name/domain/URL and adds the reason for country_hint ('jp' for Japanese companies), but that value-add is marginal over the schema's own "ISO country hint for registry lookups, e.g. 'jp'". The x_payment mechanism is left entirely to the schema.

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

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

States a concrete transformation (company name/domain/URL into a verified profile) and names the actual primary sources (GLEIF LEI, Japan NTA corporate-number registries). This is far more specific than a generic 'look up company', though it never explicitly contrasts itself with the sibling jp_company_profile, leaving some ambiguity for an agent choosing between them.

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

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

"Choose this when you have a company NAME or DOMAIN and need a registry-grounded profile" gives a clear triggering condition, and it tells the agent to pass country_hint 'jp' for Japanese companies. It lacks an explicit when-not or a named alternative (e.g. jp_company_profile), so it stops short of a 5.

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

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

Annotations already declare openWorldHint=true, idempotentHint=true, destructiveHint=false, so the burden is partly lifted. The description adds genuinely non-structured behavior: automatic JS rendering, robots.txt compliance, and tiered pricing with a cache discount. It does not explain the x402 payment handshake beyond what the schema says, so not a full 5.

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

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

Three compact sentences, zero filler: purpose first, cost/behavior second, routing last. Every clause carries information an agent uses for selection or invocation.

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

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

Output schema exists, so return values need not be described. Given the tool's complexity (payment, modes, caching), the description covers purpose, cost, behavioral traits, and sibling routing, leaving nothing critical to inference.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds economic meaning to mode selection ('$0.005 fast / $0.01 rendered; cached results half price') and ties caching to cost, which the schema's ttl description does not. Minor friction: it says 'rendered' while the enum value is 'heavy', leaving the mapping implicit.

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

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

States a specific verb and resource ('Extract a web page to clean Markdown + metadata') with the output artifact named. It explicitly carves itself out from structured_extract (schema filling) and pdf_info/parse_document (PDFs), so an agent can route without opening sibling schemas.

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

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

Explicit selection rules: 'Choose this when you need a web PAGE as clean Markdown to read yourself', with named alternatives for the two nearest competing intents. Both the use case and the when-not conditions are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds genuinely non-structured context: the call is free, and it returns payment config, error codes, and rate limits — useful in an x402/pay-per-call ecosystem. It stops short of saying whether the catalog is cached or how often it changes.

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

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

A single telegraphic sentence with the resource front-loaded and the cost signal last; nothing is wasted. The fragment style ('Free.') is slightly clipped but still unambiguous and appropriately sized for a zero-arg 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?

With zero parameters, rich annotations, and an output schema that already documents return values, the description needs only to identify the resource and its scope — which it does. Enumerating the returned categories (prices, payment config, error codes, rate limits) is a helpful bonus rather than a 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 tool takes zero parameters, so per the rubric the baseline is 4 and there is nothing for the description to disambiguate. No parameter detail is required or missing.

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

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

The description names a specific resource (Mart402 product catalog) and enumerates what it contains: products, prices, payment config, error codes, rate limits. An agent can tell this is a discovery/metadata endpoint rather than a data-processing tool. It does not distinguish itself from the one plausible sibling, search_x402_services, which is a minor gap.

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 only usage signal is the trailing word 'Free,' which implies a cost advantage over paid x402 siblings but never states when to call this versus search_x402_services. There is no statement of prerequisites, ordering, or when-not-to-use.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely behavioral fact not present in annotations: the call is free and requires a receipt_id issued by a prior paid response. It omits whether receipts expire or whether the re-fetched payload is identical, but with annotations carrying safety this is solid.

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 action and resource, with the clarifying parenthetical placed after the essential information. 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?

An output schema exists, so return values need not be described, and annotations cover the safety semantics. The description supplies purpose, parameter provenance and cost behavior; only minor operational details (receipt lifetime, pagination/error behavior on an invalid id) are absent.

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

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

Schema coverage is 100% and the schema already documents the single parameter including its 'rcpt_...' format. The description's provenance note ('from a paid response') largely restates the schema's own wording, so it adds little beyond the structured field. Baseline 3 applies.

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

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

States a specific verb and resource ('Re-fetch a previously paid result') plus the selection key ('by receipt id'), and adds the key differentiator that this path is free. No sibling tool overlaps, so an agent can identify this as the free retrieval path for a paid result without opening the schema.

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

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

The description tells the agent the precondition (you must hold a receipt_id) and where that id comes from ('every paid response carries receipt_id'), which implies the when-to-use condition: retrieving a result already paid for rather than paying again. It does not explicitly name an alternative or a when-not-to-use case, but the context is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond that: the payload is a *recorded* production response, it is free, and it is flagged with sample:true, which tells the agent the data is illustrative and not live processing of its own input.

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

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

The first sentence is well front-loaded and earns its place, but the trailing 'Available: ...' clause reprints all 28 enum members that already appear in the schema, roughly doubling the length with zero added 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?

An output schema exists, so return values need not be explained, and the single parameter is fully documented. The description covers what the sample is, where it comes from, and how it is flagged, leaving only minor gaps (e.g. whether the sample corresponds to the same shape as the live paid call).

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

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

Schema coverage is 100% and the single 'product' parameter is a fully enumerated, documented string, so the schema carries the semantics. The description's product list simply restates the same enum values verbatim and adds no syntax, format, or selection meaning beyond it — baseline 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?

States a specific verb+resource ('Free recorded sample response for a paid product') and makes the scope explicit: it returns a preview of the exact response shape rather than doing the work. This cleanly separates it from the paid sibling tools (document_pipeline, enrich_company, ocr_image, etc.), which an agent can distinguish without opening either schema.

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

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

Gives a clear selection context: 'see the exact response shape before paying anything', i.e. call this when previewing a paid product's output rather than invoking the paid tool. It does not name an explicit alternative or a when-not-to-use condition, so it falls short of the top band.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, destructiveHint=false. The description adds real operational context beyond that: dual-engine consensus, calibrated confidence, per-segment corroboration, and a flat $0.05/image cost, which matters because this call is billed. It does not mention the x402 payment handshake, though the schema covers it.

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, zero filler, front-loaded with the capability and cost, then the routing rule. 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?

An output schema exists, so return-value explanation is unnecessary, and the schema documents the one-of input and payment header. The routing rule and cost complete the picture; only the payment-requirement flow is left entirely to the schema.

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

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

Schema coverage is 100%, so lang, image_url, image_base64 and x_payment are already documented in the schema. 'Japanese-strong' hints at the lang default but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

Specific verb (OCR) plus resource (one image) plus the differentiating capabilities (dual-engine consensus, calibrated confidence, per-segment corroboration) and the language specialty. It explicitly names the sibling it is not: parse_document.

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?

States the selection condition directly: 'Choose this when the input is an IMAGE (photo, screenshot, receipt); for PDFs use parse_document.' Both the when and the when-not are given, with the alternative named.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false, but the description adds the substantive behavioral detail those annotations omit: the 402 response quotes an exact price, omitting x_payment returns payment requirements without being charged, and quote_id locks the price. This is real value beyond structured fields, though limits such as document size or failure handling are unstated.

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, all load-bearing, with the core capability front-loaded before routing and payment mechanics. The stacked parentheticals in sentence one are slightly packed, but nothing is padding or repetition of the name/title.

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?

An output schema exists, so return-format explanation is unnecessary. For a 3-parameter paid tool with no required fields, the description covers capability, output form, parameter choice, prerequisites (pdf_info), alternatives (document_pipeline), and the payment lifecycle an agent must navigate to invoke it successfully.

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

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

Schema description coverage is 100%, so baseline is 3. The description goes further by explaining the semantic relationship declared only structurally in x-required-one-of: 'One of the two is required', plus the tradeoff that url is the one-step form while quote_id carries a pre-fixed price. That interpretation is not derivable from the schema alone.

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

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

Names a specific verb and resource with the exact output form: 'Parse a PDF to structured Markdown'. The parentheticals add distinguishing traits (hallucination-guarded OCR, Japanese-strong) that separate it from the many other PDF siblings. An agent can identify this tool without opening the schema.

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

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

Explicit routing: choose this when the input is a PDF and full text as Markdown is wanted; call pdf_info first if scanning status is unknown; use document_pipeline for invoices needing verification. It also states how to choose between url and quote_id (one-step vs. fixed price). Both when-to-use and alternatives are covered.

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

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

Annotations cover the safety profile (destructive=false, idempotent=true, openWorld=true), and the description adds the cost dimension ('$0.001', 'cheapest real call') plus the cheap-probe-before-parsing workflow, which is genuine context not in the structured fields. It does not contradict readOnlyHint=false (the paid call is a real side effect), though it never explicitly frames itself as a metered x402 call — that detail lives only in the x_payment schema field.

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

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

Two dense sentences with zero filler; the value proposition and cost come first, then the routing instruction. 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?

An output schema exists, so return values need not be explained, and the description still previews the payload (pages, metadata, text volume, scan estimate). Purpose, cost, and downstream routing are all covered for a 2-param read 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 100%, so both url and x_payment are already documented in the schema, including the omit-to-get-payment-requirements behavior. The description adds no parameter-level syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('PDF facts') and enumerates the exact outputs: pages, metadata, per-page text volume, scanned-or-not estimate. It explicitly positions itself against siblings parse_document, pdf_pages and document_pipeline, so an agent can distinguish it without opening any schema.

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

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

'Choose this first for any unknown PDF (cheapest real call); then parse_document, pdf_pages or document_pipeline' gives an explicit ordering rule and names the alternatives that follow. When-to-use and which-sibling-next are both spelled out rather than implied.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds two facts those annotations do not: the operation is deterministic and it costs $0.003, which is genuinely useful for a paid tool. It still says nothing about failure behavior or turnaround, hence not a 5.

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

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

Two short fragments, front-loaded with the operation and its cardinality limit, and each clause carries information: ordering, bound, determinism, price. There is no filler.

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

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

With an output schema present, return values need not be explained, and the payment mechanics are documented in the x_payment parameter. The description signals that the call is paid ($0.003), covering the main non-schema concern; only error/latency expectations are absent.

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

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

Schema description coverage is 100% and the two parameters are fully documented there, including the ordering constraint and the x_payment flow, so the baseline of 3 applies. "In order" echoes the schema's own wording rather than adding syntax or format detail.

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

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

The description names a specific verb and resource ("Merge 2-10 PDFs into one, in order"), which is unambiguous and inherently distinguishes it from the read-oriented siblings pdf_info and pdf_pages. It stops short of explicitly contrasting itself with any sibling, so it lands at clear-but-undifferentiated.

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

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

Usage is implied by the constraint (combine 2-10 PDFs) plus the cost note, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as pdf_pages or document_pipeline. The price signal gives a decision-relevant cue but no routing guidance.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds genuinely new behavioral context: a fixed $0.002 cost and the fact that output goes 'into a new PDF' (input is not mutated). It does not disclose error behavior for invalid ranges or payment-flow details beyond what the x_payment schema param already says.

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

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

Two tight sentences, front-loaded with the action and scope, followed by the differentiators (deterministic, cost). No filler or redundancy.

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

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

An output schema exists so return values need no explanation, and the description covers purpose, cost, and non-destructive output. It is slightly incomplete on error handling for malformed ranges and on how it relates to sibling PDF tools, but adequate for a simple, well-annotated extraction 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 100%, so the schema already documents url, pages, and x_payment. The description's '1-based ranges (e.g. 1-3,7)' merely restates the pages schema description, adding no syntax or edge-case meaning beyond it.

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

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

States a specific verb (Extract), resource (pages from a PDF), input format (1-based ranges), and output (a new PDF), which lets an agent separate it from siblings like pdf_merge or pdf_info by function. It stops short of naming those siblings explicitly, so there is no direct differentiation.

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

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

The purpose implies when the tool applies (you have a PDF and want a subset of pages), but there is no explicit when-to-use vs alternatives guidance and no mention of when to prefer pdf_merge or pdf_info. Usage is left to inference from 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?

Annotations already cover readOnly, idempotent, and non-destructive, so the safety profile is done. The description adds genuinely new context the annotations don't carry: the operation is free, no payment occurs, and the returned quote_id is the credential for the follow-up parse_document call.

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

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

Two sentences, no filler, and the value proposition ('free', 'exact final price', 'before any payment') is front-loaded where the agent needs it.

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

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

An output schema exists, so return-value documentation isn't required, and the description still previews the key return fields and the quote_id handoff. The only gap is any precondition on the input URL, which is minor for this simple one-param 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?

One parameter with 100% schema description coverage ('PDF URL'), so the schema handles the semantics. The description adds nothing about URL constraints (public accessibility, size limits), so the baseline 3 applies.

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

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

States a specific verb and resource (quote a PDF parse) plus what the quote contains: page count, route, and exact price. It clearly distinguishes itself from parse_document by framing itself as the free pre-payment step.

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 positions the tool as coming 'before any payment' and tells the agent to use the returned quote_id with parse_document. It doesn't spell out when to skip this tool (e.g., if a quote is already held), so it stops short of a full when/when-not statement.

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

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

Annotations already declare openWorldHint=true and idempotentHint=true, and the description adds genuinely useful context the schema doesn't: the $0.03/call cost and the hybrid LLM+deterministic execution model. It doesn't explain the unexpected readOnlyHint=false or any rate/latency behavior, but the pricing disclosure is meaningful value beyond structured fields.

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

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

Two tight sentences, with the core purpose and cost front-loaded before the routing guidance. No wasted words.

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?

An output schema exists, so return values need not be described, and the payment path is covered in the x_payment schema. Cost and sibling routing are provided, though the description could say more about input limits (page/PDF size, schema complexity) for a service with a per-call fee.

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

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

Schema description coverage is 100%, so the schema already documents url, schema, x_payment, and instructions fully. The description reinforces 'your own schema' and 'any URL/PDF' but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ('Fill YOUR JSON schema from any URL') and adds the mechanism ('hybrid LLM + deterministic canonicalization'). It also names the sibling tools it is not (enrich_company, jp_company_profile), so an agent can distinguish it without inspecting schemas.

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

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

Explicitly states when to choose it ('when you have your OWN JSON schema to fill from any page') and names the alternatives for the company-profile case. The routing condition is unambiguous.

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

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

Annotations cover the safety profile (destructiveHint=false, idempotentHint=true, openWorldHint=true for the NTA lookup), so the description's added value is the per-call price ($0.015/call) and the specific external check performed. It does not explain how the x_payment charge/accepts flow interacts with a failed verification, which keeps it short of a 5.

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

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

Front-loaded with what gets checked, then price, then routing guidance in a single compact block. Dense but each clause carries information; the only mild redundancy is restating 'invoice' across the check list.

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?

Output schema exists so return values need not be re-explained, and the mention of 'accounting-ready JSON' plus the precise check list, cost, and sibling routing covers everything an agent needs to call this correctly.

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

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

Schema coverage is 100% and the schema itself documents fields, x_payment, and line_items, so baseline is 3. The description only lightly reinforces this by naming 'line-item totals' and the per-call fee; it adds no format, enum, or validation detail beyond the schema.

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

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

States a specific verb (verify) plus resource (extracted invoice fields) and enumerates the actual checks performed: arithmetic consistency, line-item totals, JP registration check-digit, and NTA registry lookup. It also explicitly separates itself from document_pipeline, so an agent can pick it without opening either schema.

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

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

Gives an explicit when-to-use ('when you already HAVE invoice fields from your own extraction') and an explicit when-not with the named alternative ('to start from a PDF use document_pipeline'). Routing is unambiguous.

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