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

The description goes far beyond the annotations. It discloses estimation methodology and accuracy ('estimates from character and word statistics, not a tokeniser, and typically land within about 15 percent'), pricing table staleness ('a model whose price has moved since is reported with its table date'), and unknown-model handling ('refused with the closest matches rather than guessed'). This is rich behavioral context beyond the safety 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?

The description is front-loaded with the core purpose and well-structured English text. However, it repeats the German pricing information at both the beginning and end ('Kostenpflichtig: 0.002 USDC je Aufruf...' and 'Preis 0.002 USDC je Aufruf...'), which is redundant and adds ~30 unnecessary words. Otherwise, every sentence carries useful information, so it's only slightly over-length.

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 7-parameter, all-optional tool with no output schema, the description provides a complete picture: what it does, what inputs to provide (text or token count, output length, cache/batch), what outputs to expect (input, output, cache-read, cache-write cost per model with total), accuracy caveats, pricing table date, unknown-model refusal, and the per-call fee. This is comprehensive and leaves no major 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining the either/or relationship between 'text' and 'input_tokens' ('Give either the text itself or a token count'), the role of 'output_tokens' ('plus the expected output length'), and the cache/batch discounts tied to 'cached_input_tokens' and 'batch'. It doesn't mention 'calls' or 'models' explicitly, but the schema already covers those, so the added value justifies a 4.

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

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

The description opens with a specific verb+resource phrase: 'Estimate token use and price for a prompt across several models before you spend anything.' It clearly distinguishes itself from siblings by focusing on pre-spend estimation of token counts and costs, including cache and batch discounts. The second sentence 'Works out what a call would cost' reinforces the unique purpose.

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 explicitly tells when to use the tool ('before you spend anything') and provides input instructions ('Give either the text itself or a token count, plus the expected output length'). It also gives an explicit alternative for exact counts: 'where an exact count matters, count with the vendor tokeniser.' This meets the bar for when/when-not guidance with an alternative.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses meaningful behavior: it queries OSV.dev, aggregates severity from multiple sources, reports a worst-case verdict, and includes pricing via x402. It also openly states that absence of findings does not prove safety—an important caveat not visible in 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?

The description is front-loaded with the core purpose, then provides thorough details. However, the pricing information is repeated twice (once in German, once again), making it slightly redundant. The length is justified by the complexity of the tool, but the repetition prevents a perfect score.

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?

Since there is no output schema, the description does an excellent job explaining return values: vulnerability identifiers, severity, summary, lowest fixing version, severity breakdown, and a worst-case verdict. It also covers the data source and limitations, giving the agent all necessary context for decision-making.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds some context by implying the 'packages' parameter can include versions, but it does not detail the exact format or relationships. This matches the baseline for high coverage without significant added semantics.

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

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

The first sentence clearly states the tool's function: 'Check a package list against known vulnerabilities and get, per package, the severity breakdown and the lowest version that closes every finding.' This is a specific verb+resource with clear outputs, and it distinguishes the tool from siblings like license_check or tls_chain.

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

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

The description provides strong context on when to use the tool by listing supported ecosystems (npm, PyPI, etc.) and stating limitations: 'a package with no finding is not proven safe' and 'an internal or vendored package is invisible here.' These are implicit usage guidelines, but no explicit alternatives are named, so it misses a 5.

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

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

The description provides rich behavioral detail beyond the annotations: paragraph-level unit of comparison, word-level diffs for rewrites, symmetric similarity score formula, use of shortest-edit-script diff for ordering/duplicates, reporting of structural counts, and the caveat about different source formats. It also discloses the pricing model (0.002 USDC per call via x402), which is critical operational context. This far exceeds what readOnlyHint/openWorldHint/destructiveHint provide.

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

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

The description is front-loaded with a strong first-sentence overview but becomes repetitive. The pricing information appears twice: once in German ('Kostenpflichtig: 0.002 USDC je Aufruf...') and again in English ('Preis 0.002 USDC je Aufruf, Abrechnung über x402.'). This redundancy inflates the length without adding value. Other sentences earn their place, but the duplicate pricing could be trimmed.

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

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

