Agent Utilities Hosted

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the audit uses five fixed (non-configurable) heuristics, runs free with no key/credits/wallet, and is subject to existing source and input limits.

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

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

Three short sentences, front-loaded with the action and method, then pricing, then constraints. Efficient, though 'Existing source and input limits apply' is boilerplate that carries little actionable meaning.

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 annotations covering safety and an output schema present, the description needn't explain returns. It is minimally complete, but leaves two gaps an agent would care about: what the five heuristics detect and how this differs from the adjacent agent-config checkers.

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 67%, and the two legacy fields (requestId, maxPriceMicroUsd) are already documented as ignored in free mode. The description's only parameter-relevant line, 'Existing source and input limits apply', vaguely gestures at the text maxLength without adding format or syntax detail, so it stays at 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?

The description states a specific verb+resource ('Review agent configuration text') and the method ('five fixed risk heuristics'), so an agent can tell it audits config text rather than fetching or parsing it. It does not, however, distinguish itself from close siblings like agents_env_template_check or agents_tool_name_conflicts, which also target agent configuration.

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 guidance, no prerequisites beyond 'input limits apply', and no routing to alternatives among the many agent_* siblings. The 'FREE during validation' note is a pricing fact, not a selection condition.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond annotations: it returns name comparisons but not values (a privacy property), and it is free with no key/credits/wallet. It does not disclose pagination or size-limit behavior, keeping it below a 5.

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

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

Four short clauses, front-loaded with the core comparison and the values-not-returned guarantee. 'Existing source and input limits apply' is vague filler, slightly diluting an otherwise tight statement.

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

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

An output schema exists, so return-shape explanation is unnecessary, and the description covers the privacy guarantee, cost, and legacy-field implications. For a 3-param comparison tool this is nearly complete; only pagination/limit specifics are left implicit via 'existing limits apply'.

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 67%. The two meaningful inputs (template, actual) are self-explanatory from their names, and the two legacy fields carry their own 'ignored in free mode' descriptions in the schema. The description's note that no key/credits are needed reinforces the legacy-field behavior, but adds no format or semantic detail for template/actual.

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 ('Compare environment-variable names against a template') and immediately names the key exclusion ('never returns assignment values'). This distinguishes it from sibling audit/scan tools like security_secret_scan and agents_config_audit without needing their schemas.

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

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

Usage is implied by 'Compare ... against a template', but there is no explicit when-to-use or when-not-to-use versus the many sibling comparison tools (e.g., commerce_variant_compare, data_json_diff, agents_tool_name_conflicts). The 'FREE during validation' note hints at a workflow stage but does not name an alternative tool.

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, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it is free during validation with no key, credits or wallet required, and that existing source/input limits still apply. The limits phrase is vague but this is genuine added value.

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

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

Three short, front-loaded sentences with no filler; the core action is stated first and the cost/limits caveats follow. The closing 'existing source and input limits apply' is vague rather than wasteful, so it just misses the top mark.

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 it does cover purpose, normalization semantics and the free-mode constraint. However, for a tool with a nested required object and partial schema coverage, it omits any description of the input shape or what the conflict report contains, leaving gaps for an agent assembling the 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 coverage is 67%, and the description says nothing about the parameters at all. It never mentions that the input is a nested 'names' array (max 200 items) nor the legacy requestId/maxPriceMicroUsd fields, leaving the schema to carry the entire burden with a partial 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 states a specific verb+resource ('Find duplicate or easily confused tool names') and adds the normalization criteria (Unicode, case, separator), which makes the detection semantics unambiguous. It does not explicitly contrast itself with the agents_*/contracts_* siblings, but the function is distinct enough to be selectable.

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 states the tool is free during validation and requires no key/credits/wallet, which hints at a trial context, but gives no when-to-use/when-not guidance and names no alternative tool. Nothing tells an agent when this name-conflict check is preferable to other validation siblings.

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

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

Annotations already signal read-only/idempotent/safe, and the description adds meaningful context: it uses only the Authorization header, has no financial side effects, is a point-in-time snapshot, and excludes wallet USDC. This goes well beyond the annotation hints.

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 adding essential information: action, auth mechanism, non-financial nature, snapshot caveat, and explicit exclusion. No filler or redundant restatement.

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

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

Despite having no output schema, the description fully covers what an agent needs to invoke this safely and correctly: no arguments, auth expectations, side-effect profile, and result semantics. Nothing material is missing for a zero-parameter read tool.

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

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

With zero parameters, the empty schema already implies no arguments, but the description adds important clarity by stating 'takes no arguments or credentials' and explaining that authentication comes only from the private Authorization header.

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 ('read') and resource ('service-credit balance and live/test mode'), and clarifies what it is not ('Does not read wallet USDC'). This is distinct from sibling tools focused on config audits, preparation, and parsing utilities.

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?

Clearly implies when to use: whenever the current credit balance or live/test mode is needed. It also explicitly excludes non-read use cases with 'No charge, purchase, reservation or total spending limit,' though it does not name a specific alternative sibling tool.

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

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

Adds real context beyond the annotations: free, no API key required, examples are fixed and synthetic (not customer activity), and the tool cannot run custom input, access a wallet, or spend credits. The annotations already cover readOnly/idempotent/closed-world, so this additional disclosure is genuinely additive.

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 cost/credential constraint, then the action, then the scope limits. Every clause earns its place with no redundancy.

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

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

For a one-parameter, no-output-schema utility, the description covers what the tool returns (a fixed example), the constraints, and the cost model. Minor gap: it doesn't clarify whether the returned example is a full request/response pair or how large it is.

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 must carry the parameter's meaning. It does: the tool 'accepts only a tool name' drawn from a listed set of non-network tools, which explains the enum's scope beyond the bare list. It doesn't document how to obtain a valid name, so not a 5.

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 a fixed handler-generated input/output example for a listed non-network tool. The purpose is unambiguous and distinguishes it from execution tools ('cannot run custom input'). It does not explicitly name the preview siblings it might be confused with, so it falls just short of 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?

Gives a clear when-to-use condition: 'before supplying your own task input.' It also states the negative case implicitly by contrasting with running custom input. No sibling tool is named as an alternative, so 4 rather than 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 establish readOnly/idempotent/non-destructive/local scope, so the bar is lower; the description still adds real behavior: it discloses that conflicts and unknown fields are PRESERVED rather than resolved, that no payment or paid fallback occurs, and that input is capped at 16384 UTF-8 bytes. These are genuine operational traits beyond the annotation set.

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

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

Front-loaded with the free/no-key hook and the core compare purpose, followed by tighter constraint sentences. Dense but every clause carries information (scope, profile default, size budget, no-fetch). Minimal waste, though the trailing 'no payment or automatic paid fallback' overlaps with the 'FREE, no key' opener.

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 narration, and the description covers behavior (conflict preservation), input limits, and the profile default. The notable hole is the unexplained distinction between this tool and its non-preview sibling commerce_feed_page_compare, which the description does nothing to resolve.

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 20%, so the description must carry meaning, and it partially does: 'identity, price, currency and availability' maps to the feed fields, and the availabilityProfile google_merchant vs generic default is clarified. But html, pageUrl and offerUrl receive no explanation, so several parameters remain undocumented across 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?

The description states a specific verb (compare) plus the exact resources: supplied feed identity/price/currency/availability against selected JSON-LD product evidence. This is well beyond a tautology. However, it never differentiates itself from the near-identical sibling commerce_feed_page_compare or explains what the '_preview' suffix means, leaving the agent unable to route between them from the text 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?

Constrained context is implied: 'FREE, no key', 'Supplied data only; no fetch' tells the agent this runs on provided input rather than fetching pages, and 'availabilityProfile ... generic is the default' guides parameter choice. But there is no explicit when-to-use / when-not-to-use framing and no pointer to commerce_feed_page_compare or the other _preview siblings as 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 and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: free/no-key, no network fetch, no payment or paid fallback, and a hard input-size ceiling. It does not discuss batching or rate behavior, but that is minor.

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

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

