Benchline

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

Annotations already declare readOnlyHint/openWorldHint/idempotentHint, so the safety profile is covered. The description adds real value by disclosing the algorithm and key-derivation scheme and the structure of the encrypt output (salt, IV, ciphertext). However, it omits behaviorally important facts: encrypt output is non-deterministic (fresh salt/IV), and decrypt fails with an authentication error on a wrong passphrase or tampered bundle.

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

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

Two tight sentences with no filler; the algorithm/scope statement comes first and the round-trip contract second. Every clause carries information the agent cannot get from the name alone.

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

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

An output schema exists, so return shape need not be explained, and the annotations cover safety. For a 5-parameter cryptographic tool at 40% schema coverage, though, the definition should say how mode selects between text and bundle, what iterations trades off, and what a failed decrypt looks like; those gaps leave it adequate but not 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 coverage is only 40%, so the description partially compensates by implying the passphrase (via PBKDF2 key derivation) and the bundle contents (salt, IV, ciphertext). It still says nothing about the 'mode' enum, the 'iterations' knob (default 100000, range 10000-2000000) or the text-vs-bundle exclusivity, leaving meaningful gaps.

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

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

The description names a precise verb pair (encrypt/decrypt) and the exact primitives used (AES-256-GCM, PBKDF2-SHA256), which cleanly separates it from hashing siblings like hash_data/hash_password and encoding siblings like base64_codec. It stops short of explicitly routing against those alternatives, so it is clear but not full sibling differentiation.

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

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

Usage is only implied: 'Encrypt returns a base64 bundle...; decrypt reverses it' tells the agent the two modes exist and roughly what each produces, but never states when to choose this tool over hash_data, base64_codec, or generate_keypair, nor when not to use it. No prerequisites or security caveats 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral value by disclosing exactly what the analysis computes (status distribution, slowest/largest, top hosts, timings), telling the agent this is a deterministic local parse-and-summarize rather than a fetch. It omits any note on large-file handling or truncation.

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

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

A single front-loaded sentence with zero filler; the verb and resource lead, and the output enumeration follows efficiently. Nothing can be trimmed without losing informational content.

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

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

An output schema exists, so return values need not be explained, and both parameters are fully documented at 100% coverage. With annotations carrying the safety profile, the description provides everything an agent needs to select and invoke this tool correctly.

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

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

Schema description coverage is 100% – both 'har' and 'top' are fully documented in the schema, including minLength and 1-20 bounds for 'top'. The description's mention of 'slowest and largest requests, top hosts' echoes the purpose of the 'top' parameter but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (parse/summarize) and resource (HAR HTTP Archive capture), then enumerates the exact outputs: request counts, status distribution, slowest/largest requests, top hosts, per-request timings. No sibling tool does HAR analysis, so it is unambiguously distinguishable from the rest of the catalog.

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

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

Usage is implied by 'Parse a HAR (HTTP Archive) capture' – an agent knows this applies when it has HAR JSON to analyze. However, it names no alternatives or exclusions, and does not say how it relates to adjacent tools like check_http_headers, check_ssl, or fetch_page_markdown that also surface HTTP performance information.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: URL-safe output uses '-'/'_' and omits padding, and decode reports the sniffed media type plus whether bytes are UTF-8 text. It does not discuss error behavior on invalid input, but the added context is solid.

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

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

Three short sentences, front-loaded with the core encode/decode capability, then the two behavioral nuances. Every sentence carries information; no padding.

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

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

An output schema exists so return values need not be explained, and the description still helpfully notes what decode surfaces (media type, UTF-8 status). It is nearly complete for a 5-param codec, with the only gap being the unmentioned mime parameter.

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 40% (mime, action and dataUri have no schema descriptions), so the description must compensate. It does cover data-URI decoding and URL-safe semantics, but never mentions the mime parameter or the interaction between action and dataUri, leaving some parameters underspecified.

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 specific verbs (encode, decode) and the exact resource (Base64 / data URIs), and it is easily distinguished from nearby siblings like url_codec or convert_data_format. An agent knows immediately what this tool is for.

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: 'Encode ... or decode ...' plus the default action=encode. There is no explicit when-to-use or when-not-to-use guidance, and no mention of an alternative (e.g. url_codec) for related work.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds some value by noting that warnings are emitted for unsafe sources, but it does not disclose formatting constraints (e.g., source token syntax, semicolon joining) or limits on lintable policies.

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

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

Two tight sentences with zero filler, and the primary purpose is front-loaded ahead of the secondary lint mode and the return-value note. Every clause carries information.

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

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

An output schema exists, so the description need not explain return values (though it does). The real gap is on the input side: with 4 parameters, nested required directive keys, and 25% schema coverage, two boolean switches remain completely unspecified, leaving an agent guessing how to configure mixed-content and insecure-request handling.

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

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

Schema description coverage is only 25%: only the `policy` parameter carries a schema description, and the two booleans (`blockAllMixedContent`, `upgradeInsecureRequests`) are undocumented everywhere. The description gestures at "directives" and linting a "policy" but adds no meaning for the boolean flags or the required directive keys, so it fails to compensate for the coverage 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?

The description gives a specific verb+resource ("Build a Content-Security-Policy") and explicitly covers the second mode ("or lint an existing policy"), which separates it cleanly from sibling builders like build_json_ld or build_open_graph. An agent can identify the tool's domain and dual mode without opening the schema.

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

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

The two operating modes are named, so usage is implied: supply directives to generate, or supply a policy to lint. However, it never states which mode takes precedence, what prerequisites exist, or when an agent should prefer this over a manual check_http_headers-style tool. Guidance is present but inferential.

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/openWorldHint=false, so the safety profile is covered. The description usefully adds that the call does no page fetching and returns three artifacts including a missing-fields list, which tells the agent to expect partial output rather than a validation error.

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

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

Three short sentences, zero filler, with the output contract stated first and the usage caveat second. Every sentence earns its place.

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

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

An output schema exists so return values need not be explained, and annotations cover the safety profile. For a two-parameter, read-only builder the description supplies everything an agent needs: what it produces, when to use it, and that it performs no fetching.

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 50%: the enum on `type` is self-documenting and `values` carries a schema description about repeatable fields being arrays. The description adds nothing about parameter shape, formats, or how `values` keys must match the chosen type, so it neither compensates nor regresses. 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: builds schema.org JSON-LD for a single type, and it names its outputs (script tag, missing-fields list). An agent can distinguish it from conversion siblings like build_open_graph, though the description never explicitly contrasts with the closest neighbour. Clear, but not maximally differentiated.

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?

