mint 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, 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 only cover the safety profile (readOnly, idempotent, non-destructive); the description adds genuinely new behavior: the credit formula ceil(pages/20) with a minimum of 1, the accepted input encodings, the return shape, and the fallback signal (meta.note) for PDFs with no text layer. That is cost, encoding, and edge-case disclosure well 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?

Front-loaded with the purpose, then cost, input, and output in compact fragments; every piece carries information. The telegraphic 'File input (file): ... Output: JSON. {...}' style is dense but not padded, costing only a little readability.

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 return structure ({page_count, pages, chars}) and the no-text-layer note, plus pricing and accepted input forms. Nothing needed to call this three-parameter tool 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 description coverage is 100%, so the schema already documents 'file', 'pages', and 'layout'. The description restates the same input formats and page-range idea without adding syntax or constraints the schema lacks (e.g., 10 MB cap lives only 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') and immediately names its two distinguishing capabilities (page selection, layout-preserving mode). An agent can separate it from pdf_info, pdf_merge, and pdf_split 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 through the feature list and the credit-cost formula, which nudges toward narrow page ranges, but there is no explicit when-to-use statement and no named alternative (e.g., pdf_info for metadata only). A reader must infer the selection criteria.

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.