Front-loads the value hook ('FREE, no key') then the core action, with tight clauses and no filler. The final sentence slightly fragments into a list of negatives, but every element adds a real constraint.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The gap is input-side: with 0% schema coverage on four parameters, an agent still lacks the semantics of query, maxLinks and sourceUrl, which the description never fills in.

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% across four parameters, so the description carries the full burden — yet it only alludes to the html byte limit ('32768 UTF-8 bytes'). Nothing explains what query matches against, how maxLinks caps results (default 5, max 20), or that sourceUrl is needed to resolve relative hrefs into direct URLs.

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: 'Rank real links in supplied HTML against a query', and pins the output as 'direct URLs and matched words instead of a page dump'. The 'supplied HTML' / 'no fetch' framing cleanly separates it from fetch-based siblings like web_link_shortlist and from html_links.

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 explicit exclusions ('No search or destination verification', 'Supplied data only; no fetch'), which tells the agent this is for HTML it already holds rather than for retrieving pages. It stops short of naming the fetch-based alternative (e.g. web_link_shortlist) that would apply when the HTML must be downloaded.

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 mark it read-only, idempotent, and non-destructive, and the description adds meaningful behavioral detail: it never fetches external data, never triggers payment or paid fallback, and abstains when evidence is ambiguous. It also discloses the evidence sources it relies on, which goes beyond the structured 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 terse sentences front-load the free/no-key status and then state the core action, input constraints, abstention behavior, and no-fetch/no-payment guarantee without repetition. Every phrase 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?

For a simple, read-only analysis tool with an output schema, the description covers input limits, no-fetch/no-payment behavior, and ambiguity handling. It does not explicitly state the role of pageUrl, but the schema example and output schema fill most remaining gaps.

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

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

Schema description coverage is 0%, so the description carries the burden. It identifies the main input as JSON-LD HTML and hints at the optional pageUrl through 'canonical evidence', but it never explicitly explains the html/pageUrl parameters or which one is required. The inline example helps, but the description itself leaves pageUrl under-specified.

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 task: identify the main Product or ProductGroup from supplied JSON-LD HTML, and lists the evidence signals used (identity, mainEntity, canonical) plus an abstention policy. This clearly separates it from sibling preview tools such as offer_preview and pack_preview. The verb 'identify' plus the resource scoping makes the purpose 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 states it operates on supplied data only, with no fetch, payment, or paid fallback, and that it is free and keyless, which tells an agent when this tool is appropriate. It also provides a decision rule to abstain on ambiguity. It does not explicitly name sibling alternatives or exclusion conditions, but the context is clear 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, non-destructive, and closed-world, and the description is consistent with them. It adds concrete behavioral detail beyond annotations: a 16384-byte input cap, a max of 3 offers, truncation/warning inspection, and no paid fallback. Missing only auth/rate-limit context, which is minor for a free local 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?

Front-loads the key qualifier ('FREE, no key') then the operation and constraints. Slight redundancy between 'At most 3 offers' and 'maxOffers defaults to 3', but overall dense and earn-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?

Output schema exists so return format needn't be explained, and the description hints at truncation/warnings for inspection. Limits, fallback policy, and the larger-input alternative are all covered; only baseUrl semantics remain 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 0%, so the description must compensate. It explains the html size cap (16384 UTF-8 bytes) and maxOffers (defaults to 3, capped at 3), but baseUrl is never mentioned and gets no semantic meaning anywhere.

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

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

States a specific verb and resource ('Extract declared Product/Offer JSON-LD from supplied HTML only') with clear scope boundaries. The 'only' and 'no page fetch' phrasing distinguishes it from sibling extractors like commerce_offer_extract.

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

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

Explicitly names the alternative for larger inputs ('Larger HTML uses the free commerce_offer_extract full tool within its limits') and states what it does not do (no fetch, no JS, no live-price, no orders, no paid fallback). An agent can route correctly.

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 read-only, idempotent, non-destructive, closed-world behavior, so the safety bar is low. The description still adds real context: no key/payment/network fetch or paid fallback, a 4096 input-byte cap, and itemized numeric limits (3 offers, 1000 units, 1000 units/pack, 50 packs/offer). That is useful disclosure beyond the structured fields.

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

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

Dense but front-loaded: purpose first, then limits, then cost scope, then auth/network caveats, then the alternative routing. Every clause carries information (limits, exclusions, no-key, alternative) 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description supplies what those fields can't: the exact envelope constraints and the 'exact item subtotal only; excludes shipping, tax, fees' costing semantics. Only the currency/minorUnitDigits meaning is left uncovered.

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

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

Schema description coverage is 0%, so the description must compensate. It references offers count, required units, units-per-pack and packs-per-offer caps, which map to the schema constraints, but it never explains the semantics of 'currency' or 'minorUnitDigits', nor the per-offer id/price fields. Compensation is partial.

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

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

States a specific verb+resource ('custom pack planning') and distinguishes itself from the sibling commerce_pack_plan, which it explicitly names as the 'full tool'. An agent can tell it is a bounded preview variant rather than the general planner, though it never restates what the output actually is.

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 hints at routing ('Larger tasks may use the free commerce_pack_plan full tool within its limits') and lists hard limits that imply when this is and is not sufficient. However, the boundary condition is vague ('within its limits') and there is no explicit when-to-use/when-not statement, so 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses several important behaviors: it is free and keyless, has a hard input size limit, processes only supplied data (no external fetches), and rejects ambiguous text. It also clarifies that there is no automatic paid fallback. These details are not derivable from annotations or schema, and they directly affect how an agent should invoke the tool. No contradiction with annotations exists.

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

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

The description is two sentences, front-loaded with the most critical practical fact ('FREE, no key') before the functional summary. Every clause adds value: limits, no fetch, no fallback, rejection behavior. There is zero redundancy and the structure is easy to scan. It is appropriately concise for a preview tool.

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

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

The tool has an output schema (not shown but present), so the description does not need to explain return values. It covers the key constraints an agent needs: input limits, free access, no external side effects, and rejection of ambiguous input. It does not explicitly state the output format or error behavior, but the output schema likely covers that. Minor gap: it does not mention that this is a preview of a full tool, which could affect expectations, but the name and free status imply 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?

The schema itself is self-explanatory (locale enum, quantities array with id and text), but the description provides little explicit parameter-level meaning beyond the domain ('locale-explicit pack-size expressions'). With 0% schema description coverage, the description should compensate more, but it does convey the overall purpose of the quantities field. It does not explain the exact format or constraints of id/text beyond the schema's maxLengths. The example in the schema aids understanding, so a 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 ('Normalize'), a resource ('locale-explicit pack-size expressions and multipacks'), and the outcome ('to exact grams, millilitres or counts'). It also explicitly mentions rejection of ambiguous text, which distinguishes it from a simple parser. The 'preview' suffix and 'FREE, no key' imply a limited version, but the core purpose is unambiguous and distinct from siblings like commerce_pack_size_normalize.

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 conveys usage context: it is free, requires no key, and has strict input limits (4096 bytes, max 5 quantities). It also states that only supplied data is used (no fetch, payment, or paid fallback), which is a clear exclusion. However, it does not explicitly say when to prefer this preview tool over its full sibling (e.g., commerce_pack_size_normalize) or other alternatives, nor does it mention any condition for using the full version. The guidance is useful but not fully explicit about tool selection.

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

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

Annotations already declare the read-only, non-destructive, idempotent, closed-world profile, yet the description adds genuinely new behavioral facts: no API key needed, a hard 32768-byte total JSON input cap, an output budget, and an explicit guarantee of no network fetch or automatic paid fallback. These cost/limit/no-side-effect disclosures go beyond the annotations and help an agent predict 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?