"Use this when you already know the fields" gives a real selection condition, and "It does not fetch a page" excludes the fetch-based siblings (fetch_page_markdown, inspect_meta_tags) by implication. It stops short of naming the alternative tool an agent should use when it does not already know the fields.

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 and idempotentHint, so the agent knows this is a pure, repeatable generation with no side effects. The description adds that defaults target a 'pnpm standalone image', which is useful context, but it doesn't disclose what happens if the flags conflict (e.g. migrate without prisma) or how the multiple artifacts are 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?

Two tight sentences, artifact list front-loaded, no filler. Every clause carries 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?

Output format is covered by the output schema and the safety profile by annotations, so those needn't be restated. However, for a tool exposing 13 undocumented configuration parameters, the description is thin and leaves most option semantics to inference.

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

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

With 0% schema coverage across 13 parameters, the description carries the full burden but only hints at two defaults (packageManager=pnpm, standalone=true). It says nothing about base, node, port, turbo, prisma, migrate, healthPath, publicEnvs, cacheMounts, healthcheck, or telemetryDisabled.

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 (Generate) and enumerates the exact artifacts produced: Dockerfile, dockerignore, compose file, and next.config snippet. No sibling tool overlaps this domain, so the tool is easily identifiable.

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 scoping is 'for a Next.js app'. There is no statement of when to reach for this versus hand-writing a Dockerfile, no mention of prerequisites (existing package.json, pnpm lockfile), and no when-not guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds only that images are optional and that output is a PNG plus a Next.js file; it does not explain rendering failures, size/weight limits, or what happens with fields not used by the chosen template.

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, front-loaded with the action and outputs, then the required inputs. No filler or restated boilerplate.

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

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

An output schema exists, so return values need not be described. However, for a 33-parameter, 18-template tool with zero required parameters, the description gives no sense of which fields belong to which template, forcing the agent to guess or re-query list_og_templates.

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

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

Schema coverage is only 30% across 33 parameters, but the description does group them conceptually (template-specific fields, colors, size, optional base64 images) and notes that only 'the fields that template uses' matter, which is real semantic guidance. It stops short of enumerating the many text fields (quote, steps, versions, before/after values) that are undocumented in 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 (render Open Graph templates) plus both output artifacts (PNG and opengraph-image.tsx). It also ties itself to the sibling list_og_templates for template ids, so an agent can distinguish it from build_json_ld and list_og_templates at a glance.

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

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

It establishes a clear workflow precondition: get the template id from list_og_templates, then pass the fields that template uses. There is no explicit when-not-to-use or exclusion, but the routing to the sibling is concrete and useful.

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

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

The annotations already declare read-only, idempotent, and closed-world behavior, so the safety profile is covered. The description adds useful semantic detail by stating which values are computed and which optional transformations are available.

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, front-loaded with the core return values and followed by optional operations. There is no redundant or wasted text.

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

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

The description is complete for a pure calculation tool whose output schema details the return shape and whose annotations define the safety profile. Nothing needed to invoke the 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 coverage is 100%, so the schema already documents cidr, merge, contains, and splitPrefix. The description maps loosely to contains, splitPrefix, and merge, but adds no format or syntax detail beyond the schema, making the baseline of 3 appropriate.

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

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

The description states a specific verb and resource: return network, broadcast, host range, and host count for an IPv4 or IPv6 CIDR. It also names optional operations, so an agent can clearly distinguish this from unrelated calculator siblings like calculate_emi or calculate_percentage.

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

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

It clearly indicates the optional modes: test membership, split, or merge. There are no alternative tools to route between and no exclusions, but the context for when to use those optional parameters is explicit enough.

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, and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: half-up rounding to cents and the fact that extraMonthly reduces principal, which materially affects results. It stops short of explaining how the amortization schedule is shaped, but the output schema carries that.

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 sentences with the core purpose front-loaded, then rounding semantics, then the optional parameter's effect. No filler or restatement of the title.

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

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

With an output schema present, the description needn't explain return values, and annotations cover safety; the remaining essentials (purpose, rounding, extra payment) are stated. Minor gap: no stated rate/term assumptions or error behavior, but nothing critical is missing 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 100%, so all four parameters are already documented, giving a baseline of 3. The description tangentially reinforces extraMonthly's effect on principal but adds no syntax or unit detail beyond the schema's own descriptions.

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 (Calculate) plus resource (reducing-balance loan installment and amortization schedule), which is far more precise than the generic 'calculate' siblings like calculate_percentage. An agent can immediately tell what the tool produces 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 by the specialized domain (loan EMI), and no sibling overlaps meaningfully, but there is no explicit when-to-use or when-not-to-use guidance. The description never states assumptions such as fixed-rate or that it is not a general percentage calculator.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that – no note on rounding/precision, how string inputs are parsed, or error behavior for incompatible mode/value combinations. The one useful addition is the margin-vs-markup distinction.

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

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

A single front-loaded sentence led by the verb, with no filler or repetition of the title. It is a dense enumeration, but every clause maps to a real mode, so nothing 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?

An output schema exists and the input schema is fully documented, so return-format explanation is not needed. With annotations covering safety and the enum covering modes, the definition is nearly self-sufficient; only precision/error-handling behavior is left 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 100%, including role assignment for a and b per mode, so the schema already carries the semantics. The description's re-listing of the modes largely duplicates the enum rather than adding meaning (e.g., it never clarifies the argument order for 'reverse' or how 'margin' consumes a and b). Baseline 3.

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

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

States a concrete verb ('Calculate') plus the resource (percentage) and enumerates the exact computation modes offered, which cleanly separates it from the other calculators in the sibling list (calculate_cidr, calculate_emi, calculate_programmer). An agent can identify the tool's domain without opening the schema.

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

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

The mode list implies which scenario each variant covers ('what percent one number is of another', 'percent change', 'margin versus markup'), giving some usage signal. But there is no explicit when-to-use/when-not statement and no routing to alternatives such as convert_units or calculate_programmer.

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 openWorldHint=false, so the safety profile is covered. The description adds real behavioral context (C-like operator precedence, literal formats, masking and signed/unsigned interpretation), but with an output schema present the 'reports base conversions' sentence largely restates the return contract rather than disclosing new behavior.

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

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

