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

No annotations provided, so the description must fully disclose behavior. It explains it uses a language model, returns corrected text and edits, supports style modes, and has character limits per tier. However, it does not mention rate limits, authentication needs, or potential side effects beyond what is described.

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 well-structured with separate sections for input, output, and tiers. It is front-loaded with the main purpose. However, it is slightly verbose with repetition (e.g., 'Check and rewrite' appears twice). Still, it is clear and 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?

Given the absence of an output schema, the description fully details the return structure ('corrected', 'edits', 'chars_in', 'chars_out') and explains the edits list composition. It also covers character limits for free and pro tiers, providing a complete picture of tool behavior.

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 fully explains both parameters: 'text' as the input text, and 'style' with a list of options and defaults. It adds significant meaning beyond the schema's minimal type definitions.

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 checks and rewrites text for grammar, spelling, punctuation, and style. It also describes the output (corrected text and edit list). It is distinct from sibling tools which are validation, lookup, and other text processing tools like translate or summarize.

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 does and its style options, but does not provide guidance on when to use this tool versus alternate sibling tools (e.g., translate_text, summarize_text, redact_text). No explicit when-to-use or when-not-to-use 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?

No annotations provided, so description carries full burden. Detailed explanation of k-anonymity method (only first 5 chars of SHA-1 hash sent), local comparison, and that full password never transmitted. Discloses data source (HaveIBeenPwned etc.).

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?

Well-structured with paragraphs for purpose, method, usage, and returns. Some redundancy could be trimmed (e.g., 'the full password and hash are never transmitted' appears twice), but still efficient and clear.

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

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

Comprehensive for a sensitive security tool. Explains method, return values (breached bool and count), interpretation of count, and limitations (not a guarantee of safety). No output schema, so description covers returns adequately.

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 has 0% coverage for parameter descriptions. The description adds essential meaning: password is transmitted as partial hash only, never plaintext. Explains the security mechanism for the single parameter.

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?

Clearly states 'check if a password has appeared in known data breaches' with specific verb and resource. Distinguishes from sibling tools like validate_email, dns_lookup, etc., which are unrelated.

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 advises use cases: 'validate new passwords at registration or prompt users to change a compromised credential.' Also implies safety due to k-anonymity, guiding appropriate use.

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?

No annotations provided, so description fully carries burden. It clearly states it does NOT verify signature, lists accepted input formats (compact and bearer), and details all return fields including is_expired, expires_at, etc.

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?

Well-structured with 'Args' and 'Returns' sections. The security warning is a single sentence. Every sentence provides value without redundancy.

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

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

For a simple tool with one parameter and no output schema, the description fully covers input specification, return fields, and crucial behavioral details (no verification). It is complete and self-contained.

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?

Only one parameter (token) with 0% schema description coverage. Description compensates fully by explaining token format: 'JWT string (three base64url-encoded sections separated by dots). Both compact and bearer format are accepted.' This adds crucial meaning beyond the raw 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?

Description clearly states 'Decode a JWT without signature verification' and explains it parses header and payload. It effectively distinguishes the tool from unrelated siblings by specifying its exact function.

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 states when to use: debugging authentication issues, inspecting claims, checking expiry. Also provides important when-not: 'Do NOT use this to make security decisions about whether a token should be trusted.'

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?

With no annotations, the description carries the behavioral disclosure burden. It states the tool queries authoritative DNS servers and returns records with TTL and query time, implying a read-only network operation. However, it omits details like rate limits, caching behavior, or error handling, leaving some transparency 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?

The description is well-structured with clear sections (Args, Returns), uses bullet points for clarity, and every sentence adds value. It is appropriately succinct for the complexity of the 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?

Given the simple 2-parameter schema and no output schema or annotations, the description covers the tool's purpose, parameters, return format, and use cases comprehensively. Minor omissions like error handling or authentication requirements are acceptable for a read-only DNS lookup tool.

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

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