Without an output schema, the description does an excellent job of explaining what the response will contain: lists of removed/added/reworded blocks, word-level changes within reworded blocks, structural counts, and a similarity score. It also covers algorithm choices, edge cases (different input formats), and limitations (no judgment). This is complete enough for an agent to invoke the tool and interpret results.

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 input schema already documents all 7 parameters with descriptions (100% coverage). The tool description adds no parameter-specific semantics beyond what the schema states: e.g., it doesn't elaborate on ignore_case or block_char_limit, but the schema's descriptions are clear. It does provide conceptual background (paragraph vs block) that indirectly helps understand parameters, but no direct enhancement. Baseline of 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 opens with a precise statement: 'Compares two versions of a document — PDF, DOCX, ODT, HTML, Markdown or plain text — and returns which paragraphs were removed, added or reworded, with a word-level diff inside every reworded paragraph and a symmetric similarity score.' This names the resource (documents), the operation (compare), and the output format, clearly distinguishing it from sibling tools like cve_check or license_check.

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 explains what the tool is for and what it explicitly does NOT do: 'What this endpoint does not do is judge: it says what changed, never whether the change is favourable, material or lawful.' It also warns about the caveat when inputs come from different formats. While it doesn't name alternatives, the purpose is so specific and the sibling tools are so different that usage context is sufficiently clear.

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

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

The description adds behavioral context beyond the annotations: it explicitly states 'Free — no wallet needed and no payment is made,' which is not covered by readOnlyHint=true. It also reveals that the tool returns a listing with specific fields. This is valuable contextual information that annotations don't provide.

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

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

The description is three sentences, each earning its place: the first states the core purpose, the second clarifies cost-related behavior, and the third provides usage order guidance. It's front-loaded and free of filler.

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

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

For a read-only listing tool with no output schema, the description provides adequate context: it lists the fields returned (price, hub, one-line summary), confirms it's free, and advises when to use it. It doesn't fully differentiate from sibling tools but covers the essentials for an agent to decide whether to invoke 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 input schema already provides detailed descriptions for all three parameters (hub, suche, hoechstpreis_usdc) with 100% coverage. The description does not add any additional parameter semantics, so the baseline of 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 clearly states the tool lists every HALOWERK service with price, hub, and one-line summary. It uses a specific verb and resource, and the phrase 'every HALOWERK service' gives scope. It doesn't explicitly distinguish from sibling tools like halowerk_preis, but the intent is clear.

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

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

The description provides clear usage guidance: 'Use this first to see what is available before spending anything.' This tells the agent when to use the tool (before making purchases) but doesn't name alternatives or explicitly state when not to use it. It gives clear context without exclusions.

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 readOnlyHint annotation, the description adds substantial behavioral context: it makes no payment, reports the ceiling rather than minimum for tiered prices, and specifies which amount the budget check uses. These are non-obvious traits that an agent would not know from annotations alone.

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

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

The description is three sentences, front-loaded with purpose, and every sentence adds unique value: cost return, budget check, free/no payment, and ceiling behavior. There is no redundancy or filler.

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

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

Given no output schema, the description adequately explains return values (cost, budget check amount, pass/fail) and key constraints (free, ceiling). The tool is simple with two params and annotations cover safety; the description is complete for an agent to use 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 coverage is 100%, so the baseline is 3. The description does not add further parameter-level detail; it only mentions 'planned call' and 'tiered prices,' which are behavioral rather than param-specific. The schema already documents werkzeug and koerper adequately.

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 clearly states the tool returns planned call cost, the budget check amount, and pass/fail status against per-call cap and session budget. It uses a specific verb 'Returns' and resource, and distinguishes itself by noting it is free and reports the ceiling for tiered prices, separating it from siblings like cost_estimate.

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 for use: checking cost and budget feasibility before making a call. It implies alternatives by stating 'Free — makes no payment,' but it does not explicitly name when not to use it or mention sibling tools, so it lacks explicit exclusions.

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

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

The description goes well beyond the readOnlyHint annotation by disclosing computation methodology: 'All arithmetic runs in whole cents, because adding decimal amounts as floating point produces cent-level noise' and explains formal checks like due date, tax rates, negative lines, and VAT. This provides rich behavioral context that annotations alone do not cover.

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 long and contains redundant pricing statements: 'Kostenpflichtig: 0.002 USDC je Aufruf...' near the beginning and 'Preis 0.002 USDC je Aufruf' at the end. While the content is organized with a clear summary, methodology, and formal checks, the repetition and mixed languages make it less concise than it could be.

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 no output schema, so the description carries the burden of explaining return values. It says 'report every deviation with the exact amount' and mentions reporting rounding differences separately, but it does not describe the output structure (e.g., a list of discrepancies, fields returned). This is a significant gap for a complex tool with 12 parameters.

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 schema coverage at 92%, the baseline is 3. The description adds operational meaning by explaining how parameters are used: 'applies line and document discounts in the right order, groups the net amounts by tax rate' and checks due_date, invoice_date, reverse_charge, customer_vat_number. It explains the interaction between parameters beyond the schema field descriptions.

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

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