A single dense sentence with zero filler, front-loading the evaluation semantics and the literal formats an agent needs to construct a valid input.

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

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

With an output schema present, return values need not be explained, and the annotations cover the safety profile; the description supplies the operator-precedence and literal-format context that the schema cannot. The one gap is that the dual input mode (expression vs a/b/op) is left entirely to the schema.

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

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

Schema description coverage is 100% and every parameter carries its own description and example, so the baseline is 3. The description adds no parameter-level meaning: it never clarifies that op/a/b are an alternative to expression, nor what 'bits' masking does beyond what the schema already says.

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 (evaluate) and a well-scoped resource (integer expressions with C-like precedence, hex/octal/binary literals, bitwise ops), which cleanly separates it from calculate_cidr, calculate_percentage and calculate_emi. It never names a sibling explicitly, so the differentiation is by domain rather than by direct contrast.

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: 'evaluate integer expressions' and 'report base conversions plus signed/unsigned interpretations' tells the agent what it gets, but not when to pick this over e.g. convert_units or calculate_percentage. No exclusions, prerequisites, or note that the tool supports two alternative input modes (expression vs a/b/op).

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, openWorldHint, and idempotentHint, but the description adds meaningful behavioral context beyond them: it follows redirects, grades specific headers, refuses private addresses, and states the body is not stored. The privacy note about the body not being stored is especially valuable and not covered by annotations.

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

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

Three short sentences, front-loaded with the core action and constraints. Every sentence earns its place with no redundancy or filler.

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

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

For a simple one-parameter tool with 100% schema description coverage and an existing output schema, the description provides everything an agent needs: purpose, behavior, constraints, and privacy handling. Nothing essential 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 schema itself already documents the only parameter, including that private addresses are refused. The description repeats 'Public http or https URL' and the private-address restriction without adding new syntax or format details, 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?

The description states a specific verb+resource: fetch a public URL, follow redirects, and grade five named security headers. This clearly distinguishes it from siblings like check_ssl and check_robots_txt, which target different resources. An agent can identify the exact operation 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?

It provides clear context ('Fetch a public URL') and an explicit when-not condition ('Private addresses are refused'). However, it does not name alternative tools or explain when to prefer this over check_ssl or inspect_meta_tags, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds useful context: it operates on *public* URLs (implying a live network fetch and no auth), and it discloses the two specific checks performed rather than just saying 'check'. No rate-limit or failure-mode detail is given.

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

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

Two tight sentences that front-load the operation and immediately follow with the usage condition. Every clause earns its place with no padding.

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

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

With an output schema present, return-value detail is unnecessary, and the description still names the two reported facts. Combined with annotations covering the safety profile, an agent has enough to call it correctly; only edge-case behavior (e.g., missing/404 robots.txt) is unaddressed.

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 url parameter is fully documented, including the page-URL-to-/robots.txt resolution behavior. The description's URL guidance largely restates the schema, so it adds little beyond the baseline.

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 (fetch) and resource (public robots.txt) and specifies exactly what it reports: whether the wildcard group blocks the site and whether Sitemap lines are absolute. This is more precise than most siblings, though it does not explicitly contrast itself with adjacent tools like validate_sitemap or check_http_headers.

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

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

Gives a clear when-to-use condition ('when you have a URL') and a when-not exclusion ('not a pasted file'), which steers input format correctly. It stops short of naming an alternative sibling tool, so it isn't a full 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), but the description adds real operational context: private addresses are refused and the handshake times out after 8 seconds. That timeout and the refusal rule are things an agent cannot infer from the schema or annotations, though no rate-limit or redirect/TLS-version caveats are disclosed.

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

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

Three short sentences, each load-bearing: the first gives action and outputs, the second and third give hard constraints. No preamble or restated title 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 an output schema present, return-value documentation is not required, yet the description still names the reported fields. Combined with the timeout and address rules, an agent has everything needed to call it correctly and predict failures.

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% for the single 'host' parameter, so the schema already documents that only port 443 is contacted and private addresses are refused. The description largely restates that constraint rather than adding new semantics such as accepted URL forms or IPv6 handling, 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?

Specific verb plus resource: 'Connect to a public host on port 443 and report certificate expiry, subject alternative names, protocol, and chain.' It enumerates exactly what is returned, which cleanly separates it from network-adjacent siblings like lookup_dns and check_http_headers without needing to name them.

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

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

Usage is implied by the scope constraints (public host, port 443 only, private addresses refused), which tells the agent when the tool will fail. However, it never explicitly says when to choose this over lookup_dns or check_http_headers, and gives no exclusions beyond the address 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 readOnlyHint, idempotentHint and openWorldHint, so safety is partly covered. The description adds genuinely useful behavior beyond them: private/local addresses are refused (SSRF guard), decoded input is capped at 10 MB, and the result is returned as base64. It does not mention rate limits or what happens to non-image input, but the additions are substantive.

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

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

Four short sentences, each carrying distinct information (operation, inputs, limits, return). Constraints and inputs are front-loaded 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 an output schema present, return values need not be described, yet the description still notes the base64 return. Inputs and size/SSRF limits are covered, so an agent can call it correctly; the only gap is the unexplained output-format enum.

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

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

Schema coverage is only 50%, and the description compensates for the undocumented 'quality' parameter by stating the 1-100 range (the schema gives it no description). However, the 'choice' enum (original/jpeg/png/webp/avif) is never explained, leaving the output-format parameter uninterpreted in both places. A 3 reflects 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 and resource (re-encode/compress an image) plus scope details: quality range and optional longest-edge capping. It separates itself somewhat from resize_image and convert_image by emphasizing re-encoding at a quality level, but never names or contrasts those siblings 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?

Gives input guidance ('Send base64 or a public URL') and constraints, but never says when to reach for this over resize_image, convert_image, or optimize_svg. Usage is implied by the tool's function rather than routed against alternatives.

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 and openWorld, and the description goes beyond them usefully: "Private addresses are refused" discloses an SSRF guard, "An optional target size tries harder" explains a behavioral tradeoff, and it states the return payload. It omits failure behavior when the target cannot be met.

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?

Five short, front-loaded sentences with no filler; the core action leads, input/security/behavior notes follow. Every sentence carries 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?