Front-loads the key operational fact ('FREE, no key') and packs constraints into short clauses with no filler sentences. It is dense and efficient, though the somewhat vague 'Explicit shared output budget and scope' phrase is less informative than its length suggests.

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?

Return values need not be described since an output schema exists, and the description covers cost, input size, and no-fetch guarantees. But it omits parameter semantics for maxChars/sourceUrl and offers no routing guidance among the numerous delta/compare siblings, so it is only minimally complete for a 4-parameter tool in a crowded namespace.

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 parameter burden, but it only clarifies beforeHtml/afterHtml (via 'before/after HTML') and gesturally points at an 'output budget' that may map to maxChars. It never explains maxChars truncation semantics or what sourceUrl is used for, leaving two of four parameters undocumented.

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 (return) and resource (added and removed content blocks) plus the required input (before/after HTML), so the core function is unmistakable. It implicitly separates itself from fetch-based siblings via 'Supplied data only; no fetch,' but never names web_page_delta or the other delta/compare siblings, so full sibling differentiation is left to inference.

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

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

The rationale 'avoid rereading unchanged text' implies the delta-monitoring use case, and 'Supplied data only; no fetch' hints at when this is preferred over a live-fetch tool. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling tools, 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description still adds real context beyond that: no model involved, no fetching, no payment or automatic paid fallback, and an explicit 32768-byte input cap. It is candid that token savings are not guaranteed, which is honest behavioral disclosure.

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

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

Front-loads the 'FREE, no key' hook well and stays reasonably short, but repeats the negative-fetching idea twice ('No model, fetching' and 'no fetch') and repeats the paid-fallback concept, wasting a sentence on 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?

Output schema exists, so return values need not be described. Combined with annotations covering safety, the description supplies the remaining operational constraints (input size, offline, no cost) that an agent needs to call this correctly; only the per-parameter semantics remain thin.

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, and it largely does not. It gestures at 'source' (sourceUrl) and 'truncation' (maxChars) and states the 32768-byte input limit, but never explains maxChars' default/max/floor of 256 or what sourceUrl is used for, leaving the agent to infer from 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 (pack) and resource (supplied HTML) and names the output form: bounded readable blocks with source, truncation and size estimates. The phrase 'supplied HTML' implicitly distinguishes it from fetch-based siblings like web_page_pack_fetch, though it never names an 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?

Implies the usage context ('supplied data only; no fetch') so an agent understands this is for HTML it already holds, and 'FREE, no key' signals cost constraints. It stops short of naming when-not or the specific alternative tools to route to when data must be retrieved.

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, destructiveHint=false, so the safety profile is covered. The description does add genuinely useful context beyond them: no authentication is needed and funding is currently paused. It says nothing about what limits or access data are returned, so it stops at adequate.

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 with no padding, and the operational caveat ('Funding is paused') is front-loaded. 'Read free validation access and shared limits' is compressed to the point of ambiguity, which costs a point.

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

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

For a zero-parameter, annotation-covered read tool, the description needn't explain safety or inputs. However, with no output schema, it should say something about what 'validation access' and 'shared limits' actually return; that gap leaves the agent unsure what it will get back.

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

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

The tool takes zero parameters and schema description coverage is 100%, so the baseline of 4 applies. There are no parameters whose meaning the description would need to clarify.

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 name says 'payment_options' but the description says 'Read free validation access and shared limits. Funding is paused.' The verb is present ('Read') but the resource is fuzzy and the two sentences don't clearly resolve into a single coherent purpose. No differentiation from the many agent_utilities_* siblings is offered.

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 credentials required' and 'Funding is paused' hint at operating context, but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings. The agent must guess whether this tool is even actionable given funding is paused.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful context beyond that — that no execution or reservation occurs and that the call is free — but it does not address the notable idempotentHint=false, nor what the returned arguments look like or how they should be consumed.

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 with the key qualifier ('FREE') front-loaded and zero filler. Slightly clipped to the point of ambiguity, but structurally efficient.

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

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

For a tool that dispatches across 46 utilities with an undocumented nested 'input' object and no output schema, the description is too thin — it never explains the name/input relationship or what the agent should do with the returned arguments.

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 full burden. It says 'validate input' but never explains the 'name' parameter (a 46-value enum selecting the target utility) or how the free-form 'input' object must be shaped to match that target. This is a significant gap for a meta-tool.

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 action (validate input, return exact arguments) and clarifies that nothing is executed or reserved. However, the verb 'prepare' is vague about the tool's role, and it never explains that the 'name' parameter selects which of the ~46 sibling utilities is being prepared, so the agent must infer the tool's function from the enum 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 phrase 'for a free full call' implies this is a pre-flight step before invoking a full/paid call, and 'no execution or reservation' implies a dry-run use case. But no alternatives are named (e.g. the *_preview or *_trial siblings), and the conditions selecting this tool over a direct call are left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful behavioral traits beyond that: deterministic output, stable issue IDs, bounded evidence pagination, no credentials, no model invocation, and no charge. These materially help an agent reason about cost and side effects.

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-loading what the tool does before the constraints. The 'FREE' emphasis and the list of negatives are borderline filler, but overall it is tight and every sentence carries some 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?

For a 10-parameter tool with nested objects, no output schema, and no parameter descriptions, the description is too thin. It never explains the snapshot shape, what previousIssueIds enables (issue diffing), or how coverage/capturedAt affect results, leaving an agent with an incomplete picture of how to call it correctly.

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

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

Schema description coverage is 0% across 10 parameters, so the description must carry the load and it largely does not. It hints at the summary/evidence distinction and bounded pagination (mapping to detail/limit/offset), but says nothing about pages, siteUrl, pageUrl, coverage, capturedAt, previousIssueIds, or group. Most inputs remain undocumented in both schema and prose.

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: it audits supplied same-site snapshots for technical SEO issues. It also names scope boundaries (deterministic, local-only) that distinguish it from crawl/fetch siblings like web_readable_fetch or web_page_pack. An agent can identify the capability immediately.

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

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

It gives a preference rule ('prefer local crawler reports... to keep raw HTML outside model prompts') and states a negative constraint (no remote crawl), which implies when it applies. However, it never names an alternative tool or a concrete when-to-use/when-not-to-use condition relative to the many sibling tools. Guidance is implied rather than explicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description still adds real context: free and keyless, a 32768-byte input limit, no generated consensus, and no automatic paid fallback. It stops short of describing the output shape or failure behavior, but the cost and scope disclosures are genuine value beyond 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?

Front-loads cost and purpose well, but 'No fetch' and 'no fetch, payment or automatic paid fallback' restate the no-fetch point, and the byte-limit sentence is tacked on after the alternative. Mostly tight, with noticeable redundancy across the two sentences.

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

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

An output schema exists, so return values needn't be described, and the behavior/cost framing is solid. However, for a transformation tool with 4 params at 0% schema description coverage, the description leaves the parameters unexplained, which is a real gap 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 0% and there are 4 parameters, so the description must carry the semantic load, but it never explains maxChars, maxComments, sourceUrl, or the thread structure. The mention of a 32768-byte input cap is the only limit-related detail, leaving the two size/limit parameters undocumented.

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 (supplied Reddit comments JSON) and names the output precisely: a bounded post and reply tree with original Markdown, authors and direct links. The 'No fetch' clause implicitly separates it from fetch-based siblings like web_reddit_thread and web_thread_pack, so an agent can tell what it does 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?

Clear context: 'Supplied data only; no fetch, payment or automatic paid fallback' tells the agent to use this only when it already holds the JSON, versus fetching tools. It doesn't explicitly name an alternative sibling to use when fetching is required, so it stops short of a full when/when-not/alternatives statement.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the bar is lower. The description adds genuinely useful behavioral context beyond them: no fetch, no generated summary, no payment or automatic paid fallback, and a hard 32768-byte input ceiling with a bounded text budget.

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?