The input schema has 0% description coverage, but the tool description extensively documents both parameters: domain with examples, record_types with supported types and detailed explanations (including defaults and example values). This adds significant 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 clearly states the tool's function: 'Look up DNS records for a domain across multiple record types.' It also lists specific use cases (email deliverability, domain ownership, CDN configuration, propagation status), distinguishing it from sibling tools like whois_lookup or ssl_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 explicitly mentions when the tool is useful (diagnosing email deliverability, verifying domain ownership, etc.), providing practical context. However, it does not explicitly state when not to use it or mention alternative sibling tools, which would improve 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?

No annotations are provided, so the description fully carries the burden. It discloses that hashing is performed server-side, output is hex-encoded, and results are consistent. It does not mention any destructive actions or side effects, which is appropriate for a pure computation 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?

The description is well-structured with a clear opening sentence, followed by a use case paragraph, then parameter details in a list format. It is relatively concise for the amount of information, though the parameter documentation could be slightly condensed.

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 explicitly lists the return fields (algorithm, hex, length). It also covers parameter details and behavior. With no annotations, this description is complete and leaves no obvious gaps for an agent to invoke or 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?

Schema coverage is 0% (no descriptions in schema), so the description fully compensates. It explains both parameters: 'data' with UTF-8 encoding, and 'algorithm' with all options, defaults, and security notes. This adds significant 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?

Description clearly states 'Hash a string with a cryptographic hash algorithm.' It provides a specific verb (hash) and resource (string), lists multiple algorithms, and distinguishes itself from sibling tools which are unrelated (e.g., validate_email, dns_lookup).

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?

Description mentions use cases such as verifying data integrity, creating fingerprints, and generating identifiers. However, it does not specify when not to use this tool or provide explicit alternatives among the sibling tools, though no sibling is a direct competitor.

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?

With no annotations, the description carries full burden. It discloses generation behavior, format differences, color support, error correction level, and size limitations. Transparent background note for PNG only is good. Could mention any rate limits or auth requirements, but none apparent.

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 well-structured with a summary, details, and return info. It's somewhat lengthy but every sentence adds value. Could be slightly more concise, but clarity is prioritized.

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

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

Given the simplicity of the tool (generate and return base64), the description covers all needed aspects: input parameters, format options, output description. No missing critical information.

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%, but the description's Arg section thoroughly explains each parameter: url (content examples), size (default, range, SVG behavior), format (choices), fg and bg (hex defaults, transparent for PNG). This adds significant meaning beyond the bare 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 clearly states it generates a QR code and returns it as a base64-encoded image. It specifies supported formats (PNG, SVG), customization options, and error correction level. No sibling tool does QR generation, so it's unique and distinguishable.

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

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

The description implies this tool is for creating QR codes from various payloads. While it doesn't explicitly state when not to use it, the uniqueness among siblings makes this less critical. A brief note on alternatives (if any) would improve it.

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?

Describes standards compliance, entropy, and ordering characteristics. No annotations provided, so description carries full burden, which it meets well. Slight gap: does not mention if v1 includes MAC address exposure.

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 concise sections (purpose, args, returns) with clear formatting. Every sentence adds value; no fluff.

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?

Tool is simple (1 param, no output schema), and description covers purpose, parameter semantics, and return value structure comprehensively.

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?

Despite 0% schema coverage, the description fully details the single parameter `version` with meanings, default, and trade-offs for each option.

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 generates UUIDs and lists multiple use cases (database keys, idempotency tokens, etc.), distinguishing it from sibling tools like validate_email or dns_lookup.

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 explicit guidance on when to use each UUID version: v1 for time-sortable IDs, v4 for general-purpose, v7 for monotonic ordering and better database index locality.

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?

Describes rendering in headless Chromium, CSS support, default A4 page size, and base64 return. No annotations exist, so description carries full burden; it adds sufficient behavioral context but omits potential limitations (e.g., timeouts, resource loading).

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?

Description is front-loaded with purpose and behavior, followed by structured Args and Returns sections. It is slightly longer than necessary but well-organized and free of 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?

Covers purpose, parameter details, behavioral notes, and return format. With an output schema present, it does not need to detail PDF structure. Missing minor aspects like error handling or dependency on external resources (e.g., fonts).

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?

Despite 0% schema coverage, the description's Args section fully explains the html parameter: expects a complete HTML document, recommends style block and @media print CSS. This adds rich context beyond the schema's minimal type definition.

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?