Given a 6-param PDF tool with an output schema, the description covers input methods, presets, the private-address guard, target sizing, and return contents. It could still clarify what each preset actually trades off, but nothing essential to invoking it 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 only 50%, and the description compensates: it names the preset values (light/medium/strong, which the enum leaves undescribed) and explains that targetBytes is an opt-in effort ceiling, adding meaning beyond the schema's terse "Optional size ceiling in bytes." filename and mimeType remain unexplained.

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?

"Recompress embedded images in a PDF" is a specific verb+resource that clearly separates it from compress_image and the other PDF siblings by operating on the PDF itself. It does not explicitly name alternatives or scope boundaries, but the resource framing makes the intent unambiguous.

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

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

The description supplies operating context (presets, base64-or-URL input, an optional target size) but never states when to pick this over compress_image, resample elsewhere, or which preset to prefer for a given goal. Usage is implied rather than guided.

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 closed-world behavior, so the safety profile needs no restating. The description adds one behavioral fact — the default of returning every style when none is requested — but that fact is already duplicated in the schema's 'style' description, so the net new information is limited.

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, zero filler, with the capability set front-loaded and the default behavior stated last. Nothing needs to be trimmed.

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 a full output schema present, return values need no explanation, and the description covers purpose and default behavior adequately. A minor gap remains: it never notes the per-line conversion semantics (only present in the schema) or the 100k length cap, though those are documented elsewhere.

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

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

Schema description coverage is 100%, so the baseline is 3. The description names only 6 of the 16 enum values (omitting lower, upper, sentence, capital, pascal, dot, path, train, alternating, inverse) and adds no format or edge-case semantics beyond what the schema already documents for text and style.

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 (Convert) and resource (text) plus concrete output styles (camelCase, snake_case, kebab-case, CONSTANT_CASE, AP/Chicago title case), which is far more informative than the title alone. An agent can distinguish this from neighbors like convert_units, convert_data_format, or convert_color at a glance.

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

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

The description implies usage via 'Returns every style unless one is requested', which tells the agent that omitting 'style' is a valid call. However, it gives no guidance on when to prefer a single style, what to do for mixed/ambiguous input, or when a sibling tool (e.g. format_json) would be more appropriate. Usage is only implied, 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 declare readOnlyHint, idempotentHint, and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: it performs three distinct operations (multi-format conversion, Tailwind token lookup, WCAG 2 contrast computation) and notes the contrast is measured against a background, which is not obvious from annotations alone.

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

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

A single front-loaded sentence with zero filler; every clause names a capability (conversion, token naming, contrast) without redundancy.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description is complete for a simple two-parameter tool; the only minor gap is the absence of usage routing against siblings.

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 both parameters and their accepted formats. The description only vaguely gestures at the background parameter ('against a background') without adding format 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 (convert) and resource (color), and enumerates the input formats (HEX, RGB, HSL, OKLCH, CMYK) plus two additional capabilities (Tailwind token naming, WCAG contrast). This clearly distinguishes it from near-neighbors like convert_units and convert_case.

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 strongly implies the use case, but there is no explicit when-to-use/when-not-to guidance and no mention of alternatives such as convert_units for non-color conversions. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly/openWorld/idempotent, so the bar for adding context is lower. The description clears it by disclosing real behavioral traits beyond the annotations: supported delimiters, type inference, dotted flattening, and notably that inferred numbers too large for a JavaScript number retain their digits (precision handling). Missing edge-case detail on malformed input is a minor 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?

Three tight sentences, front-loaded with the primary action, then supported options, then a precision caveat. No wasted words; each sentence earns its place.

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

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

With an output schema present, return values need not be explained, and annotations carry the safety profile. The description is nearly complete for calling correctly, though it omits the schema's note that 'auto' delimiter resolves to comma when writing CSV and gives no guidance versus the convertible sibling 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 coverage is only 50%, but the description compensates by naming delimiters, optional header, type inference, and dotted flattening, which map onto the delimiter/header/inferTypes/flatten parameters and effectively cover most fields. The direction parameter is implied by 'CSV to JSON or JSON to CSV'. It adds meaning beyond the schema for the un-covered fields.

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 (convert CSV↔JSON) and even disambiguates both directions, so the core purpose is unambiguous. It does not, however, differentiate itself from the overlapping sibling convert_data_format, which likely covers format conversion too.

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

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

No when-to-use, when-not-to-use, or alternative mentions. Notably the sibling convert_data_format is left unaddressed, so an agent has no guidance on which converter to pick. The description explains capabilities but not selection context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds nothing behavioral on top of the name/title — no note on invalid-command handling, input size limits, or which curl features are unsupported.

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

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

A single front-loaded sentence with the action, input, and outputs. Zero waste, nothing to trim.

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

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

For a simple two-parameter converter with an output schema present, the description is close to sufficient: it says what is converted and to which languages. Minor gaps remain around edge cases and unsupported curl constructs, but nothing essential to calling it 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 0%, so the description carries some burden. It names all five target languages matching the enum, which helps confirm the 'target' parameter's meaning, and 'command' is transparently the curl string. However, it adds no syntax, format, or size-limit (20000 chars) detail beyond the schema.

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

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

States a specific verb ('Parse') and resource ('a curl command') with the concrete output forms ('JavaScript fetch, Python requests, Go, PHP, or Rust code'). This clearly distinguishes it from generic siblings like convert_data_format or analyze_har.

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

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

The purpose implies when to use it (translating a curl command into code), but there is no explicit when/when-not guidance and no mention of sibling alternatives such as analyze_har or convert_data_format. Adequate but not instructive.

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 openWorldHint, so the safety profile is covered. The description adds genuine context beyond that: rates come live from the Frankfurter API and pass through an SSRF-safe outbound guard, which is useful for understanding latency and external dependency. It omits failure modes for invalid currency codes, which keeps it short of a 5.

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

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

Two front-loaded sentences with no filler; the core operation leads and supporting detail follows. The mention of the SSRF-safe outbound guard is slightly implementation-flavored but still informative and brief.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description covers the source of rates and the historical-date capability, which is nearly everything an agent needs; only error behavior for unknown currency codes is unaddressed.

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 75% and all four parameters are constrained (ISO codes with min/max length, date regex, amount bounds). The description's 'ISO 4217 currencies' and 'historical dates' restate what the schema already says, adding no format or interpretation detail. 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 (Convert) and resource (money between ISO 4217 currencies), which cleanly separates it from convert_units, convert_color, and convert_data_format. The rate source is named, so an agent knows exactly what operation it is getting.

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

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

