vøiddo utilities

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: a cost of 1 credit per call and the output payload shape, which the annotations do not provide.

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-loads the operation, then the cost, then input forms, then output shape — each fragment carries distinct information with no filler or repetition.

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

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

With no output schema present, the description supplies the return structure ({rows, cols, columns: [...]}) an agent needs to consume the result, alongside cost and input forms. Nothing essential for correct invocation 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 description coverage is 100%, so every parameter is already documented in the schema, including the base64/data-URI/url forms of 'file'. The description restates the file input forms and adds nothing about formats, encoding, header handling or max_rows beyond what the schema says, so baseline 3 applies.

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

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

States a specific verb (Profile) and resource (CSV, TSV, XLSX or JSON table) and enumerates exactly what is computed per column. An agent can distinguish this from tabular_convert without any further context.

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

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

Usage context is implied by the operation itself, and the credit cost signals weight, but the description never says when to prefer this over siblings such as tabular_convert or json_yaml_convert, nor any when-not condition.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavior context: a per-call cost of 1 credit and the JSON shape returned by each operation. It stops short of stating rate limits, throttling, or data freshness beyond 'latest'.

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 plus a compact per-operation output spec, with purpose, cost, and return shapes front-loaded and nothing redundant. Every clause carries information an agent needs before calling.

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

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

With no output schema, the description usefully enumerates the three return shapes, and it flags the credit cost. For a 9-parameter, zero-required tool it leaves defaults and the 'quotes' batching behavior to the schema, which is acceptable given the 89% coverage.

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 already 89%, so baseline is 3, but the output shapes ('base, quote' for history; 'amount, from, to' for convert) implicitly map parameters to the operation that consumes them, clarifying that some fields are op-specific aliases. This adds meaning beyond the per-property descriptions without fully explaining defaults.

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 ('euro foreign exchange reference rates from the European Central Bank') and adds the conversion capability, which is a distinct function. No sibling tool touches currency, so an agent can identify it immediately among the many conversion/format siblings.

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

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

The three modes (latest, convert, history) are named along with their outputs, which implies when each applies, but there is no explicit when-to-use guidance or exclusions. Since no sibling overlaps, the practical risk is low, so this is adequate rather than strong.

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 (read-only, idempotent, non-destructive, open-world). The description adds genuinely useful operational context beyond them: the 1-credit cost per call and the specific upstream resolvers used. It does not mention rate limits or failure/status semantics, so it stops 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?

Three tightly-packed sentences: purpose front-loaded, then cost, then output shape. No filler; every clause carries information an agent needs before calling.

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

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

With no output schema, the description compensates by spelling out the JSON return shape (name, type, status, records with value/ttl, count, resolver, elapsed_ms), plus cost and resolvers. Nothing essential is missing for this single-purpose lookup 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 'name', 'type', and 'all' (including punycode conversion and PTR address handling). The description only restates the record-type set and 'public name', adding little beyond the schema. Baseline 3 is correct.

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 (Look up), the resource (DNS records), enumerates all supported record types, and scopes it to public names resolved via Cloudflare and Google. An agent can distinguish this from ip_lookup and rdap_lookup immediately.

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 'public name' and the record-type list, but there is no explicit when-to-use guidance and no reference to the alternatives (e.g. rdap_lookup for registration data, ip_lookup for reverse lookups) despite those siblings existing. Adequate but leaves selection to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds value beyond that: per-call cost, supported coverage (250 countries/regions), and a concrete output shape. It still omits what happens on invalid subdiv/language combinations or unknown country codes.

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 tight fragments: what it returns, what it costs, and the exact response shape. Front-loaded with the highest-value information and no filler whatsoever. The inline JSON sketch communicates return structure in minimal characters.

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

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