Clearly states it converts HTML to PDF and returns base64 string. Specifies use cases (invoices, reports) but does not explicitly differentiate from sibling tools like screenshot_url.

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 typical use cases but no guidance on when not to use or alternatives. Context signals show siblings like screenshot_url cover similar needs, but no exclusion criteria are mentioned.

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?

No annotations are provided, so the description carries full burden. It explains the output fields (geolocation, threat signals, composite score) and coordinate precision (city-level). It does not discuss authentication, rate limits, or potential side effects, but as a read-only lookup, these are less critical.

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 well-structured as a Google-style docstring with a concise summary, bulleted return fields, and usage scenarios. Every sentence adds value, no fluff, and critical information is front-loaded.

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 tool with one parameter and no output schema, the description is complete: it enumerates all return fields with descriptions, notes coordinate precision, and explains the threat score range. No critical gaps for its 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?

Schema description coverage is 0%, but the description compensates fully by specifying the parameter format ('IPv4 or IPv6 address') and providing concrete examples ('8.8.8.8', '2001:4860:4860::8888'). This adds significant meaning beyond the bare schema type.

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 'Geolocate an IP address and detect VPN, Tor, and datacenter usage.' It specifies both geolocation and threat detection, distinguishing itself from siblings like dns_lookup and whois_lookup by focusing on IP intelligence and composite threat score.

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 lists concrete use cases: fraud detection, access control, region-based personalization, and investigating suspicious traffic. It implies contexts where this tool is appropriate but does not explicitly state when not to use it or mention 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?

No annotations are provided, so the description carries full burden. It discloses that it assumes UTC unless a POSIX TZ string is prepended, returns 5 next runs, and lists returned fields. It implies a read-only, stateless operation, which is appropriately transparent.

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 well-structured with an overview, an 'Args' section, and a 'Returns' section. It is detailed yet concise, with every sentence adding value and 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?

Given one parameter and no output schema, the description thoroughly documents input options and briefly describes output fields (description, next_runs, fields, timezone). It could provide more details on output format (e.g., datetime string format), but is largely complete for agent use.

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

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

The single parameter 'expression' has 0% schema description coverage. The description compensates fully with detailed examples: 5-field, 6-field, special strings, ranges, step values. This provides extensive meaning beyond the schema's bare type definition.

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 it parses cron expressions and returns next execution times with a human description. It specifies supported formats (5-field, 6-field, special strings, ranges, step values), distinguishing it from sibling tools that handle validation, DNS, SSL, etc.

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 states use cases: validating cron jobs, explaining schedules, debugging scheduler configuration. While it doesn't list exclusions, the sibling tools are unrelated, so usage context is sufficient.

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 notes that it fetches the page and parses metadata, implying an HTTP request. However, it does not disclose potential timeouts, error handling, or rate limits. With no annotations, more behavioral detail would be beneficial.

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 well-structured with sections for Args and Returns, front-loading the purpose. It is somewhat lengthy due to the detailed return field list, but remains organized and focused.

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 or annotations, the description fully covers purpose, usage, parameter constraint, and return structure. It addresses the tool's complexity and expected context adequately.

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 has 0% coverage for the single parameter 'url'. The description adds critical semantics: 'Full URL of the page to parse (must include https://)', specifying format and requirement 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 clearly states the tool extracts Open Graph, Twitter Card, and standard meta tags from a URL, specifying the verb and resource. It is distinct from siblings like validate_email or dns_lookup.

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 lists use cases: link preview generation, SEO auditing, and validating social sharing metadata. It does not mention when not to use or alternatives, but provides clear context for appropriate usage.

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?