No statement of when to prefer this tool over neighbors such as convert_units, and no exclusions or prerequisites. 'Supports historical dates' hints at a use case but does not frame selection between alternatives.

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/closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond them: large numbers preserve digits, errors carry line and column, and TOML rejects null and non-table roots. These are real gotchas an agent would otherwise discover only by hitting them.

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

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

Four short sentences, format scope front-loaded, each one carrying distinct information (scope, detection, numeric precision, error shape, TOML constraint). No filler or restatement of the title.

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

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

With an output schema present, return values need not be described, and the description covers inputs, detection, and error/edge behavior. Minor gap: no mention of any size limits or hints on choosing a target format, but 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 only 33% (only `text` is documented), but both `to` and `from` are enums with defaults that the schema already enumerates. The description adds that source detection is automatic, matching the `from: auto` default, and nothing about `to` beyond the format list. Adequate but not compensating for the coverage 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 ("Convert") plus the exact resource formats (JSON, YAML, TOML, XML), which implicitly separates it from siblings like format_json (formatting only) and convert_csv_json (CSV involved). 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?

The description supplies "Auto-detects the source," which hints that the `from` parameter can be left alone, but it never states when to choose this over format_json or validate_json_schema. Usage is implied through the behavior, not explained.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral detail beyond those annotations: private-address refusal, a 10 MB decoded size cap, base64 output, and the HEIC limitation. It does not describe auth or rate-limit behavior, keeping it at 4 rather than 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?

Five short sentences, each carrying a distinct useful fact, with the core action and supported formats front-loaded. There is no repetition, filler, or buried constraint; the operational limits follow immediately.

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

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

Given the annotations, output schema, and 50% schema description coverage, the description covers the essential calling information: input forms, address restriction, size cap, output form, and an important unsupported case. It could still mention the target default and the optional filename/mimeType parameters, but nothing critical for a successful 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 coverage is 50%. The description reinforces that input is base64 or a public URL and lists the target formats, but those details largely mirror the existing schema descriptions and enum values. It adds the HEIC-not-decoded limitation, yet never mentions filename, mimeType, or the target default, so it only partially compensates for the coverage 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?

The description gives a specific verb (Convert) and resource (image), names the supported output formats, and makes clear it handles base64 or public URLs. An agent can distinguish this from sibling image tools like compress_image, resize_image, and crop_image because the stated purpose is format conversion rather than compression or geometric editing.

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

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

The description provides clear operational context: input via base64 or public URL, private addresses refused, 10 MB decoded cap, and HEIC not decoded. It does not explicitly name alternatives for unsupported cases or state when to prefer compress_image or resize_image, so it stops short of full when/when-not/alternative guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds that the tool infers types and produces code, but says nothing about how the source JSON is treated (sample vs. full document), size limits, or behavior on malformed input, so it adds only modest context beyond annotations.

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

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

A single front-loaded sentence with zero filler; the core verb and the deliverable outputs are stated immediately and nothing is repeated from the schema or title.

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

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

An output schema exists, so return-format explanation is unnecessary, and annotations cover the safety profile. The definition is close to complete for this simple codegen tool; the remaining gap is the undocumented rootName parameter and the absence of any input-validity note for the JSON payload.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. The enumerated output targets do map usefully onto the 'targets' enum, but 'rootName' is never mentioned and the required 'json' parameter's format (a valid JSON document string, capped at 500000 chars) is undocumented in both description and 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+resource (infer types from JSON and generate type definitions) and enumerates the exact outputs: TypeScript interfaces, Zod schemas, Pydantic models/dataclasses, and Go structs. This is easily separable from the many generic convert_* siblings such as convert_data_format and convert_csv_json, which do value transformations rather than code generation.

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 description: you bring a JSON document and receive generated type definitions. However, there is no explicit when-to-use guidance and no routing against nearby siblings (e.g. format_json, validate_json_schema, convert_data_format) that an agent might otherwise consider for JSON work.

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 and openWorld=false, so the safety profile is covered. The description adds that sanitize strips scripts from the output and that no URL is fetched, but it never states whether sanitization applies to HTML→Markdown as well, nor what happens to unsupported Markdown constructs.

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

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

Three short sentences, front-loaded with the primary action. 'to is html or markdown' is telegraphic and slightly awkward, but 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?

An output schema exists, so return values need no explanation, and the safety profile is annotation-covered. Still missing for a 3-parameter tool: any description of the 'text' input and whether sanitize is ignored in the Markdown direction.

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

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

Schema description coverage is 0%, so the description must carry the burden. It explains 'to' (redundant with the enum) and 'sanitize' (genuinely additive beyond the boolean name), but says nothing about 'text' — the core input payload — so coverage is only partial. Partial compensation lands at 3.

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

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

States a specific verb and resource, with both directions named ('Markdown to HTML, or HTML to Markdown'), and adds the scope boundary that it does not fetch a URL, which implicitly separates it from fetch_page_markdown. It stops short of naming any sibling explicitly or differentiating from convert_data_format.

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

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

The direction is selected via 'to is html or markdown', which is usable guidance, and the no-URL-fetch sentence rules out the fetching sibling. There is no explicit when-to-use/when-not statement or named alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety behavior is fully covered structurally. The description adds only the decimal-vs-binary category caveat and says nothing about rounding behavior or how the precision default (6) affects results — useful but thin on top of the annotations.

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

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

Two short sentences, zero filler, with the scope enumeration front-loaded and the disambiguating caveat immediately after. Every clause carries information.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile; the description covers scope and the tricky data-size split. The remaining gap is behavioral detail on precision/rounding, which an agent would need to produce predictable output.

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

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