Key constraints are front-loaded in the opening sentence, but the 'no fetching / supplied data only / no fetch' prohibition is stated three times across separate sentences, which is redundant padding rather than earned 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?

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description is nearly complete, lacking only per-parameter semantics for 'section' and 'sourceUrl' and any positive usage cue.

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

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

Schema description coverage is 0%, so the description must compensate. It loosely covers two of four params ('bounded text budget' ~ maxChars, '32768 UTF-8 bytes' ~ html maxLength) but says nothing about 'section' selection or what 'sourceUrl' is for or whether it is validated against the supplied HTML.

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 ('Pack') and resource ('supplied Wikipedia article HTML') plus the outputs it produces: sections, source links, attribution, and a bounded text budget. The word 'supplied' plus 'No fetching' implicitly separates it from fetching siblings like web_wikipedia_read/web_wikipedia_pack, though it never names 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?

Gives a clear negative condition ('No fetching or generated summary', 'Supplied data only'), which implies the tool is for when you already have HTML in hand. But it never states the positive when-to-use case or explicitly names an alternative for agents that don't yet have the HTML.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond them: it is a bounded free trial with no service debit and no paid fallback, and that upstream access/rate limits still apply.

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

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

The text is short and front-loaded with the free-trial framing, but the 'Reader: maxChars 3000, maxComments 5' fragment appears to be boilerplate for a different tool and adds noise rather than value here, weakening structure.

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

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

With no output schema and 0% schema coverage across three parameters, the description should compensate but leaves date format, language options, and result semantics unexplained, while including irrelevant reader-specific detail. An agent would have to guess at several key inputs.

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, but it only mentions the limit value (10). The required 'date' parameter and its YYYY-MM-DD format are never addressed, the language enum is unmentioned, and 'namespace filtering' refers to something not present as a parameter, which is potentially misleading.

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: returns dated Wikipedia article links ranked by official daily pageviews, with rank/view counts and namespace filtering. It is clearly distinguishable from the read/pack siblings by the 'popular' ranking focus, though it never names those alternatives 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?

'FREE bounded source trial' and 'No service debit or paid fallback' imply this is a no-cost preview variant, which hints at when to prefer it over paid/full siblings. However, there is no explicit guidance on when to choose this over web_wikipedia_popular or agent_utilities_wikipedia_pack_preview.

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/non-destructive, but the description adds genuinely useful behavioral context: 'No service debit or paid fallback' and 'Upstream access/rate limits still apply'. The out-of-scope budget mentions ('maxComments 5', 'Popular links: limit 10') do not map to any parameter of this tool and slightly muddy the signal, keeping this below a 5.

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

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

Front-loaded with the core action and reasonably compact, but the telegraphic fragments ('inspect omissions', 'Ten supported editions') and the parameter-like figures that belong to other tools add noise rather than information.

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

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

With no output schema, the description does convey what is returned (revision, license, sections, budget) and the rate-limit constraint. However, key input semantics (url/section format) remain unspecified and the extraneous budget mentions leave the scope of this specific tool ambiguous.

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 burden. It clarifies the maxChars text budget (3000) and implies sections, but never explains whether 'url' is a full URL or an article title, nor the accepted format/values for 'section'. The 'maxComments' figure further confuses the parameter picture.

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 a public Wikipedia article through the official API', and lists what it returns (revision, license, sections, text budget). It is clear on its own, but it never names or distinguishes itself from the non-trial sibling web_wikipedia_read or from agent_utilities_wikipedia_popular_trial, so an agent cannot route confidently without opening schemas.

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

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

'FREE bounded source trial' gestures at a usage context, but there is no explicit when-to-use, when-not-to-use, or named alternative. The distinction between this trial tool and web_wikipedia_read / agent_utilities_wikipedia_pack_preview is left entirely 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 read-only, closed-world, non-destructive behavior, so the bar is lower. The description earns credit for adding non-obvious traits: conflicts and unknown fields are preserved rather than dropped, google_merchant remaps availability (explicitly 'not an eligibility check'), and free-mode has no key/credit/wallet requirement. It does not explain the not-idempotent flag, which is slightly surprising for a read-only compare.

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 compact sentences, each carrying distinct information: the comparison scope, the profile option, the billing state, and the limit caveat. Scope is front-loaded and there is no filler, though the two free-mode sentences could be merged.

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 nested-object, read-only comparison tool with an output schema and safety annotations, the description covers scope, mode selection, cost, and limits adequately. Return-value shape is rightly delegated to the output schema; only sibling differentiation and named alternatives are 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 67%, so the baseline is 3. The description usefully enumerates which feed fields are compared (identity, price, currency, availability) and clarifies the generic-vs-google_merchant availabilityProfile tradeoff, but adds nothing about pageUrl, offerUrl, or the legacy requestId/maxPriceMicroUsd semantics beyond what the schema already states.

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

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

The description names a specific verb (compare) and the two resources being reconciled: the supplied feed identity/price/currency/availability and the JSON-LD product evidence on the page. That is far more than a restatement of the name, though it stops short of explicitly distinguishing itself from siblings like commerce_variant_compare or commerce_offer_extract.

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

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

Usage is implied: you use this when you have both a feed record and a page whose JSON-LD you want cross-checked. The FREE/no-key note is a useful selection signal, but no alternative tool is named and no explicit when-not condition is given, so the agent must infer routing.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description earns credit by adding billing and access context: free during validation, no key/credits/wallet required, and inherited source/input limits. It does not explain what a failed or malformed check digit returns, but with an output schema present that burden is reduced.

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

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

Purpose and scope are front-loaded, and the remaining sentences are short and information-dense. 'FREE during validation' and 'No key, credits or wallet' overlap somewhat, a minor redundancy.

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

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

With an output schema present, return values need not be described, and the description covers scope, cost, auth, and accepted formats. The phrase 'Existing source and input limits apply' is vague about the actual constraints, which is the only real gap for a single-purpose validation 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 67% and the required 'code' field carries no description, so the enumeration of accepted formats (GTIN-8, UPC/GTIN-12, EAN/GTIN-13, GTIN-14) genuinely adds meaning beyond the bare string/maxLength definition. The legacy requestId and maxPriceMicroUsd fields are documented in the schema itself rather than the 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 (validate) and a precise resource (GTIN-8/UPC-12/EAN-13/GTIN-14 check digits), and immediately delimits scope with 'no product lookup,' which cleanly separates it from product-oriented siblings like commerce_main_product and commerce_offer_extract. An agent can route to this tool without opening the schema.

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

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

The 'no product lookup' clause functions as a when-not-this condition, steering agents away from expecting product data, and the free/no-key statements clarify the cost and auth context. It does not name a specific alternative tool for product resolution, so it stops short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered structurally. The description adds genuine behavioral context beyond that: the abstain-on-ambiguity policy, the free/no-key/no-credits billing state, and that existing source and input limits still apply.

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, purpose front-loaded, with cost and limit notes trailing. No filler, though the billing sentence is somewhat repetitive ('FREE', 'No key, credits or wallet').

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 purpose, cost state, and ambiguity handling; only the parameter-level detail is thin, which is minor given a 3-param schema with 67% coverage.

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

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

Schema coverage is 67%, and the description adds nothing about the html/pageUrl inputs or the two legacy fields. It gestures at 'supplied JSON-LD HTML' and the evidence sources, but adds no format, size, or semantics detail beyond what the schema already documents.

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 ('Identify the main Product or ProductGroup from supplied JSON-LD HTML') and names the evidence it uses (identity, mainEntity, canonical). It does not, however, distinguish itself from the near-identical sibling agent_utilities_main_product_preview, so an agent cannot tell the two apart from the text 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?

Provides useful context ('abstain on ambiguity', 'FREE during validation') but never states when to choose this tool over the sibling preview variant or other commerce_* extractors. Usage is implied rather than directed.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, non-open-world), and the description adds genuine context beyond them: exact-amount handling, strict grouping, per-price error reporting, the 50-item cap, and that no key/credits/wallet are needed in free mode. It does not, however, explain the unusual idempotentHint=false for what looks like a pure normalization operation.

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

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