The description clearly states the tool's purpose: 'Recompute an invoice from its line items: totals, tax per rate, discounts and rounding, and report every deviation with the exact amount.' It uses a specific verb ('recompute') and resource ('invoice') with clear scope. It distinguishes itself from sibling tools like cost_estimate or output_validate by focusing on invoice auditing.

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

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

The description implies usage for verifying invoice correctness with details of checks performed, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives. Since the context is clear and there are no exclusions, it meets the 'clear context, no exclusions' level.

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 annotations (readOnlyHint=true, destructiveHint=false), the description adds valuable behavioral disclosures: the two-layer check (structure/claims and signature), the per-call cost of 0.002 USDC via x402, and the behavior when no key is provided. It also explains that it reports unverified signatures rather than failing or assuming success. No contradiction with 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?

The description is overly verbose and redundant, repeating the pricing information three times (Kostenpflichtig, Hoechstens, and final Preis lines). While the purpose is front-loaded, the repeated German pricing paragraphs and lengthy explanation detract from overall conciseness and 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?

Given 8 parameters and no output schema, the description is fairly complete: it specifies claim checks (exp, nbf, iat, issuer, audience, token lifetime), signature algorithms (HMAC, RSA, RSA-PSS, ECDSA), JWKS handling, and the no-key case. It does not explicitly describe the return format, but the level of behavioral detail largely compensates.

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 input schema already describes all 8 parameters (100% coverage), so the baseline is 3. The description's references to 'clock skew you allow' and 'kid matched to the right key' are helpful but largely paraphrase the schema descriptions. It adds minimal new semantic meaning 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: 'Verify a JWT signature and claims' and explicitly names the classic token attacks (alg none, HMAC confusion, unbounded lifetime, missing audience). This clearly separates it from siblings like cve_check or webhook_signature.

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 for when to use this tool (any JWT verification task) and even adds a nuance: without a key, it decodes and judges claims but reports the signature as unverified rather than assuming good. However, it does not mention alternatives or exclusions compared to sibling 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?

The description richly discloses behavior beyond annotations: how multi-license expressions are handled (AND/OR), unknown licenses are reported as 'unknown' rather than harmless, the data source (deps.dev) and its limitation, and a disclaimer that it is not legal advice. It aligns with readOnlyHint/openWorldHint and adds substantive context.

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

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

The description is informative but verbose, with redundant pricing statements (mentioned twice in German) and a mixed English/German structure. The opening purpose is front-loaded, but the repetition and extra pricing details detract from conciseness.

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

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

The description provides extensive behavioral context and limitations, covering classification logic, unknown handling, and disclaimers. However, with no output schema, it does not explicitly describe the return format or structure, leaving a moderate 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 100%, so the baseline is 3. The description indirectly references the 'usage' parameter by explaining network copyleft (AGPL) implications, but does not add syntax-level detail beyond the schema for packages or ecosystem. No significant added meaning.

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 clearly states the tool's function: 'Resolve package licences and classify them for commercial use' with specific categories (disclosure, attribution, unknown). This distinguishes it from sibling tools like cve_check and tls_chain, which address different concerns.

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

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

The description provides strong context for when to use the tool: for a 'closed, sold product' and evaluating what each license demands. It explains scenarios (permissive, weak copyleft, strong copyleft, network copyleft) but does not explicitly state exclusions or alternatives to other 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?

Beyond the read-only/no-destructive annotations, the description discloses paid usage via x402 (0.002 USDC per call), support for multiple JSON Schema drafts, separate reporting of wrapping vs schema errors, and optional repair suggestions. This adds significant behavioral context not present in 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?

The description is front-loaded with a strong purpose statement, but pricing information is repeated twice, once in English and twice in German, adding redundancy. The extra German paragraph does not earn its place, though the rest is well organized.

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

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