With no output schema, the description usefully inlines the response shape ({country, year, subdiv, holidays[], count}), and cost is disclosed. Combined with rich schema descriptions and full annotation coverage, an agent has almost everything needed. Only minor gaps remain around error behavior and variable subdivision support across countries.

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 83%, so the schema already documents all six parameters including formats and defaults. The description only echoes parameter names (year, subdiv, language, category) without adding syntax or constraint detail. This meets the baseline rather than exceeding 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 resource (public holidays), scope (about 250 countries and regions), and key qualifier (for a given year, with optional subdivision/language/category). No sibling tool overlaps with holiday data, so the agent can identify this unambiguously. The verb is carried by the name ('lookup'), making the intent unmistakable.

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 rather than stated — the description never says when to call this instead of anything else, though no sibling offers comparable data. It does add a decision-relevant cost signal ('1 credit per call'), which helps an agent weigh the call. No exclusions, prerequisites, or edge-case conditions (e.g., subdiv support varies by country) are given.

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 establish the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower, and the description still contributes real behavioral facts: a 3-credit cost, an inline file return, and a 1 MiB output cap. Retina scaling and transparent-background support are also disclosed, though error/failure behavior and the JS-not-executed caveat (left to the schema) are not mentioned.

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 opening sentence and the cost/output sentences are front-loaded and efficient, but the definition ends with the dangling, incomplete fragment 'The rendered image', which is wasted text and looks truncated. Useful content is present, but the trailing orphan costs it.

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

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

With no output schema, the description correctly carries the return-value burden, specifying an inline file (image/png | image/jpeg | image/webp) capped at 1 MiB and noting JavaScript is not executed. Combined with 86% schema coverage and full annotations, an agent has enough to call it, though the dangling final sentence and absent sibling routing leave minor gaps.

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

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

Schema description coverage is 86%, so the schema already documents html, width, height, quality, transparent and device_scale_factor with ranges and defaults. The description's mentions of width, retina scaling and transparent background largely restate that, adding no syntax or format detail beyond it; 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 (Render) and resource (an HTML snippet) plus the concrete output artifacts (PNG, JPEG or WEBP), so an agent immediately knows this produces a raster image. It implicitly separates itself from html_to_pdf by output format, but never names that or any other sibling, so a choice between this and screenshot still requires inference.

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 when-to-use or when-not-to-use guidance and no named alternative, even though screenshot and html_to_pdf are obvious competitors in the toolset. The cost line ('3 credits per call') hints that cost should factor into tool selection, but no condition is spelled out.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value beyond them: a per-call cost of 3 credits, the return medium (inline application/pdf), and a hard output cap of 1 MiB. It does not note failure modes or what happens on oversized output, but this is solid extra 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?

Two dense, front-loaded sentences that open with the action and immediately follow with cost and output constraints. The trailing fragment 'The PDF document' is dangling and adds nothing, the only real waste.

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

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

With no output schema, the description correctly fills that gap by stating the return type, delivery mode and size ceiling, and it discloses metered cost. An 8-parameter tool with 88% schema coverage plus this prose is adequately specified, though error/limit behavior on oversized inputs is unstated.

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 high (88%), so a baseline of 3 applies, but the description maps its prose onto parameters by naming page size, margins, orientation and page-numbered header/footer, matching format, margin_mm, landscape and header_text/footer_text. It gives no units or defaults, but semantics are largely carried by 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 and resource (HTML document -> print-ready PDF) and enumerates configurable aspects (page size, margins, orientation, header/footer). It is clearly distinguishable from pdf_merge, pdf_split and html_to_image by input and output type, though it never names a sibling to contrast with.

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 makes usage largely self-evident (choose this when you have HTML and want a PDF), but there is no explicit when-to-use vs html_to_image/screenshot guidance and no exclusions or prerequisites stated. Usage is implied rather than directed.

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 (readOnly, idempotent, non-destructive), and the description adds genuinely new operational facts: 1 credit per call, accepted input encodings, and a 1 MiB inline output ceiling. It stops short of saying what happens when the result exceeds 1 MiB (error vs truncation), which is the one behavioral gap.

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

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

The first three sentences are dense and well front-loaded (capability, cost, I/O contract). However, the description ends on a dangling fragment, 'The converted image', which is an incomplete sentence that wastes space and slightly muddies the return-value statement.

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

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

With no output schema, the description correctly carries the return contract: inline file with enumerated MIME types and a size cap. For an 8-parameter tool at 88% schema coverage the essentials are present; only the over-limit behavior and any latency/size tradeoff for resizing are unstated.

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 88%, so the schema already documents nearly every parameter. The description's mention of quality, fit modes, transparency handling and metadata stripping merely names fields that the schema explains in more detail, adding no new semantics.

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

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

States a specific verb pair (convert and resize) plus the resource (images) and enumerates the supported format set, which is enough to separate it from raster-unrelated siblings like svg_to_png, html_to_image and screenshot 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?