Front-loaded with the core action and its limits, followed by two short sentences on cost and constraints. Slightly telegraphic phrasing ('exact amounts, strict grouping and per-price errors') but no wasted sentences.

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

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

An output schema exists, so return values need not be explained, and the description covers limits, free-mode behavior, and error semantics adequately. It leaves the non-idempotent annotation and the legacy parameter handling unaddressed, which keeps it short of a 5.

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

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

At 67% schema description coverage, the schema carries most of the parameter burden, and the description's mention of locale, currency and decimal scale just restates the required nested fields. The legacy requestId/maxPriceMicroUsd fields are documented only in the schema, so the description adds no compensating detail.

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

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

States a specific verb and resource ('Normalize ... displayed prices') plus scope ('up to 50', 'explicit locale, currency and decimal scale'). This clearly separates it from adjacent siblings like commerce_price_components and commerce_unit_price, which decompose rather than normalize whole displayed prices.

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 gives no when-to-use or when-not-to-use guidance and names no alternative tool. The 'FREE during validation' line describes pricing/access, not the conditions under which this tool should be selected over siblings such as commerce_price_components.

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, non-destructive, closed-world), so the bar is lower; the description still adds real value by disclosing bounded output, missing-price warnings, separate aggregate ranges, and the free/no-key/no-wallet access model. It does not contradict the annotations, though the non-idempotent hint for a pure extraction is unexplained.

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

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

Front-loaded with the purpose, followed by compact access-model notes. Every clause carries information, though the three short access-mode sentences could be merged without loss.

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 flags aggregate-range separation and missing-price warnings. The free-mode/limit context is present; only the relationship to sibling extraction tools is left implicit.

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

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

Schema coverage is 67%, and the two legacy fields are already documented inline. The description hints at "bounded" offers (maxOffers) and "input limits," but adds no meaning for baseUrl or maxOffers beyond what the schema states, so it neither compensates for nor extends the partial coverage.

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

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

Specific verb ("Extract") plus resource ("bounded Product offers from supplied JSON-LD HTML") and the output characteristics (source pointers, missing-price warnings, aggregate ranges). An agent can tell it apart from a generic JSON-LD or page extractor, though no sibling is named to sharpen the distinction.

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 usage context (you already have JSON-LD HTML and want Product offers), but it never states when to choose this over html_jsonld, commerce_main_product, or agent_utilities_offer_preview. No exclusions or alternatives are given, so routing relies on 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely new context: free during validation, no key/credits/wallet required, and the 20-offer cap. It does not explain what happens when no valid pack combination exists for the required count, which would be useful for a solver.

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 compact sentences, front-loaded with the core purpose before the pricing/limit caveats. No filler, though the trailing 'Existing source and input limits apply' is somewhat vague.

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 offer cap and cost constraints. However, for a constrained optimization tool it omits what happens on infeasibility (e.g., maxPacks too low to reach requiredUnits) and how ties or interchangeable offers are resolved.

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 67%, so the schema carries most of the burden. The description adds light meaning — 'required count' maps to requiredUnits, 'up to 20 interchangeable offers' maps to the maxItems cap, and 'exact prices / explicit pack limits' gesture at price and maxPacks — but adds no format or syntax detail beyond the schema.

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

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

The description states a specific verb+resource ('Choose the lowest-cost whole-pack combination for a required count') and names the key constraints (exact prices, explicit pack limits, up to 20 offers). It is clear what the tool does, though it never names a sibling to distinguish itself from the many pack-related tools like agent_utilities_pack_preview or commerce_pack_size_normalize.

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 says the tool is FREE and requires no key/credits/wallet, but gives no guidance on when to use this tool instead of the pack-preview siblings (agent_utilities_pack_preview, agent_utilities_page_pack_preview). No alternatives, prerequisites, or exclusion criteria are stated.

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

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

Annotations already cover readOnly/destructive/closed-world, so the bar is lower, and the description still adds real context: it is free during validation with no key/credits/wallet, it rejects ambiguous text rather than guessing, and source/input limits apply. It does not explain the non-obvious idempotentHint=false, which is a minor remaining 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 short, front-loaded clauses: purpose first, then cost, then limits. No filler, and every clause carries information. Slightly clipped telegraphic style but nothing extraneous.

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 purpose, cost, rejection behavior and limits. The vague 'Existing source and input limits apply' is the only under-specified element; constraints like min/max items live in 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 67%, so the schema baseline is 3. The description contributes only indirectly ('locale-explicit' gestures at the locale enum; 'No key, credits or wallet' relates to the legacy requestId/maxPriceMicroUsd fields) and never clarifies the quantities array, id/text semantics, or the 50-item cap.

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 (normalize) and resource (locale-explicit pack-size expressions and multipacks) and names the output units (grams, millilitres, counts), plus the failure mode (reject ambiguous text). This is far more specific than a restated name, though it never names the sibling tools (commerce_pack_plan, commerce_unit_price) it must be distinguished from.

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

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

Usage is only implied: an agent can infer it should run this before trusting raw pack-size strings, and that ambiguous input is refused. There is no explicit when-to-use, when-not, or alternative routing vs commerce_pack_plan / agent_utilities_pack_preview. The FREE phrasing is cost guidance, not usage 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 readOnly/non-destructive/openWorld=false, so the bar is lower, and the description still adds real behavior: missing costs remain unknown rather than being coerced to zero, and a declaredTotal can be checked against the computed sum. The auth/cost disclosure ('No key, credits or wallet') is useful, though 'FREE during validation' is ambiguous about what changes afterward.

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

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

The core purpose is front-loaded in the first clause and the whole thing is only three short sentences. The cost/auth sentence is telegraphic and slightly noisy for a read-only reconciliation tool, but nothing is redundant.

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. Given a read-only annotation set, the description covers the operation, the null-handling rule, the optional total check, and access requirements, leaving no gap an agent must fill before calling 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 67%, so the schema does most of the work on the nested input object. The description adds 'exact decimals' (hinting at the string-decimal pattern) and names the component fields and declaredTotal, but it explains nothing about currency/minorUnitDigits semantics or how the optional legacy fields (requestId, maxPriceMicroUsd) are handled beyond the schema note.

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 (reconcile) and enumerates the resource components it operates on (item, discount, shipping, tax, fee amounts), plus the mechanism (exact decimals). This is far more informative than a tautology, but it never distinguishes itself from adjacent siblings such as commerce_unit_price or commerce_money_parse, which an agent could plausibly confuse it with.

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

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

There is no statement of when to pick this tool over the many commerce_* siblings, nor any precondition or exclusion. The only usage-flavored sentence, 'Existing source and input limits apply,' is too vague to route an agent, and 'FREE during validation' is a pricing note rather than 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 destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond annotations: it is free, requires no key or wallet, operates on up to 50 offers, performs exact arithmetic, and does not convert currencies. It does not disclose output details, but an output schema exists.

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

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

The description is two compact sentences that front-load the comparison scope and then list operational constraints. Every clause contributes: limits, arithmetic behavior, pricing mode, and prerequisites.

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 an output schema exists, the description need not explain return values. It covers the key behavioral constraints an agent needs: read-only, free access, no currency conversion, exact arithmetic, 50-item limit, and that legacy parameters are ignored. This is sufficient for correct invocation.

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

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