Schema coverage is only 40%: 'to' and 'from' are documented in the schema, while 'value' (string|number), 'category', and 'precision' are not. The description partially compensates by disambiguating the two data-size categories, which is the highest-risk parameter choice, but it says nothing about precision, rounding, or the accepted value formats.

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 (Convert) plus the resource (units) and enumerates the nine supported categories, which cleanly separates it from look-alike siblings such as convert_data_format, convert_color, and convert_unix_timestamp. It stops short of naming which sibling to prefer for adjacent tasks, so it is clear but not sibling-routing.

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 statement, but the category list implies the applicability surface, and the note that decimal (kB, MB) and binary (KiB, MiB) bytes are separate categories is real selection guidance that prevents a common category mistake. Still, nothing tells the agent how to choose between this tool and e.g. calculate_programmer or convert_data_format.

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=true, idempotentHint=true, closed-world), so the bar is lower. The description usefully adds the output formats and time-zone-aware conversion behavior, but says nothing about how ambiguous epoch values are disambiguated under unit='auto' or how conflicts between 'input' and the calendar fields are resolved, which is the risky part of this tool.

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

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

A single front-loaded sentence that packs the input units, both output formats, time-zone scoping, and the bidirectional capability with zero filler. Nothing can be cut without losing semantic content.

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

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

An output schema exists, so return values need not be described, and annotations handle safety. However, for a 9-parameter tool with 22% schema coverage and a dual input mode, the description omits how to supply calendar input, how the five unit options interact with 'auto', and that 'input' also accepts ISO-8601/RFC 2822/'now' — gaps an agent would hit on first use.

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 22%, so the description carries most of the burden — and it does not. Six numeric calendar parameters (year, month, day, hour, minute, second) and the 'unit' enum are never mapped to meaning, and the crucial mode-selection rule (leave 'input' empty when calendar fields are set) appears only in the schema, not the description. The unit and time-zone mentions largely restate enum/default values already present in 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 (convert) and resource (unix timestamp/epoch) plus the exact accepted units (s, ms, us, ns) and output formats (ISO-8601, RFC 2822). It also declares the reverse direction ('calendar time back to epoch'), which clearly separates it from the sibling date_difference without opening either schema.

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

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

The description implies the two usage modes (epoch input vs. calendar components) so an agent can infer direction, but it never states when to prefer this tool over date_difference or convert_data_format, nor does it explain the 'auto' unit-detection behavior that governs the no-unit case. Usage is implied rather than prescribed.

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 openWorldHint=false, so the safety profile is fully covered. The description does add a genuine behavioral trait beyond the name — the SEO/social limit comparison — but omits the 200,000-character input cap and says nothing about how results are reported.

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

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

A single tight sentence with zero padding, front-loading the enumeration of counted units before the comparison feature. Only minor awkwardness in the trailing clause keeps it from being exemplary.

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

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

An output schema exists, so return values need no explanation, and annotations carry the safety profile. The description covers the tool's capability set adequately; only the input size limit and the count methodology remain 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?

One parameter with 100% schema description coverage, so the schema already documents 'text'. The description adds no syntax, formatting, or edge-case guidance (e.g., how graphemes vs code points are counted) beyond what the schema provides. 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 (count) and enumerates the exact units measured: words, code points, graphemes, sentences, paragraphs, plus an SEO/social limit comparison. This implicitly separates it from the nearest sibling count_tokens, though it never names that alternative 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?

Usage is only implied: the mention of SEO and social limits suggests the use case of validating copy against platform limits, but there is no explicit when-to-use statement, no exclusions, and no pointer to count_tokens for token-based counting.

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 openWorldHint=false, so safety is covered. The description adds genuine value beyond that by disclosing that Claude and Gemini rows are estimates rather than those vendors' real tokenizers — an important accuracy caveat an agent needs when reporting numbers.

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

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

Two sentences, no waste, and the core capability plus the encoder choice are front-loaded. The caveat sentence is short and earns its place by preventing a misread of the estimate rows.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The remaining gap is the cost-modeling parameters (cachedRatio, outputTokens, requestsPerDay), which an agent cannot interpret from either the description or the schema.

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

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

Schema coverage is only 33%, so the description must compensate, and it partially does: 'o200k or cl100k encoder' explains encoding, and 'published model table' explains modelIds. However, cachedRatio, outputTokens, and requestsPerDay — the parameters that shape the cost model — are left entirely unexplained in both description and 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 verb+resource ('Count tokens') and adds scope the siblings lack: the o200k/cl100k encoder choice and pricing against a model table. This implicitly separates it from count_text (character/word counting), though it never names that sibling explicitly, keeping it just 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 when-to-use or when-not-to-use guidance, and no alternative tool is mentioned despite count_text being a plausible competitor for text-length tasks. The accuracy caveat about Claude/Gemini rows is a limitation note, not routing guidance.

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

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

The annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower, and the description still adds real operational context: private/local addresses are refused, the decoded file is capped at 10 MB, and the result is returned as base64. Those limits and the output encoding are not derivable from the annotations and directly affect how an agent prepares the call.

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

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

Six short, information-dense sentences, front-loaded with the core action and then limits and output, with almost no filler. There is some duplication of what the schema enum fields already say about px/ratio and format, which keeps it from being maximally tight.

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

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

With an output schema present, the description need not explain return structure, yet it still flags the base64 return. It covers both input modes and the size/address restrictions, leaving only the coordinate fields (x/y/width/height) under-explained for an 8-parameter tool.

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

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

Schema description coverage is only 25%, so the description needs to compensate, and it does for file (base64 or public URL), unit (px vs ratio, restated), circle, and format. However x, y, width, and height have no schema descriptions and no explanation in the description — the default of 1 for both width and height is especially ambiguous — so the compensating coverage is partial.

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

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

The description states a specific verb and resource ('Crop an image') and scopes it ('to a pixel box or a 0 to 1 ratio box'), which is enough to separate it from convert_image or resize_image without opening a schema. It stops short of explicitly naming which sibling handles the non-cropping cases, so it is clear but not sibling-differentiated.

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 description mentions the px vs ratio choice, the circle mask, and the format options, which hints at the decisions a caller makes. There is no when-to-use-this-vs-an-alternative guidance and no statement of prerequisites or exclusions beyond the input-source restrictions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered. The description adds genuine semantic behavior: business days exclude weekends and user-listed holidays, clarifying what the calculation actually does beyond the safety profile.

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

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

Two sentences with zero filler, and the primary operation is front-loaded ahead of the business-day qualification. Every clause carries information.

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

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

An output schema exists so return values need no explanation, and annotations carry the safety profile. The description is complete for calling the tool correctly; only minor edge-case semantics (e.g. includeEnd interaction) are left to the schema.

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

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