Usage is implied by the operation itself (you reach for this when you need a different image format or dimensions), and the cost line signals this is a billable server call. But there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as svg_to_png for vector sources.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-structured context: a cost of 1 credit per call and the fact that only open registry data is consulted, which affects expectations about freshness and coverage.

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 sentences that front-load purpose and then cost/output. The trailing inline JSON shape is dense but informative; nothing is wasted, though the output sketch could have been prose.

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

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

With no output schema, the description usefully sketches the return shape (ip, version, is_private, reverse_dns, network fields) and discloses cost. For a single-parameter read tool this is nearly complete; only sibling differentiation is missing.

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

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

Schema coverage is 100% and the single 'ip' parameter is fully documented as a public IPv4/IPv6 address, so the baseline is 3. The description reinforces the public-address constraint but adds no syntax or format detail beyond the schema.

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

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

The description names a specific resource (reverse DNS name and registry record of a public IP) and states the data source ('open registry data only'), so the agent knows exactly what this returns. It does not, however, contrast itself with the same-domain siblings dns_lookup and rdap_lookup, leaving overlap unexplained.

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 constraint given is 'public IP address'; there is no guidance on when to prefer this over dns_lookup or rdap_lookup, which appear to cover adjacent ground. Cost is stated, but no when/when-not framing is offered.

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/openWorld/idempotent/non-destructive, so the safety profile is covered. The description goes beyond them by disclosing the cost model ('1 credit per call') and the exact response shape, which are not in any structured field. It omits rate limits or error behavior, 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?

Front-loaded purpose sentence followed by two compact payloads (cost, output shape) with no filler. The inline output structure is dense but earns its place because no output schema exists. Slightly overloaded in a single block.

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

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

With no output schema, stating the return object shape ({type, query, results, count, total, truncated}) is exactly what an agent needs, and the cost disclosure is important for a metered API. Remaining gap is the un-explained 'limit' parameter, but the definition is otherwise sufficient for correct invocation.

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

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

Schema coverage is 50%: 'query' and 'country' are documented in the schema, while 'type' and 'limit' are not. The description recovers 'type' by enumerating the four categories and clarifies 'query' as code-or-name-fragment, but says nothing about 'limit' (default 10, max 50) or when 'country' applies. Baseline 3 for partial compensation.

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 ('Look up') and enumerates exactly which standard code sets are covered (ISO 3166 country/subdivision, ISO 4217 currency, ISO 639 language). No sibling tool (currency_rates, timezone_convert, etc.) overlaps this scope, so an agent can route here unambiguously.

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 enumeration of covered code systems implicitly tells the agent what this tool is for, but there is no explicit when-to-use/when-not guidance or named alternative for adjacent tasks (e.g. vs currency_rates for rates rather than codes). Usage is inferable but not stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: cost of 1 credit per call, the supported draft versions, and a truncation indicator in the meta output. These extend well beyond what structured fields disclose.

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?

Extremely compact and front-loaded: purpose first, then cost, then output shape. Every clause carries information with no filler.

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

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

With no output schema, the description compensates by documenting the exact return shape ({valid, errors, count} and meta), plus drafts, cost, and the truncation flag. An agent has everything needed to call and interpret the result.

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

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

Schema coverage is 100%, so the schema already documents draft, schema, instance and instances, including the enum and the 1000-item limit. The description adds nothing per-parameter beyond echoing the draft list and the instance count, so baseline 3 is appropriate.

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

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

States a specific verb (validate) and resource (JSON document(s) against a JSON Schema) with scope (single or up to 1000 instances). An agent can immediately tell this apart from the conversion-oriented siblings like json_yaml_convert.

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 batching is supported ('or up to 1000 of them') but gives no explicit when-to-use, when-not, or routing guidance, since no sibling directly competes. Usage is inferable but not spelled out.

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 establish the safe, read-only, idempotent profile, so the bar is lower; the description still adds real operational context: 1 credit per call, a 1 MiB output cap, inline file delivery, and the meta {from, to} payload. It does not, however, explain error behavior beyond 'line-accurate error messages'.

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 core action and features, then terse cost/output facts. The output clause is telegraphic ('converted.json or converted.yaml; meta: {from, to}') but earns its place; no filler 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 no output schema, the description appropriately specifies the return shape (inline file, media type, filename, meta) and the size limit, which is what an agent needs. Minor gap: it does not reconcile the 2 MB input cap with the 1 MiB output cap.

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 every parameter (from, to, input, indent, minify, sort_keys) is already documented in the schema with defaults and enum meanings. The description only gestures at these options without adding format or interaction details beyond what the schema states.

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

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