Schema description coverage is 67%, with two legacy parameters clearly described as ignored in free mode. The description adds meaning by clarifying the 50-offer limit and the exact-arithmetic/no-currency-conversion constraint, which helps interpret the required input fields. It does not explain the reference unit semantics in detail, but the schema provides enums and patterns.

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: comparing up to 50 pack prices with exact arithmetic across compatible mass, volume or count units, and explicitly excludes currency conversion. This distinguishes it from siblings like commerce_pack_size_normalize or commerce_price_components, though the core action of normalizing to a reference unit is left implicit.

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 gives clear context: comparing explicit pack prices with no currency conversion and within compatible units. It does not explicitly name sibling tools or state when to prefer alternatives like commerce_pack_plan, but the constraints and scope provide strong usage boundaries.

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 destructiveHint=false, and the description adds meaningful context beyond them: it is FREE during validation, requires no key/credits/wallet, and is subject to existing source and input limits. This pricing/auth context is exactly the kind of non-annotation behavior an agent needs.

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 with the core purpose front-loaded. The free/limit notes are slightly repetitive ('FREE during validation' and 'No key, credits or wallet' overlap), but nothing is padded or 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?

For a read-only comparison tool with an output schema present, the description covers purpose, cost/auth model, and limits adequately, so return values need not be explained. Only the absence of usage routing to alternatives leaves a minor gap.

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

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

Schema coverage is 67%, and the description usefully maps the semantics of the two nested 'input' keys (requested = requested product attributes, offered = offered variant). The legacy params are documented in the schema itself as ignored, so the description's added value over the schema is modest but real.

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 ('Compare') and resource ('requested product attributes' vs 'an offered variant') and names the concrete output ('missing or mismatched fields'). It is clear and self-contained, though it does not differentiate itself from any sibling tool by name.

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 gives the condition 'during validation' and notes free access, but there is no explicit when-to-use vs when-not, and no alternative sibling is referenced (e.g., commerce_feed_page_compare or commerce_pack_size_normalize). 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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description usefully adds that validation runs against a 'bounded JSON Schema 2020-12 subset' and that existing source/input limits apply, but it never says which subset or what the limits actually are, so the added context is directionally useful but vague.

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 with the core purpose front-loaded, and no sentence is obviously padding. The repeated free/pricing framing ('FREE during validation' plus 'No key, credits or wallet') is slightly redundant but compact.

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. However, for a validator the unsupported portion of the 'bounded subset' is exactly the information an agent needs to avoid misusing it, and neither the subset boundaries nor any usage routing are provided.

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 67% and the description adds no parameter-level detail: it never explains the required nested schema/data pair or the semantics of the two legacy fields. The 'no key, credits or wallet' line only loosely corroborates that requestId and maxPriceMicroUsd are ignored, which is already stated 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 (validate) and resource (data using a bounded JSON Schema 2020-12 subset), which is clear and actionable. It does not explicitly distinguish itself from siblings like contracts_openapi_lint or data_json_diff, so it stops short of a 5.

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

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

The description spends its guidance budget on pricing (FREE, no key/credits/wallet) rather than on when to choose this tool over alternatives. There is no stated when-to-use, when-not-to-use, or named alternative among the many sibling validation tools.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful non-schema context (free during validation, no key/credits/wallet, limits apply), but never clarifies what 'selected direct' changes are detected or the nature of the diff output, leaving real behavioral gaps.

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

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

Three short sentences, front-loaded with the core capability before the pricing/limits caveats. No waste, though the 'FREE' framing is more promotional than informative.

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 needn't be explained, and the read-only nature is covered by annotations. However, the scope of 'selected direct breaking changes' and what limits 'apply' remain undefined, which is a meaningful gap for a diff 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 67% and the description says nothing about the parameters, relying on the schema's before/after nested objects and the legacy requestId/maxPriceMicroUsd fields. It only implicitly confirms the inputs are OpenAPI documents, so it adds little beyond the schema; baseline 3.

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

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

States a specific verb+resource: detecting breaking changes between OpenAPI 3.0 documents, which cleanly separates it from siblings like contracts_openapi_lint and contracts_jsonschema_validate. The qualifier 'selected direct breaking changes' is slightly ambiguous about which changes are covered, keeping it from 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?

No indication of when to choose this over contracts_openapi_lint or contracts_jsonschema_validate, and no prerequisites beyond the vague 'existing source and input limits apply'. The pricing note is not usage 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 readOnly, non-destructive, non-open-world behavior. The description usefully adds that the call is free and that 'existing source and input limits apply', which is real operational context, but it says nothing about failure modes or what validation output/errors look like.

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 with the purpose front-loaded; nothing is padded. The two pricing sentences are slightly redundant but still compact.

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. However, an agent still lacks guidance on alternatives and on what the referenced 'input limits' are, leaving it only minimally equipped.

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 67% and the description adds no parameter meaning at all. The central nested input.document has no description anywhere, and the vague 'input limits apply' does not compensate for that 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 (validate) plus the resource and scope (OpenAPI 3.0 JSON structure and internal references). This clearly separates it from contracts_openapi_diff and contracts_jsonschema_validate, though it does not name 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?

The description focuses on pricing ('FREE during validation. No key, credits or wallet') rather than when to use this tool versus contracts_jsonschema_validate or contracts_openapi_diff. No context, prerequisites, or exclusions for selection are provided.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, non-open-world), so the description earns credit for adding context they don't: 'FREE during validation. No key, credits or wallet' discloses pricing/payment behavior, and 'Existing source and input limits apply' flags limits. These are genuinely beyond what the structured annotations convey.

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?

Reasonably short and the core purpose is front-loaded, but the trailing fragments ('FREE during validation. No key, credits or wallet. Existing source and input limits apply.') are choppy and partly redundant with each other, diluting structure.

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

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

An output schema exists, so return values needn't be explained. For a canonicalization tool the description conveys the key facts an agent needs: deterministic key ordering, non-certification scope, free mode, and applied limits. The nested input structure is left entirely to the schema.

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

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

Schema coverage is 67%, so the schema already documents most parameters. The description's 'FREE' and 'No key, credits or wallet' implies the cost/legacy params are inert in free mode, but it adds no format or structural detail for the input.data payload 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: serialize JSON with sorted object keys for deterministic comparison. The purpose is clear and the 'not RFC 8785 certification' clause bounds it. It doesn't explicitly name a sibling to route against (e.g. data_json_diff), so it stops short of a 5.

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

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

The phrase 'for deterministic comparison' implies when to use it, but there is no explicit when-not guidance or named alternative such as data_json_diff or data_json_patch. Usage context is present but left 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, idempotentHint and destructiveHint, lowering the bar. The description still adds useful context, noting results are 'bounded', that it is free with no key/credits/wallet, and that source and input limits apply, which the structured fields do not convey.

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 with the core purpose front-loaded and zero filler. The free-mode sentence is slightly promotional but still informative about auth/cost, so it earns most of 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. Given the nested input and read-only annotations, the description covers the essentials (comparison, bounded output, free/no-key operation, limits) without leaving a critical gap.

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

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

Schema description coverage is 67%; the two legacy fields are documented in the schema and the before/after pair is self-evident. The description's 'bounded changes' loosely maps to maxChanges and 'JSON Pointer paths' to the output, but it adds little concrete parameter meaning, so baseline 3 applies.

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

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

States a specific verb (compare) and resource (JSON structures) and even describes the return (bounded changes at JSON Pointer paths), which clearly distinguishes it from sibling tools like data_json_patch and data_json_canonical. It stops short of explicitly naming which JSON sibling to prefer, 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 guidance on when to use this tool versus alternatives such as data_json_patch, data_json_pointer, or contracts_openapi_diff. The 'FREE during validation' note is pricing context, not a usage condition, so an agent gets no when/when-not signal.

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

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuinely useful behavior: execution is transactional (all-or-nothing), pointers are strict, object properties are handled safely, and intermediate results are bounded. It does not disclose error/rollback reporting, but it meaningfully enriches the annotation baseline.

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; the capability statement (verb, standard, limits) is front-loaded, followed by behavior and pricing. No filler or repetition.

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

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