The description covers input modes, unwrapping behavior, schema draft support, repair options, limitations, and return contents (paths, rules, wrapping). With no output schema, it gives a reasonable but not exhaustive picture of the response shape, leaving some detail to the agent's expectation.

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

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

Schema coverage is 100%, giving baseline 3. The description adds value by explaining the output/output_text mutual exclusivity and that wrapping is reported separately, which clarifies the combined behavior beyond individual parameter descriptions. It also specifies that suggest_repairs covers defaultable missing fields and extra fields.

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

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

The opening sentence clearly states a specific action: checking a model answer against a JSON schema, reporting deviations in plain language with paths, and noting wrapping. This distinguishes it from sibling tools like tool_arg_validate by focusing on model outputs and wrapping detection.

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

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

The description provides clear usage context: it accepts parsed or raw model output, handles code fences/prose, and explicitly limits itself to structure ('never truth'), telling users not to use it for factual verification. It does not name alternative tools, but the boundary is clear.

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

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

The description explicitly lists 'set' and 'delete' actions and says 'Every write carries...', but annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction: the tool is described as mutating state, so the read-only hint is misleading. Although the text offers rich behavioral detail (TTL cleanup, found=false, namespace unauthenticated), the contradiction forces a score of 1 per rubric.

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 front-loaded with the core purpose and includes useful details, but it repeats the pricing/cost statement twice ('Kostenpflichtig...' and 'Preis...') and contains slightly disjointed German/English phrasing. It is reasonably sized but not every sentence earns its place.

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

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

No output schema exists, but the description compensates by explaining the get behavior on missing/expired keys (found=false), removal behavior on access, 64 KB size limit, and 1000-key cap. It gives enough context for an agent to select and use the tool, though it could state error behavior for invalid actions or oversize values.

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 100% schema coverage, the baseline is 3; the description adds value by enumerating the valid actions ('set, get, list, delete'), which the schema leaves as the vague 'What to do.' It also reinforces action-specific requirements (key for set/get/delete, value for set, TTL max) and adds the 1000-key limit. This goes beyond the schema without being 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?

The description opens with a specific verb phrase—'Store, read, list and delete small pieces of agent state under a namespace'—and adds the key constraint 'mandatory expiry.' This clearly identifies the resource (agent state) and the supported operations, distinguishing it from sibling tools like web_archive and cve_check.

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 intended use case: 'Key-value state for agents that need to survive between calls.' It also gives exclusions: no permanent storage (30-day TTL max) and not for secrets ('do not put secrets in it'). It doesn't name an alternative tool, but no obvious sibling provides this function.

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

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

The description discloses significant behavioral context beyond the annotations: it opens a network connection, is a paid operation (0.002 USDC per call via x402), and provides details about chain validation implications (e.g., missing intermediates). Annotations only declare readOnly and not destructive, so this added transparency is valuable and not contradictory.

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 front-loaded with a clear summary, but it contains redundant pricing information stated twice in German ('Kostenpflichtig...' and later 'Preis...'). The long final paragraph, while informative, could be tightened to avoid repetition and improve scannability.

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 there is no output schema, the description provides a comprehensive list of what is reported: per-certificate details, hostname coverage, expiry days, self-signed/weak algorithm flags, missing intermediates, protocol version, and cipher. This is almost complete, though the exact output format is not specified.

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 input schema has 100% description coverage for all four parameters, so the baseline is 3. The description does not add parameter-specific semantics beyond mentioning 'expiry warnings' and 'days remaining' which loosely relate to warn_days, but it does not improve on the schema's own descriptions.

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

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

The description opens with a specific verb and resource: 'Read the TLS certificate chain of a host', listing the exact information returned (names, validity, key type, signature, expiry warnings, hostname coverage). This clearly distinguishes it from sibling tools like cve_check or jwt_verify, which address different security concerns.

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 for use by explaining that it connects directly to the host, has no third-party dependency, and no rate limit, implying reliability and self-contained operation. However, it does not explicitly state when to use this tool over alternatives or when not to use it, so it stops short of full guidance.

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

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

The description discloses the two-stage behavioral process (schema validation and heuristic warnings) and importantly notes that warnings can be wrong in both directions, which is critical for interpretation. This goes beyond the readOnlyHint annotation by explaining how results should be used. It also adds pricing and x402 payment details, providing operational context.

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

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