Names a specific verb (Convert) plus both resources (JSON and YAML text), and the feature list (safe parsing, indent, key sorting, minify) pins down the exact scope. It is clearly distinguishable from siblings like image_convert or tabular_convert.

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 practical framing in the form of cost (1 credit per call) and size bounds, but never states when to pick this tool over alternatives such as tabular_convert or json_schema_validate. Usage is only implied by the tool's obvious purpose.

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 (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavioral facts: a per-call cost of 5 credits, accepted file input encodings, and the 10 MB size ceiling. It also discloses that output is signed and independently verifiable via verify_url, which is a meaningful trust property not present in annotations. Missing is whether failed/invalid file checks are still billed.

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 action and cost before any field detail, and the terse output-shape notation packs a lot of information into a few lines. The output listing is long but justified by the absence of an output schema, so little of it is waste.

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 four-parameter validation tool with no output schema, the description supplies the return shape, verdict vocabulary, and verification URL — the pieces an agent most needs to plan around the result. Gaps remain around error/failure responses and the meaning and defaults of the paper option.

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?

With 75% schema coverage, the schema already carries baseline documentation, and the description usefully generalizes the accepted input forms (base64, data: URI, or {"url": ...}) to both interior and cover plus the 10 MB cap. However, the paper parameter and its enum (white/cream/groundwood/color stocks) get no explanation at all, and trim is only implicitly covered, so it does not fully close the remaining gap.

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: check a KDP paperback interior and cover PDF against Amazon's published file specs, returning a signed report. An agent can distinguish this from kdp_spine_calc or kdp_puzzle_book without opening the schema. It stops short of a 5 because it never names the adjacent siblings (kdp_report in particular) to make the boundary explicit.

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 rather than stated — you run a preflight check on manuscript files before upload, and the '5 credits per call' note is decision-relevant cost context. There is no explicit when-not guidance, no mention of prerequisites (e.g., whether a cover can be checked without a spine width), and no routing to alternatives such as kdp_spine_calc or pdf_info.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses two facts an agent cannot get from structured fields: a 500-credit cost per call and an inline 1 MiB output ceiling with the exact ZIP inventory. It does not say how long generation takes, whether credits are refunded on failure, or what 'signed file check' verifies, which keeps it off 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 the deliverable, then cost, then output shape and ZIP contents — dense, zero filler. The final ZIP inventory is a raw comma list that reads tersely and 'signed file check' is unexplained, so it is efficient but not maximally clear.

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

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

For a 14-parameter generator with no output schema, the description covers the two things an agent most needs to decide and plan: cost and the returned artifact set, including size. It leaves out failure/refund behavior and whether trim/paper/large_print conflicts are validated, but the critical calling information is present.

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 64% and the description adds nothing about parameters — no hint that kind/count/level interact or that mix is required for the 'variety' kind. The undocumented params (trim, paper, title, author, subtitle) are self-evident name/format fields with enums or defaults, so the description does not need to compensate heavily; baseline 3 applies.

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

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

The description names a concrete deliverable — a ready-to-upload KDP paperback puzzle book — and enumerates its artifacts (interior PDF, wrap cover, check report, previews, listing notes), which clearly separates it from kdp_preflight, kdp_report and kdp_spine_calc. It stops short of an explicit 'use this to generate X' verb phrase, and never names the sibling tools it is distinct from.

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 only implied: the phrase 'ready-to-upload KDP paperback puzzle book' positions it as the end-to-end generation step in the KDP pipeline, and the 500-credit price signals a call to make sparingly. There is no explicit when-to-use, when-not, or pointer to kdp_preflight/kdp_report for the verification path.

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 (readOnly, idempotent, non-destructive, openWorld), so the description's added value is the free-tier/credit-exclusion note and the return contract '{found, genuine, report?}', which tells the agent how to interpret a missing or non-genuine result. It stops short of explaining failure modes or lookup latency.

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 clauses: action, billing caveat, output shape. Nothing is redundant and the core verb is front-loaded; an agent can parse it in one pass.

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

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

With no output schema, the inline '{found, genuine, report?}' contract does the job of describing return values, and the credit note removes a cost-related ambiguity. Complete enough for a single-parameter lookup, though error/not-found behavior is still implicit.

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 single id parameter is fully documented with a regex pattern in the schema. The description only restates 'by id' and adds no format, source, or retrieval nuance 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 and resource ('Look up a KDP file check report by id') plus the outcome it verifies ('confirm its signature and file fingerprints'). This is clearly distinct from the other kdp_* siblings (preflight, puzzle_book, spine_calc), though it never names them explicitly.

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

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

The only usage condition given is commercial ('Free tier only, credits do not apply'), which is a billing rule rather than a routing rule. It implies the caller must already hold a report id, but it never says when to use this versus kdp_preflight or what to do if no report exists.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely new context: it discloses the credit cost per call and that the optional template flag yields a base64 PDF cover guide, both of which the annotations do not carry.

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

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

The purpose is front-loaded in a well-packed first sentence, but the output field dump is long and ends mid-word with 'bleed…', which reads as truncated boilerplate. It earns partial credit for leading with the useful part, but the tail is noise.

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

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

With no output schema, listing return fields is the right instinct, but the list cuts off mid-field ('interior: {page_width_in, page_height_in, bleed…'), so the description fails to complete the contract it started. Enough is present to call the tool correctly, but the return-value picture is left unfinished.

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

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

Schema description coverage is 100% with enums on trim and paper, so the schema already defines every parameter. The description mentions trim, pages, paper and the PDF template option, but adds no semantics beyond the schema's own 'Also return a PDF cover guide (base64)' wording, 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?

The description names a specific computation and resource: full cover size, spine width, safe areas, barcode box, gutter and margins for an Amazon KDP paperback. It's clear what the tool does at a glance, but it never distinguishes itself from the sibling kdp_preflight, which an agent could reasonably confuse with cover/spine validation.

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 statement of when to reach for this tool versus kdp_preflight or kdp_report, and no prerequisites or exclusions. The only usage-adjacent sentence is 'Cost: 1 credit per call', which is a pricing note, not guidance on selection.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: per-call credit cost, the higher 3-credit PDF price, an output size cap of 1 MiB, inline return, and the meta fields returned. It stops short of disclosing failure modes or sanitisation specifics beyond the word 'sanitised'.

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 core purpose and feature list, then output and cost details; every sentence carries information. It is dense to the point of being abbreviated, and the credit cost is stated twice ('1 credit per call' and 'pdf costs 3 credits, html and fragment 1'), a minor 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?

With no output schema, the description correctly carries the return-value burden, naming the output files, MIME types, size limit, and meta object. Combined with 100% parameter coverage, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description earns above that by tying the format parameter to concrete credit costs and naming the produced files. It does not add anything for css/theme/toc/title beyond what the schema already states.

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

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

States a specific verb (render) and resource (Markdown) with the exact output set (sanitised HTML page, fragment, or PDF). An agent can distinguish it from siblings like html_to_pdf or html_to_image purely from the description, since the input is Markdown rather than HTML.

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 clear context for choosing among the three output modes (html = page, fragment = content only, pdf = A4 document) and notes relative cost, which helps the agent pick. It does not, however, route the agent away from overlapping siblings such as html_to_pdf when the source is already HTML.

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 openWorld, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: a per-call credit cost, the accepted input encodings (base64, data URI, URL object) and the truncation rule that page_sizes_mm covers only the first 50 pages.

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 content is front-loaded with the capability list, then input format, then output shape, in three compact sentences with no filler. It is dense rather than bloated, though the inline output-field listing overlaps with what a reader would expect from a return-value section.

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

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

With no output schema, the description carries the return contract itself and does so thoroughly, covering input encodings, size limit, cost and the output field list including the password_required flag. Minor gaps remain around error/truncation behavior for oversized or corrupt files.

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 single 'file' parameter is already documented in the schema with the same base64/data-URI/url formats and the 10 MB limit. The description restates this without adding syntax or format 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?

The description names a specific verb (Read) and resource (a PDF) and enumerates exactly what is extracted: page count, encryption flag, metadata, page sizes, text-layer presence, bookmark count. That enumeration clearly separates it from sibling extractors like pdf_text, pdf_merge and pdf_split.

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 enumerated fields (use this when you need structural/metadata facts rather than extracted text), and the cost note ('1 credit per call') is a useful decision input. However, there is no explicit when-to-use/when-not statement and no named alternative such as pdf_text for actual text extraction.

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 (readOnly, idempotent, non-destructive), and the description adds genuinely new operational context: the credit cost formula (ceil(total pages / 20), minimum 1), the aggregate 10 MB input ceiling, the 1 MiB inline output cap, and the returned filename/meta shape. These are the kinds of constraints an agent must know before invoking and are not available anywhere in the structured fields.

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

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

Extremely dense and front-loaded: the core action leads, then limits, then cost, then I/O shape. The telegraphic fragments ('Output: ... merged.pdf; meta: {...}') are slightly run-on and the filename placement is awkward, but virtually no sentence is wasted.

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

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

There is no output schema, so the description correctly carries the return-value burden and does so: inline application/pdf, 1 MiB cap, filename, and meta fields. Combined with input limits and cost, an agent has everything needed to call this correctly on the first attempt.

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

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

Schema coverage is 100%, so the baseline is 3; the schema already documents both parameters including the accepted file input forms. The description adds marginal value by restating the accepted encodings and by emphasizing order-sensitivity ('in the order given'), which reinforces the semantic meaning of the files array beyond its schema text.

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 (merge) plus resource (PDF files) plus the exact scope (2 to 20 files, in the given order, bookmarks optional). It is trivially distinguishable from siblings like pdf_split, pdf_info, and pdf_text 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?

Usage is implied by the cardinality and ordering constraints ('2 to 20 PDF files into one document in the order given'), which tells the agent when this tool is applicable. However, there is no explicit routing guidance — e.g. it never says to use pdf_split to go the other direction, or when to prefer this over other document assembly paths. Implied usage only.

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 only cover the safety profile (readOnly, idempotent, non-destructive). The description adds materially more: the credit cost formula (ceil(pages written / 20), min 1), the 1 MiB inline output cap, and the exact return shape (part_01.pdf vs split.zip with meta {parts, page_count}). None of that is available elsewhere.

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?

Information-dense and front-loaded with the core action, with cost and output details following in priority order. The output-naming clause ('part_01.pdf when there is one part, otherwise split.zip holding part_01.pdf ...') is a bit run-on, but every sentence carries distinct, non-duplicated information.

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

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

With no output schema, the description carries the return-value burden and does so fully: format, MIME type, size limit, file naming, and meta contents. Input formats, cost model, and both splitting modes are all covered, leaving nothing an agent needs before calling.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The description's input-format note (base64, data: URI, {"url": ...}) and range syntax example largely restate 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 (split a PDF) plus two distinct modes (page ranges or every N pages) and the two possible outputs (single PDF or zip). This distinguishes it clearly from pdf_merge (combining) and pdf_info (inspecting) without needing to open 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?

Gives clear context for the two operating modes: 'by page ranges such as "1-2,5-" or every N pages'. It does not, however, explicitly state when NOT to use it (e.g. use pdf_merge to combine, pdf_info to inspect), so the routing guidance is implicit rather than explicit.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered structurally. The description adds genuinely useful behavior beyond that: the credit cost formula (ceil(pages/20), minimum 1), the 10 MB input cap scope, and the meta.note edge case for scanned PDFs. Missing only retry/pagination or error semantics, which keeps it below 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 the core action, then cost, input, and output in a compact sequence with no filler sentences. It is dense and somewhat run-on, packing four distinct concerns into one paragraph, but every clause carries information an agent needs given the absence of an output schema.

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

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

With no output schema, the description compensates by spelling out the full JSON return shape (page_count, pages array, chars, metadata fields) and the markdown variant key. It also covers cost, input size limit and the no-text-layer case, so an agent has everything needed to call and interpret this 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 each of the four parameters is already documented in the schema, and the description largely restates them (file formats, page selection, layout mode). It adds a little value by clarifying that markdown stripping of repeated headers/footers does not apply when layout is on, but that nuance also appears in 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?

States a specific verb and resource ('Extract the text of a PDF page by page') plus the two output modes, page selection and layout option. It is clearly distinguishable from pdf_info (metadata-oriented) and pdf_split/pdf_merge by emphasizing text extraction. No sibling does the same thing, so an agent can route to it 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?

Usage is implied through the feature list and the note that a PDF without a text layer produces meta.note, which signals an OCR-gap case. However, it never says when to prefer this over pdf_info or what to do when no text layer exists (no OCR alternative named). Guidance is present but inferred rather than explicit.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely new behavioral facts: a per-call credit cost and an inline response capped at 1 MiB in image/png or image/svg+xml. It could still say more about failure behavior, but this is solid added 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 core content is front-loaded and dense with no filler. However, the trailing fragment 'The QR image' is a dangling, incomplete sentence that earns no place and signals truncation.

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

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

With no output schema, the description usefully compensates by describing the return (inline file, MIME type, size ceiling) and the credit cost. For a simple 7-parameter generator this is close to sufficient, though error/failure behavior and the excluded color/margin parameters remain undocumented.

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 43%, so the description should compensate more than it does. It references text/URL, PNG/SVG, size, and error-correction, but the color (bg/fg) and margin/quiet-zone parameters are left to the schema and get no clarification here; no syntax or format detail is added beyond what the schema already states.

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

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

States a specific verb+resource ('Turn text or a URL into a crisp QR code') and the two output encodings. It is readily distinguishable from image-manipulation siblings like html_to_image, svg_to_png, or image_convert, which transform existing inputs rather than synthesize a QR code.

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 when-to-use or when-not-to-use guidance and no alternative tool named. The description tells the agent what the tool produces but never when it is the right choice over its many image/render siblings.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is low. The description adds real value beyond that: a stated cost (1 credit per call), the absence of personal contact data, and the shape of the normalised record returned.

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, front-loaded clauses cover scope, cost and output format with no filler. The cost and output statements are compact but each carries decision-relevant information.

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

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

With no output schema the description responsibly sketches the return value ('normalised registration record: domain, IP network or autonomous system') and discloses cost and privacy limits. Only a fuller account of the record fields or error behaviour 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 description coverage is 100% and both parameters (query format examples, fields enum semantics) are fully documented in the schema. The description only restates the accepted query types, adding no syntax or defaulting detail beyond the structured fields, 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 ('look up the public registration record') plus the accepted input types (domain, IP, AS number) and the RDAP source. An agent can tell it is not a generic DNS/IP tool, but the description never explicitly contrasts itself with the sibling tools dns_lookup and ip_lookup, which overlap in input domain.

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

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

Usage is only implied: the credit cost, the 'without personal contact data' caveat and the record types suggest when the tool fits. There is no explicit when-to-use vs when-not-to-use guidance and no named alternative for DNS/RDAP-adjacent lookups, so the agent must infer routing.

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 (readOnly, idempotent, openWorld, non-destructive), but the description adds genuinely new operational facts: the response is returned inline, capped at 1 MiB, the allowed MIME types, and that this tool bypasses credit accounting. That is meaningful disclosure beyond the structured fields, though error/failure behavior is not addressed.

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?

Purpose and output are front-loaded and the sentence count is low, but the trailing fragment "The screenshot" is a truncated, sentence-fragment artifact that adds no information and makes the definition look unfinished.

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

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

With no output schema, the description carries its weight by stating exactly what comes back (inline image file, PNG/JPEG/WEBP, ≤1 MiB), and the 9 parameters are well covered by the schema at 89%. Only the dangling final fragment and the absence of any failure/timeout behavior keep this from a 5.

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 89%, so the schema already documents url, width, height, quality, delay_ms, full_page, device_scale_factor and block_cookie_banners thoroughly. The description mirrors the notable knobs (viewport size, full page, retina scaling, cookie-banner hiding, format) but adds no format/syntax detail beyond what the schema provides, so baseline 3 applies.

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

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

Specific verb and resource: "Capture a public web page as a PNG, JPEG or WEBP image" plus capability list (viewport size, full page, retina, cookie-banner hiding). The word "public web page" implicitly separates it from HTML-string siblings like html_to_image and html_to_pdf, but no sibling is named, so the differentiation is inferred rather than stated.

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

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

The scope statement ("public web page", "Free tier only (credits do not apply to this tool)") implies when this tool is appropriate and flags that it is not credit-metered. However, it never says when to prefer this over close alternatives such as html_to_image, svg_to_png, or image_convert, and lists no exclusions beyond the public-URL restriction.

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/destructive=false, but the description adds genuinely useful non-schema behavior: external files, network references and XML entities are never loaded (a security guarantee), cost is 1 credit per call, and output is inline image/png capped at 1 MiB. It stops short of 5 because error/timeout behavior and the exact scope of 'network references never loaded' (given a URL input is accepted) are left unexplained.

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?

It is front-loaded with the core operation and useful constraints, but it contains a dangling, truncated fragment ('The rendered PNG') and restates the output location twice (file input guidance and output description), which blunts its structure.

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

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

With no output schema and six parameters, the description does the necessary extra work: it specifies the return type/size cap and the accepted input encodings, which the schema partially covers. It omits failure modes and a clear statement of what the URL input actually does over the network, so it is not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents svg, file, scale, width, height and background with constraints and the width/height/scale exclusivity. The description restates the sizing/background choices without adding format or default 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?

The description states a specific verb and resource ('Render an SVG document to a PNG'), and the SVG→raster pipeline is distinct from siblings like html_to_image or image_convert. It never names an alternative or clarifies when this beats those siblings, so it stops short of a 5.

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

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

There is no explicit when-to-use / when-not-to-use guidance and no routing to the closest siblings (html_to_image, image_convert). The only implied usage context is the width/height/scale tradeoff, which is already schema-level detail.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive, openWorld), yet the description adds substantive operational context they don't carry: cost is 1 credit (2 for xlsx output), output is returned inline capped at 1 MiB, input is up to 10 MB, and oversized inputs are rejected rather than silently truncated. These are exactly the cost/limit disclosures this dimension rewards.

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?