An output schema exists, so return-value detail is unnecessary. The description supplies the operation cap, transactional semantics, and pricing context. It is nearly complete but lacks sibling routing and error-behavior notes for a mutation-style 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 67%; the description references RFC 6902, which gives useful semantics for the patch array and its per-op pointers, and confirms the 100-op ceiling. It says nothing about requestId/maxPriceMicroUsd beyond what the schema already documents as legacy/ignored, 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 and resource ('Apply ... RFC 6902 operations ... to supplied JSON') and quantifies the scope (up to 100 operations). It is clear what the tool does, but it never distinguishes itself from siblings like data_json_diff, data_json_pointer, or data_json_canonical, so an agent must infer when this is the right patch tool.

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 guidance offered is commercial ('FREE during validation. No key, credits or wallet'), not operational. There is no statement of when to choose this over data_json_diff/data_json_pointer, nor when-not to use it, despite three closely related JSON siblings.

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

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely non-obvious behavioral context: the 100-pointer cap, the missing-vs-null preservation semantics, the free-during-validation pricing model, and that no key/credits/wallet are required. It does not explain what happens when a pointer matches nothing beyond the missing/null note, but that is a minor residual 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?

Roughly three short sentences, front-loaded with the core operation before the pricing/auth caveats. It is slightly choppy and the 'No key, credits or wallet' fragment partly restates 'FREE during validation', but there is no real 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-value shape need not be described. For a read-only extraction tool with nested input (data + paths) and legacy optional fields, the description covers the cap, authorization/pricing model, and a subtle semantic guarantee, leaving only the no-match behavior as an unaddressed edge case.

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 67% and the description compensates by clarifying the pointer format (RFC 6901), the maximum number of paths (100, matching schema maxItems), and the null-vs-missing distinction that governs how an absent match is reported. The two legacy fields (requestId, maxPriceMicroUsd) are already documented in the schema as ignored in free mode.

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 ('Select') plus resource ('JSON values') plus mechanism ('RFC 6901 pointer strings'), and it names the count limit (100). The clause 'preserving missing versus null' distinguishes it behaviorally from data_json_canonical, data_json_diff, and data_json_patch, which are the nearest siblings in the data_json family.

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 states a cost/auth condition ('FREE during validation. No key, credits or wallet') and that existing limits apply, which is useful context, but it gives no guidance on when to choose this over data_json_canonical/diff/patch or what kinds of inputs are inappropriate. No when-not or alternative routing is present.

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, destructiveHint=false and a closed-world scope. The description adds genuinely useful behavioral context beyond that: a hard cap of 50 discovered feeds, no key/credits/wallet required, and that existing source and input limits apply. It does not, however, explain what happens when no feeds are found or how relative URLs are handled.

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 with the core capability front-loaded and no redundancy. The two pricing sentences are relevant but slightly less essential than the discovery-scope statement, keeping it just short of ideal prioritization.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. Given modest tool complexity, the remaining gaps (baseUrl semantics, empty-result behavior) are minor rather than crippling.

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 a moderate 67%, with the nested input.html and input.baseUrl documented only implicitly and the two legacy fields marked as ignored. The description says 'supplied HTML' but never mentions baseUrl's role in resolving relative feed URLs or the 100k/2048 length caps, so it adds little 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 (Discover) and resource (RSS, Atom and JSON Feed links declared in supplied HTML) with a concrete scope cap of 50. This clearly separates it from siblings like html_links and html_metadata, which extract other HTML artifacts.

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?

Contains no when-to-use or when-not-to-use guidance and names no alternatives. The pricing and limit sentences ('FREE during validation', 'Existing source and input limits apply') describe cost constraints rather than selection guidance, so an agent still has to infer when this tool is appropriate.

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=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond that: it caps output at 30 forms, guarantees no field values are returned, confirms nothing is submitted, and notes free/no-key billing plus 'existing source and input limits apply.'

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

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

Front-loaded with the core action, then constraints. Four short sentences, though the pithy 'FREE during validation. No key, credits or wallet.' fragments are slightly telegraphic rather than flowing prose.

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

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

An output schema exists, so return-value shape need not be described. Combined with annotations covering safety and the description covering scope, limits, and billing, the definition gives an agent enough to call it correctly, with only parameter intent left underspecified.

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 67% and the description never mentions the html or baseUrl inputs, leaving their intent to the schema. It does contextualize the legacy requestId and maxPriceMicroUsd fields via 'No key, credits or wallet,' but this is thin for a nested-object 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 ('Describe up to 30 forms and their controls') and scopes the output with 'without returning field values or submitting anything.' The 'forms' resource distinguishes it from sibling html_* tools like html_tables and html_links without needing to name them explicitly.

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

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

Usage is only implied: an agent infers it should call this to understand form structure in HTML. There is no explicit when-to-use, no exclusion condition, and no named alternative among the html_* siblings, though the cost notes ('FREE during validation') hint at a 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=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: a hard 200-heading result cap and a free-mode note (no key, credits or wallet). It still says nothing about the nested input shape or failure 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?

Four short sentences with the core action front-loaded; each carries a distinct fact (cap, free mode, no auth, limits). 'No key, credits or wallet' is slightly redundant but clarifies the free-tier claim.

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

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

An output schema exists, so return values need not be described, and the annotations carry the safety profile. The description covers scope, cost, and limits; the only real gap is that the nested input.html parameter is left undocumented.

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

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

Schema coverage is 67%, so requestId and maxPriceMicroUsd are already documented as ignored legacy fields in the schema. The description does not explain the required nested input.html (a 100,000-char HTML string) at all, adding only the vague 'input limits apply' clause.

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

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

States a specific verb ('Extract') and resource ('headings') and even qualifies the output (parent indices, skipped-level indicators) plus a 200-item cap. The resource is distinct enough from siblings like html_metadata, html_links, and html_tables that an agent can tell it apart, though no sibling is named 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?

There is no statement of when to choose this tool over html_metadata or the other html_* extractors, nor any exclusions. The 'FREE during validation' and 'input limits apply' lines describe cost/constraints, not usage selection.

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

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

Annotations already declare readOnly/openWorld/destructive hints, but the description adds real context beyond them: it will not fetch the images (no outbound network work), it is free with no key, credits or wallet, and result count is capped at 200. It does not discuss failure modes or what happens with malformed HTML.

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-loading the extraction scope before the cost and limit notes. No filler or repeated 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-format detail is unnecessary, and the description still names what is extracted. Cost/pricing and the item cap are covered; the only gap is input parameter semantics such as baseUrl.

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 67% and the description contributes nothing about inputs. Notably baseUrl — which determines how relative image sources are resolved — is undocumented in both the schema and the description, so an agent gets no help here.

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

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

States a specific verb and resource ('Extract ... image URLs, alt text and source attributes') and bounds the output ('up to 200'). The clause 'does not fetch images' implicitly separates it from the web_* fetch siblings, though no sibling is named 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 no explicit when-to-use or when-not-to-use guidance and does not name an alternative such as html_links or web_readable_fetch. Usage is only implied by the extraction verb, plus a vague 'Existing source and input limits apply'.

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 the safe read-only profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuine behavioral context beyond them: a parsing cap of 50 blocks, no auth/cost requirement, and that source and input limits apply. It stops short of a 5 because the referenced 'limits' are left vague.

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 with the purpose front-loaded and no wasted preamble. There is mild redundancy: 'FREE during validation' and 'No key, credits or wallet' both convey the same cost-free point, which slightly dilutes tightness.

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 purpose, the 50-block cap, and the free/no-auth model, which is close to complete for a parse tool. The unspecified 'input limits' leaves a minor gap.

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

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

Schema coverage is 67%, and the schema already documents requestId and maxPriceMicroUsd as 'ignored in free mode.' The description adds nothing about the required input.html beyond loosely gesturing at 'supplied HTML' and 'input limits.' Baseline 3 is appropriate since the schema does the substantive work.

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 scope: 'Parse up to 50 JSON-LD blocks from supplied HTML.' The resource (JSON-LD) is specific enough to distinguish it from sibling html_* tools like html_metadata and html_links. It doesn't explicitly name a sibling it differs from, so it falls 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?