Discloses algorithm source (Mozilla's Readability) and behavior (strips navigation/ads/boilerplate). No annotations exist, so description carries the burden. Lacks details on error handling (e.g., non-article pages, rate limits) but sufficient for typical use.

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?

Well-structured with two paragraphs: purpose/behavior then parameter/return details. Slightly verbose (e.g., 'Args' and 'Returns' sections repeat schema info), but each sentence adds value.

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 single required parameter, no output schema, and no annotations, the description fully covers all necessary information: input format, return fields with descriptions, and expected behavior. No gaps identified.

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?

Only one parameter (url) with schema coverage 0%. Description adds full semantics: 'Full URL of the article or page to extract (must include https://)'. This completely compensates for the missing schema 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?

Clear verb 'Extract the main article text and metadata from a web page' with specific resource. Distinguishes itself from siblings (e.g., parse_og_tags, screenshot_url) by focusing on prose extraction.

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 states ideal use cases: summarising articles, building reading lists, feeding into AI processing. No alternative tool is named, but the context signals show diverse sibling tools that clearly differ in purpose.

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

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

No annotations provided, so the description carries the full burden. It details detection methods (NER and pattern matching), covers a comprehensive list of PII types, and describes replacement style (labelled placeholders). However, it lacks discussion of limitations, performance, or error handling.

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 well-structured with sections for use cases and return values. It is informative without being verbose, though the Args and Returns sections are slightly redundant given the 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?

Given the moderate complexity and lack of output schema, the description adequately covers functionality, usage, and return values. It does not mention concurrency, rate limits, or privacy, but is complete for its purpose.

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%, but the description compensates by explaining the 'text' parameter: 'Text containing PII to redact. Handles mixed content including structured data embedded in natural language.' This adds 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 clearly states the function: redact PII from text. The verb 'redact' is specific, and the resource 'text' is explicit. It distinguishes from sibling tools, which are unrelated (e.g., validate_email, ssl_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 explicitly suggests use cases: 'before logging user input, storing support tickets, or sharing data with third parties.' This provides clear guidance on when to use, though it does not mention alternatives or when not to use.

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?

With no annotations, the description fully discloses behavior: headless Chromium, JavaScript execution, waits for network idle, captures viewport or full page, performance warning for long pages. Return fields are also described. No contradictions.

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?

Description is well-structured with a clear lead sentence, followed by technical details, then argument and return descriptions. Slightly lengthy but each sentence adds value. Could be slightly tighter, but still good.

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, but description explains all return fields (png_b64, w, h, bytes, ms). Covers key constraints and performance hint. Fully 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 0%, so the description must and does add meaning for all 4 parameters. It documents the URL requirement (https://), ranges and defaults for width/height (320–3840, 200–2160), and the full_page effect and performance trade-off.

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?

Description uses specific verb 'Capture a screenshot' and resource 'web page', clearly stating it returns base64 PNG. It lists concrete use cases (visual regression, archiving, previews, AI analysis). No sibling tools perform similar function, so no confusion.

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

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

The description implies when to use: for capturing page state, visual checks, or AI analysis. It does not explicitly state when not to use or provide alternatives, but given the uniqueness of the tool among siblings, it 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?

With no annotations, the description must disclose behavior. It mentions handling negation, sarcasm, and mixed sentiment, and uses a fine-tuned model. It does not cover rate limits, authentication, or error handling, but for a text analysis tool these are less critical. The transparency is high overall.

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 well-structured with clear sections and bullet-like formatting for parameters and returns. It is moderately concise; a few phrases could be trimmed (e.g., 'Uses a fine-tuned language model' is implied), but overall it communicates efficiently without unnecessary 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?

Given the absence of an output schema and annotations, the description comprehensively covers the tool's purpose, inputs, behaviors, and outputs. It provides usage context, parameter details, and return field descriptions, making it fully self-contained for an agent to invoke 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 has 0% description coverage, so the description carries full responsibility. It explains the 'text' parameter in detail: what it is (text to analyse), optimal range (10–2000 chars), and how to handle longer inputs. It also fully documents return fields (label, compound, confidence, positive/negative/neutral proportions), adding significant value.

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: 'Analyse the emotional tone and sentiment of a piece of text.' The verb 'analyse' and resource 'sentiment' are specific. It distinguishes from sibling tools, which are unrelated (e.g., validate_email, dns_lookup), making selection 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 lists suitable text types (reviews, social posts, etc.) and provides an optimal character range (10–2000). It advises splitting long documents, which is useful guidance. While it doesn't explicitly state when not to use the tool, the context is clear enough for an agent to decide.

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?

With no annotations, the description carries full burden. It fully discloses behavior: connects on port 443, retrieves full chain, and lists all returned fields including validity, expiry countdown, issuer, SANs, and cipher suite info.

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 well-structured with a clear intro and bullet points for arguments and returns. It is front-loaded with purpose. While slightly lengthy due to listing all return fields, each sentence earns its place.

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

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

Given one parameter, no output schema, and no annotations, the description thoroughly covers purpose, parameter usage, and return values. It provides sufficient detail 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 single parameter 'host' has no schema description (0% coverage). The description compensates by providing clear guidance: include only hostname, exclude protocol and path. This adds significant meaning beyond the raw 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 clearly states the tool's function: inspecting SSL/TLS certificates for a host. It specifies connecting to port 443 and retrieving the certificate chain. This distinguishes it from sibling tools like dns_lookup or whois_lookup.

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 explicit use cases: monitoring certificate expiry, verifying installation, checking SANs, and auditing cipher strength. However, it does not mention when not to use or alternative 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?

No annotations are provided, so the description carries the full burden. It explains the approach (extractive and abstractive), constraints (input length, max_sentences range, potential fewer sentences), and return structure (summary, sentences, compression_ratio, key_points). No contradictions.

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?

Description is concise yet comprehensive, using clear sections for intro, use cases, parameters, and returns. No wasted sentences; every line adds 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?

Despite no output schema, the description fully documents return values. Covers purpose, usage, parameters, and behavior. No gaps 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?

Schema has 0% description coverage. Description adds full meaning: text parameter gets usage guidance and content type, max_sentences gets default, range, and behavior note. Also describes all return fields. Completely compensates for missing schema 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?

Description clearly states the tool summarizes a long document into key points. It lists specific use cases (news articles, reports, etc.) and distinguishes from all sibling tools, which are unrelated (e.g., validate_email, dns_lookup).

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 suitable contexts (news, reports, transcripts) and input length recommendation (200+ words). Does not explicitly exclude contexts or mention alternatives, but sibling tools are all different so no ambiguity.

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?

Describes methods (HTTP headers, meta tags, JS fingerprints, resource paths) and notes the scan does not crawl, only the homepage is needed. No annotations are provided, so the description carries the full burden; it adequately discloses behavior without contradictions.

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?

Well-structured with a clear purpose sentence, followed by method details, use cases, and a docstring for parameters and return values. Every sentence adds value without unnecessary verbosity.

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 one parameter and no output schema, the description fully explains input requirements and return structure (list of technologies with name, category, confidence, version). It is complete and self-contained.

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?

Despite the schema having 0% description coverage, the description includes a detailed parameter doc: 'Full URL of the site to analyse (must include https://). The homepage is usually sufficient; the scan does not crawl.' This adds essential 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 clearly states 'Detect the technology stack powering a website', specifying the verb 'Detect' and resource 'technology stack'. It distinguishes from sibling tools (e.g., dns_lookup, ssl_check) by focusing on stack identification.

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 lists use cases (competitive research, sales prospecting, migration planning) and notes the tool is for understanding a client's stack. It does not directly state when not to use, but given sibling context, the intended usage 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?

With no annotations, the description carries full burden. It discloses important behaviors: preserves paragraph structure, handles HTML entities, uses NMT, and supports auto-detection. It does not mention rate limits or auth, but covers key aspects.

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 well-structured with a high-level summary, followed by clear Args and Returns sections. It is concise, with every sentence adding value and 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?

The description is fully complete given the tool's complexity and lack of output schema. It covers all parameters, explains the return format, and provides usage context. No gaps remain.

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

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

The description adds significant meaning beyond the sparse input schema. It explains that text may include multiple paragraphs, gives example BCP-47 codes for target, and specifies the default for source ('auto'). This compensates for the 0% schema description 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?

The description clearly states that the tool translates text between languages using neural machine translation, supports 100+ languages, auto-detection, and preserves structure. It also lists specific use cases, distinguishing it from unrelated sibling tools.

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 when-to-use guidance (document translation, multilingual content, international users) but does not explicitly mention when not to use or suggest alternative tools. However, the sibling tools are all different, so confusion is unlikely.

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?

No annotations are provided, so the description carries full burden. It details the multi-layer validation process and return values. Could be improved by mentioning network dependency or rate limits, but overall it discloses key behaviors.

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 well-structured with clear sections for checks, usage, args, and returns. Slightly lengthy but every sentence adds value. Front-loaded with the main purpose.

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

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

For a single-parameter tool with no output schema and no annotations, the description covers purpose, methodology, return fields, and use cases comprehensively. An agent has all needed information 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 0%, so the description must compensate. It explains the 'email' parameter with example and context, adding meaning beyond the schema's type-only definition. It could mention accepted formats or encoding but is sufficient.

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 it validates email for deliverability and quality, listing specific checks (RFC-5322, MX, disposable, role). This verb+resource description distinguishes it from sibling tools like dns_lookup or whois_lookup which are not email-specific.

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 recommends use before email campaigns, signups, or list cleaning. While it doesn't explicitly state when not to use or mention alternatives, the context is clear enough for an agent to decide.

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?

With no annotations, the description fully covers behavioral traits: validates checksum/structure, allows spaces, returns decoded components, and explicitly states it does not check account activity. No contradictions.

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 well-structured with a summary, note, args, and returns sections. It is concise with no redundant sentences; every sentence adds value.

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

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

Given the tool has one parameter and no output schema, the description is thorough. It lists all return fields (valid, iban, country_code, etc.), explains the validation scope, and notes limitations. It is complete for its purpose.

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 provides no description for the 'iban' parameter (0% coverage). The description adds detailed semantics: explanation of the parameter, that spaces are allowed and ignored, and provides example values, significantly aiding the agent.

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 validates and decodes IBANs, with a specific verb and resource. It distinguishes itself from siblings by focusing on IBAN specifically, which is different from email validation or DNS lookups.

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 explains what the tool validates (checksum and structure) and explicitly notes it does not confirm account existence ('does not confirm the account is live or funded'). This provides when-to-use and limitations, though it lacks explicit when-not-to-use mentions.

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?

With no annotations provided, the description fully carries the burden. It discloses real-time VIES query, potential 'SERVICE_UNAVAILABLE' during maintenance, a 'source' field indicating cached fallback, and details on return fields. This provides comprehensive behavioral insight.

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 well-structured with a front-loaded purpose sentence, followed by context, notes, and parameter/return details. While slightly verbose, every sentence adds value. It earns a high score for clarity and logical flow.

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 lists all expected return fields (valid, country_code, vat_number, company_name, address, request_date) and mentions edge cases ('---' if VIES withholds). For a single-parameter tool with no output schema, this is complete.

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

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

Schema coverage is 0%, but the description compensates fully. It explains the vat_number parameter in detail: includes two-letter country prefix, provides examples ('GB123456789', etc.), and notes that spaces and dashes are ignored. This adds significant 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 uses a specific verb 'Validate' and resource 'European VAT registration number', clearly distinguishing it from sibling validation tools (e.g., validate_email, validate_iban) by specifying 'European VAT' and use cases like 'B2B invoice validation'.

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

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

The description explicitly states when to use the tool: 'Essential for B2B invoice validation, zero-rating intra-EU supplies, and customer due diligence.' It does not explicitly state when not to use or list alternatives, but the context from sibling tools makes the usage 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?

No annotations are provided, so the description carries full burden. It discloses GDPR redaction effects on contact details and notes that technical data is always available, providing transparency beyond the basic action.

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 efficiently structured with an intro, a note, and clear Args/Returns sections. It is front-loaded with the main purpose and every sentence adds value without redundancy.

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

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

Despite no output schema, the description details all expected return fields with types and notes. It covers limitations (GDPR), making it complete for a look-up tool of moderate 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?

The single parameter 'domain' is described with format and example ('example.com') and TLD support, adding significant meaning beyond the schema's type definition. Coverage is 0% in schema, but description fully 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 clearly states the tool retrieves WHOIS registration data for a domain name, using a specific verb and resource. It is distinct from sibling tools like dns_lookup or ip_lookup, with no ambiguity.

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 lists use cases such as domain due diligence, expiry checking, and registrar identification. While it does not explicitly state when not to use the tool or mention alternatives, the context is clear and actionable.

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