Purpose and formats are front-loaded and the cost line is placed early, which is the right priority. However, the output portion is choppy ('Output: a file (...) returned inline, at most 1 MiB. The converted table. meta: {...}'), with a dangling fragment and a raw meta shape that reads as schema leakage rather than prose.

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

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

With no output schema, the description carries the return burden and mostly does: it names the media types returned inline, the 1 MiB cap, and the meta object fields (rows, cols, from, to, sheet/sheets, encoding, delimiter). For a 9-parameter tool this is close to complete, though error cases beyond the 413 rejection and multi-sheet output behavior are left implicit.

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

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

Schema description coverage is 100%, so every parameter including to, from, sheet, header, encoding, delimiter, max_rows and infer_types is already documented in the schema. The description only echoes a few of these ('format, delimiter and encoding detection, header control') without adding syntax or semantics 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 and resource ('Convert tables between CSV, TSV, XLSX and JSON') and enumerates the exact formats handled. This cleanly separates it from siblings like csv_profile (profiling) and json_yaml_convert (structured-document conversion), so an agent can route 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?

The description implies when to use it (any format-to-format table conversion) and notes 'Omit to auto-detect' for the source format, but never names an alternative tool or states an exclusion. No guidance on when csv_profile or json_yaml_convert is the better choice, so usage must be inferred from the format list.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context beyond them: exact daylight-saving handling (the key correctness risk for this domain) and a per-call cost of 1 credit, neither of which appears in the annotations or 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?