The description offers no when-to-use guidance or alternatives; it never says when to reach for html_jsonld over html_metadata or html_main_text. The 'FREE during validation' and 'No key, credits or wallet' lines are cost/pricing notes, not usage guidance. The agent is left to infer 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 cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description adds real value: a hard 200-link ceiling, HTTP(S) destination resolution, free-mode behavior with no key/credits, and a warning that source and input limits apply. It stops short of describing ordering or dedup behavior, which matters given idempotentHint=false.

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, front-loaded sentences with the core action first. The pricing statements ('FREE during validation' and 'No key, credits or wallet') overlap slightly but are terse enough to be acceptable.

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 covers action, resolution target, result cap, cost model and limit caveats. The main remaining gap is disambiguation from neighboring link/HTML tools, which is minor for a self-contained extractor.

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 67%, so the schema documents most fields; the description nonetheless adds meaning by tying link resolution to 'the supplied page URL' (the baseUrl parameter) and hinting at input limits for the html field. It doesn't explain the two legacy fields or the maxLength constraints, so it neither fully compensates nor is redundant.

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

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

States a specific verb and resource ('Extract ... links') plus a resolving behavior against the supplied page URL, and caps scope at 200. An agent can tell it extracts links from HTML rather than images, forms or tables. It does not, however, distinguish itself from close siblings like web_link_shortlist or agent_utilities_link_shortlist_preview.

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 operates on supplied HTML and returns links, but there is no explicit when-to-use, when-not-to-use, or pointer to a sibling for link shortlisting versus raw extraction. The pricing note ('FREE during validation') is contextual rather than a usage rule.

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, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond the schema: it is free during validation with no key, credits, or wallet required, and that source/input limits still apply — useful operational facts an agent cannot infer from 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, then cost/auth facts, then limits. Nothing is wasted, though the pricing detail is somewhat promotional rather than task-critical.

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 readOnly annotations cover the safety profile. The description supplies auth/cost and limit context, leaving only minor gaps such as what "article text" extraction does with non-article HTML.

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 67%; the nested input.html object carries no inline description, though the top-level requestId and maxPriceMicroUsd fields are documented as ignored legacy fields. The description adds no parameter-level meaning (e.g. accepted HTML form, what maxLength 100000 means), 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?

"Extract article text from supplied HTML" gives a specific verb (extract) and resource (article text), which cleanly distinguishes it from siblings like html_links, html_tables, and html_metadata that extract other facets. It does not name a sibling explicitly, but the target output 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 description says nothing about when to choose this tool over the many other html_* extractors. "FREE during validation" and "Existing source and input limits apply" are pricing/limit notes, not usage routing guidance, so the agent gets no when-to-use or when-not-to-use signal.

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 readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely useful non-schema context: it is free during validation with no key or credits, and that source/input limits apply. It does not explain the contradictory-looking idempotentHint=false or failure 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?

Three short sentences, front-loaded with the purpose before the pricing note. The 'FREE during validation' and 'No key, credits or wallet' sentences overlap somewhat, a minor redundancy in an otherwise efficient description.

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

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

An output schema exists, so return values need not be described, and the description covers purpose plus the auth/pricing reality an agent needs. The main omission is any hint about the baseUrl parameter or how relative canonical URLs are resolved, but overall it is sufficient.

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 67%, and the description adds nothing about any parameter, not even the required nested html or the undocumented baseUrl. The schema documents the legacy requestId/maxPriceMicroUsd fields, so the baseline of 3 applies with no compensating detail from the 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 ('Extract') and an enumerated set of resources (title, description, canonical URL, language, social metadata) from supplied HTML. This cleanly distinguishes it from siblings like html_main_text, html_jsonld, and html_headings that pull different content from the same input.

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

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

Usage is implied by the scope ('from supplied HTML') but there is no explicit when-to-use guidance and no routing to alternatives such as html_jsonld for structured social data or html_main_text for page body. The agent must infer the choice from the resource list alone.

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=false, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context: span-expansion behavior, no key/credits required, and that source/input limits still apply. It does not explain output structure, but the presence of an output schema lowers that burden.

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 behavior. The cost/pricing sentences are relevant to this specific free-mode tool but are somewhat repetitive ('FREE' and 'No key, credits or wallet' say similar things), which is the only minor redundancy.

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

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

Covered: read-only nature via annotations, span behavior, cost, and limits. Missing: any statement of what the output contains or what input.html should look like (raw HTML string vs. fragment). With an output schema present and 67% param coverage, the gap is moderate rather than critical.

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 67%, with the two legacy fields documented inline as ignored in free mode. The description adds nothing about the nested input.html object or its 100000 maxLength. Baseline 3 is appropriate since the schema does most of the work, but the description does not compensate for the uncovered portion.

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

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

States a specific verb and resource: 'Extract source table cells'. The qualifier 'without expanding spans' meaningfully distinguishes behavior from a generic table extractor. It does not name or contrast with any sibling explicitly, but the resource is specific enough to place it among the html_* family.

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 guidance and no alternatives named. The only usage-adjacent signal is 'FREE during validation', which addresses cost, not task selection. An agent cannot tell from the description when to prefer this over html_main_text or html_links.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral value beyond that: it masks cookie values in the output (a data-handling trait) and notes free-mode pricing and limits. It does not describe return structure or pagination, but with annotations carrying safety this is solid added context.

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

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

Compact and front-loaded, leading with the core action and scope. The semicolon-separated pricing/limit clauses are slightly choppy but each earns its place by clarifying cost and constraints.

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 purpose, free-mode cost, value masking, and limits — enough for an agent to call this read-only audit correctly.

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

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

Schema coverage is 67% and the description's only parameter-relevant statement is 'up to 50 Set-Cookie headers', which merely restates the schema's maxItems:50. The legacy requestId/maxPriceMicroUsd fields are already documented in the schema as ignored in free mode. Baseline 3 fits since the schema does most of the work.

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 ('Check') and a precise resource ('Set-Cookie headers') with the attributes audited ('security attributes and prefix rules'). This differentiates it from siblings like security_header_audit and security_csp_audit by scope, though it doesn't explicitly name those alternatives.

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 gives no when-to-use guidance, no prerequisites, and no routing against the many sibling security audits (csp, header, jwt, secret_scan). It only states constraints ('existing source and input limits apply') and pricing, not usage 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 the read-only, non-destructive, closed-world profile, so the bar is lower. The description adds genuine behavior beyond that: it is free during validation, requires no key/credits/wallet, and is subject to input limits. It does not describe handling of a malformed or empty policy, but the cost/auth context is valuable.

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

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

The core purpose is front-loaded in the first sentence, with pricing/limits as short supporting clauses. There is no wasted prose, though the final fragment 'Existing source and input limits apply' is a bit vague about what those limits are.

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 structure needn't be explained, and annotations carry the safety profile. The description covers purpose and cost/auth context; the remaining gap is that 'selected risky or missing directives' does not say which directives are checked, leaving an agent without concrete expectations.

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 67% and the two undocumented-by-description legacy fields (requestId, maxPriceMicroUsd) are explicitly marked 'ignored in free mode' in the schema. The description's 'No key, credits or wallet' reinforces why those are ignored and loosely implies the 'policy' input, but adds no syntax or format detail beyond the schema.

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

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

The description states a specific verb and resource: 'Parse a supplied Content Security Policy and flag selected risky or missing directives.' An agent can identify the operation clearly. However, it does not differentiate from siblings like security_header_audit or security_cookie_audit, which also audit security artifacts.

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 agent infers it should supply an existing CSP string to be audited. There is no explicit when-to-use, when-not-to-use, or pointer to the header/cookie audit siblings for related checks. 'Existing source and input limits apply' is a constraint note, not selection guidance.

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