Schema description coverage is 100%, so the schema already documents startDate, endDate, startTime, endTime, holidays and includeEnd with formats and defaults. The description restates the holidays format already present in the schema and adds nothing new, 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 (count) applied to a specific resource (calendar days, elapsed time, business days between two dates), and even enumerates the three distinct counting modes. There is no sibling tool doing date arithmetic, so no differentiation is needed and the purpose is fully self-evident.

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

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

The description implies when the business-day mode is useful ('skip weekends and any holidays you list') but gives no explicit when-to-use guidance or exclusion criteria. With no competing sibling for date math, implied usage is the realistic ceiling here.

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, and non-open-world, so the safety profile is covered. The description adds meaningful context beyond that: that signature verification is NOT performed and that dates are rendered as absolute ISO timestamps – both are non-obvious behavioral facts.

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

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

Two tight sentences, front-loaded with the core action and followed by the two most decision-relevant caveats (timestamp format, unverified signature). 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?

For a single-parameter read-only utility with an output schema and full annotation coverage, the description covers purpose, output shape, and the key security caveat. Only explicit routing/usage guidance 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% for the single token parameter, and the schema itself documents the optional Bearer prefix. The description adds no parameter-specific 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 (Decode) and resource (a signed JSON Web Token), and enumerates what the agent gets back: header, payload, and registered claims. Since no sibling tool decodes JWTs, this is unambiguously distinguishable.

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 'signature is not checked' caveat implicitly steers the agent away from using this for verification, but there is no explicit when-to-use or alternative named (e.g., where to verify a signature). Usage is only implied.

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

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

Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint, so the safety profile is covered. The description adds that output format varies by mode (inline diff, side-by-side rows, unified patch), which is useful context, but with an output schema present this is somewhat redundant and no auth/rate-limit/permission behavior is discussed.

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

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

Two tight sentences with no filler: the first states what is compared and the available modes, the second states what is returned. It is front-loaded and every clause carries information.

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

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

An output schema exists, so return shapes need not be described, and the description still usefully notes the mode-dependent formats. The main gap is the undocumented ignoreWhitespace parameter; otherwise it is adequate for a four-parameter, read-only comparison 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 coverage is 50% (left and right are described; mode and ignoreWhitespace are not). The description partially compensates by naming the mode values and explaining JSON mode's key-order insensitivity, but ignoreWhitespace is left completely undocumented in both schema and description.

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

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

States a specific verb (Compare) and resource (two texts) plus the supported granularities (line, word, character, JSON). No sibling tool is a diff tool, so an agent can identify this one unambiguously from the tool list.

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: it lists modes and gives one selection hint for JSON mode ('so object key order does not matter'). There is no explicit when-to-use, when-not-to-use, or prerequisite guidance, leaving mode choice mostly 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 readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds genuine value beyond that: the SSRF-style refusal of local/private/internal addresses and the note that it returns 'response data or errors', which is not derivable from the annotations. It still omits auth handling and timeout behavior.

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

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

Two tight sentences with the core action first and the security boundary second. Every clause earns its place; there is no filler or repetition of the name/title.

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

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

An output schema exists, so return-value detail is not required, and the description still briefly signals data-or-errors. For a 5-parameter tool with nested objects and no schema descriptions, it is mostly complete for invocation, with timeoutMs and header/auth conventions being the notable omissions.

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

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

Schema description coverage is 0%, so the description carries the whole burden. It flags variables and headers as optional and constrains the endpoint to public http/https on 80/443, but timeoutMs (default 15000, range 1000-60000) is entirely undocumented and no format or default hints are given for the others. Partial compensation only.

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 (Send) and resource (a GraphQL query) and pinpoints the target scope (public http/https endpoint on port 80/443). No sibling tool performs GraphQL requests, so the agent can identify it immediately without opening the schema.

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

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

The description establishes the operational boundary ('public http or https endpoint on port 80 or 443') and an explicit exclusion ('Local, private, and internal addresses are refused'), which implies when it can be used. However, it never names alternatives or states when to prefer this over a sibling like fetch_page_markdown for non-GraphQL HTTP work, leaving routing 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 establish readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description usefully adds that setuid, setgid, and the sticky bit are handled, but says nothing about invalid-input handling or the effect of the path parameter, so it clears the annotation-lowered bar only modestly.

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

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

A single front-loaded sentence that names the input, the outputs, and the special-bit coverage with zero filler. Every clause earns its place.

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

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

With an output schema present, the description needn't explain return values, and annotations cover the safety profile, so the core is complete. The one gap is the undocumented path parameter and any note on malformed-mode behavior, which is minor for this simple converter.

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%: the mode parameter is documented in the schema (and its octal/symbolic forms are merely restated in the description), while the path parameter has only a default of 'file' and no description anywhere. The description adds no syntax or format detail beyond what the schema already provides, so the baseline 3 fits.

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 gives a specific verb (Convert) plus the exact resource (an octal or symbolic file mode) and enumerates the output forms (octal, symbolic notation, chmod command). This distinguishes it cleanly from the similarly-named explain_cron sibling, which operates on a different resource.

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

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

The description implies its own use case by naming the input and output forms, but it never states when to reach for this tool versus an alternative, nor any exclusions or prerequisites. An agent gets no routing guidance.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the useful fact that output spans multiple target formats, but says nothing about how invalid or ambiguous expressions are handled, which is the main behavioral question for a parser.

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

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

A single front-loaded sentence with the action first and the output list second. No filler, no redundancy, appropriately sized for a read-only utility.

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

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

An output schema exists, so return values need not be explained, and the annotation set fully covers safety for this read-only tool. The remaining shortfall is the undocumented dialect parameter and the absence of any note on error handling for malformed expressions.

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

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

The description says nothing about the four parameters; all meaning comes from the schema, which documents expression, now, and timeZone (75% coverage). The dialect enum has no description in either place, so the description leaves that ambiguity unaddressed rather than compensating.

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 precise verb-and-resource ('Turn a cron expression into English') and enumerates the concrete artifacts produced: next UTC run times plus snippets for crontab, GitHub Actions, Vercel, Kubernetes, and node-cron. No sibling tool covers cron parsing, so the agent can route unambiguously from the name alone.

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

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

The purpose implies when to use it (you have a cron expression and want it explained), but there is no explicit when/when-not guidance, no statement about invalid-expression behavior, and no named alternative. No sibling competes, so the omission is low-risk but still a gap.

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 and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: no OCR fallback, SSRF-style refusal of private/local addresses, and the shape of the return (per-page text, headings, token count).

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

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