Front-loaded with the core capability, followed by cost, output format, and a compact per-op return-shape summary in a single dense block. Nothing is wasted, though the inline JSON shape listing is terse and requires careful 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?

With no output schema, the description usefully discloses the return shape for all three ops (convert/info/list), plus cost and DST behavior, which is substantial coverage for a 7-parameter tool. Remaining gaps are minor: error behavior for invalid zones and how fixed-offset inputs interact with DST are left implicit.

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 86%, and the schema itself already labels each parameter with its owning op and conditional requirements (e.g. from_tz required when datetime has no offset). The description's per-op output shapes and the 'country -> zones' mapping reinforce semantics but do not add meaning the schema lacks, 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?

The description opens with a specific verb+resource ('Convert a date and time between IANA time zones') and then enumerates the two other modes (inspect a zone, list a country's zones), so all three operations exposed by the `op` enum are named and distinguished. No sibling tool in the list overlaps with timezone conversion, so there is no ambiguity to resolve.

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 effectively routes the agent: convert for datetime conversion, info for offset/transitions, list for enumerating a country's zones, and the schema param descriptions tie each parameter to its op. What is missing is an explicit 'when not to use' or edge-case guidance (e.g. choose info when you don't have a datetime), so it is clear context rather than full conditional guidance.

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