The description is front-loaded with its main purpose, but it contains redundant pricing information in both German and English, duplicating the same cost details. The structure is organized around the two checks, but the repetition and mixed-language content reduce efficiency.

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 with 5 parameters and no output schema, the description adequately covers its purpose, behavioral details, limitations, and usage context. It explains what the tool does, when to use it, and its caveats. It doesn't detail the return format, but this is acceptable given the absence of an output schema and the presence of annotations.

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 already has 100% coverage with descriptions for all 5 parameters, so the baseline is 3. The description adds value by explaining that fields suggesting irreversible effects are held to stricter standards, which gives additional meaning to parameters like 'irreversible' and helps the agent understand how field names might trigger heuristics. This slightly enhances the schema's semantics.

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

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

The description clearly states the tool's function with a specific verb ('Check') and resource ('tool arguments against their schema'). It also adds the usage context of expensive/irreversible calls, which distinguishes it from sibling tools like output_validate.

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 explicitly says to use it 'before an expensive or irreversible call,' providing clear usage context. It also includes a caution that warnings are heuristics and not a substitute for the tool's own checks, which implies when not to fully trust it. However, it does not explicitly name alternative tools or state strict exclusion criteria.

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

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

The description discloses important behavioral traits beyond the annotations: it mentions CDX index stability issues, fallback to the availability endpoint, reporting of degraded state, separation of error captures, and content-digest logic. These details go well beyond the read-only/open-world 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?

The description is front-loaded with a clear summary, followed by a logically organized detailed explanation. However, pricing information is duplicated (once as 'Kostenpflichtig' and again as 'Preis'), adding redundancy and slightly bloating the text.

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

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

Since there is no output schema, the description thoroughly explains what is returned (capture time, HTTP status, MIME type, content digest), the target-date gap in days, error separation, and degraded-mode reporting. It covers all essential aspects for an agent to invoke the tool correctly.

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

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

The schema already covers all 7 parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds meaning for key parameters like `target_date` (returns nearest snapshot with gap in days), `changes_only` (content digest logic), and `include_errors` (separating error captures). It does not elaborate on `limit` or date range parameters, but the overall context compensates.

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 begins with a specific, compound action: 'List archived versions of a URL with dates, status codes and content changes, and get the snapshot closest to any date you name.' This clearly identifies the resource (archived versions) and the operations (list and get). It is distinct from sibling tools, which focus on cost, validation, and other concerns.

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

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

The description provides clear contextual use cases, such as 'what a citation of a page as it stood on a given day needs' and explains that the changed-versions list is 'the list worth reading.' However, it does not explicitly mention alternatives or when not to use the tool, though the niche is well-defined relative to 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?

The description goes well beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) by disclosing security and behavioral details: constant-time comparison, timestamp tolerance window, returning the exact signed string for debugging, and the requirement for byte-for-byte body preservation. It also explains the consequences of re-serialization, which is critical for correct use. The annotations are consistent with the described read-only verification 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?

The description is front-loaded with the core purpose, but it repeats pricing information three times (Kostenpflichtig, Hoechstens, and Preis at the end) in a way that feels redundant. The technical explanation is valuable but could be trimmed to a more concise format. The structure is reasonably organized but not every sentence earns its place, so it is not a model of conciseness.

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 8 parameters, no output schema, and supports multiple providers. The description covers major pitfalls (body serialization, timestamp tolerance, signing string order) but does not fully describe the return value beyond 'returns the string that was signed'. It also does not address error handling or what happens when verification fails, which is important for an agent to know given the absence of an output schema. Thus it is adequate but has clear gaps for this complexity.

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 100% schema coverage, the baseline is 3, but the description adds valuable semantics beyond the schema. It explains that providers build signing strings differently (body-only vs. prepending timestamp, id, or version), which directly maps to parameters like timestamp, message_id, and signature. It also clarifies why the body must be exact, enriching understanding of the 'body' parameter. However, it does not detail each parameter individually, so it falls short of 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?

The description clearly states the tool's action: 'Verify a signed webhook' and enumerates specific providers (GitHub, Stripe, Shopify, Slack, Svix) as well as plain HMAC. This is a specific verb+resource that distinguishes it from sibling tools like jwt_verify, which handles JWT tokens rather than webhook signatures.

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

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

The description provides clear context for when to use the tool: any time a signed webhook from the listed providers needs verification. It does not explicitly mention when not to use it or name alternatives, but the provider list and the distinctive description of signature construction give sufficient situational guidance. The note about passing the body exactly as received is also a usage hint.

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