Four short sentences, front-loaded with the core action, then return shape, then input method, then the constraint. Every sentence carries distinct information with no padding.

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

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

An output schema exists, so the return description is a bonus rather than a necessity, and the safety profile is in annotations. The only real gap is the two undocumented parameters (filename, mimeType); otherwise an agent has everything needed to call it.

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%: url and data are documented in the schema, while filename and mimeType are undocumented in both places. The description reinforces the either/or input choice and repeats the private-address rule, 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?

States a specific verb and resource ('Read the selectable text layer of a PDF') with a scope qualifier that separates it from OCR-based readers. It effectively distinguishes itself from sibling read_image_text via 'Does not OCR scans', though it never names a sibling outright.

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 when-not guidance ('Does not OCR scans') and input routing ('Send base64 or a public URL'), plus the constraint that private addresses are refused. No alternative tool is named for scanned documents, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds genuinely useful behavior the annotations do not: it refuses private/local addresses and caps the response at 800 KB. It does not disclose rate limits or that the page is fetched without JS rendering, but the added constraints are real value beyond structured fields.

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

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

Three short sentences, zero waste, with the core action and return shape front-loaded and the two limits (address restriction, size cap) following. Every sentence carries independent 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 an output schema present, the description needn't detail return values, and annotations cover the safety profile; the description fills the remaining gaps (address policy, size cap). Only minor omissions remain, such as whether JavaScript-rendered content is fetched or how failures are reported.

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?

There is a single parameter with 100% schema description coverage, and the schema already states 'Public http or https URL. Private and local addresses are refused.' The description repeats that same constraint rather than adding format, redirect, or query-string semantics, 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 (fetch) and resource (a public HTML page), plus the exact transformation (article to Markdown) and the accompanying outputs (title, excerpt, token count). This is clearly distinct from siblings like check_http_headers or validate_sitemap, which inspect rather than extract content.

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?

Scope is implied by 'public HTML page' and by the private/local refusal constraint, so an agent can infer when this applies. However, there is no explicit when-to-use statement, no mention of alternatives (e.g. extract_pdf_text for PDFs, check_robots_txt for crawl policy), and no prerequisites named.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety and purity profile is largely covered. The description usefully clarifies that filling targets named form fields and that flattening is optional, but says nothing about what happens to unfilled fields, existing values, or how failures (e.g., a non-interactive PDF, a refused private URL) surface.

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

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

Two tight sentences with no filler. The core action and supported field types lead, and the optional behaviors (flatten, inspectOnly) follow in the order an agent would need them.

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

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

An output schema exists, so return values need no explanation, and all four parameters are named in prose. What remains thin is failure behavior and the semantics of partial fills, which matters for a form-filling tool but is not essential to selecting or invoking it.

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, values, flatten and inspectOnly in detail, including the 10 MB cap and checkbox/radio value rules. The description only mirrors those points at a high level and adds no syntax or format detail the schema lacks.

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 (fill) on a specific resource (an interactive PDF form) and enumerates the field types it handles: text fields, checkboxes, dropdowns, radios. This cleanly separates it from the other PDF siblings (extract_pdf_text, sign_pdf, flatten-style tools) without the agent needing to open a 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?

Recommendations the workflow order explicitly: 'Pass inspectOnly to list the fields first,' which tells the agent how to discover field names before filling. It does not name any when-not conditions or alternatives (e.g., for non-interactive PDFs the agent should use another tool), so it stops short of the top band.

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

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

Annotations already declare readOnly, idempotent, and non-open-world, so safety is covered. The description adds genuinely useful behavior beyond that: big integers keep their original digits (a real precision guarantee), and invalid input returns line/column per syntax error, which tells the agent exactly how failures surface.

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 sentences, zero filler, and the primary action is front-loaded in sentence one. Each remaining sentence adds a distinct fact (number precision, success/failure return shape) rather than padding.

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

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

An output schema exists, so the description needn't detail return values, and the annotations carry the safety profile. What it adds (precision guarantee, error positions) makes the tool usable, though it omits which sibling to choose for schema validation versus raw formatting.

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

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

Schema description coverage is only 50%: 'json' and 'sortKeys' are documented, while 'indent' (enum with no description) and 'minify' (boolean with no description) are not. The description partially compensates by contrasting pretty-print with minify and clarifying that the input's numeric digits are preserved, but it says nothing about indent values or key-sorting behavior.

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 pair (pretty-print/minify) and resource (JSON), which is distinct from most siblings. However, it never names close alternatives like minify_code or validate_json_schema, and the added 'or validate' framing overlaps with validate_json_schema's territory, so the agent gets no explicit sibling differentiation.

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

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

Usage is implied by the action ('pretty-print or minify JSON') and by noting that invalid input yields error positions, so an agent can infer this is the tool for formatting/validating raw JSON text. There is no explicit when-to-use versus alternatives such as validate_json_schema, convert_json_to_types, or minify_code.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the supported dialect range but says nothing about behavior beyond the options, such as how unsupported syntax is handled or error output. Adequate but thin against an already-annotated tool.

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

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

Two tight sentences with the primary purpose front-loaded and no filler. It is efficient, though the second sentence reads as option listing rather than routing guidance.

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

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

An output schema exists so return values need not be explained, and the description covers the tool's scope and main options. Given the low schema coverage, a bit more detail on the dialect and keywordCase enums would make it 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 only 25% (only 'sql' is documented), so the description must compensate. It partially does by explaining keyword case, indent values (2 or 4 spaces), and dialects, but it omits the full dialect enum, the keywordCase enum values, and defaults, leaving real gaps.

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

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

States a specific verb (Format) and resource (SQL) and names several concrete dialects, which distinguishes it from the JSON/code formatters among siblings. It does not explicitly contrast with format_json or minify_code, but the SQL-specific framing is unambiguous.

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

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

The second sentence only describes configurable options (keyword case, indent), not when to use this tool versus alternatives or any prerequisites. There is no when/when-not guidance; usage is merely implied by the tool's name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so a safe, deterministic, offline operation is established. The description's word 'seeded' usefully reinforces determinism, but it never explains how seed, count, and rows interact or what bounds constrain output. With annotations covering the safety profile, this is a modest but real addition.

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