IntoDNS.ai DNS & Email Security Scanner

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

Annotations already mark read-only/idempotent/non-destructive; description reinforces with 'Read-only analysis' and adds key operational facts: in-memory processing, no storage, no auth. This exceeds minimal disclosure.

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

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

Dense, front-loaded description: purpose first, output summary, usage rule, then operational constraints. No wasted words; 5 sentences carry high 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?

For an analysis tool with no output schema, the description enumerates the major parsed categories and the final outputs (0-100 score, fix suggestions), plus one-param usage. It covers the tool's behavioral contract sufficiently.

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, and the input schema already fully describes rawEmail's content and max length. Description merely restates max 500KB, so it adds little beyond 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 states 'Read-only analysis of a pasted raw RFC-5322 MIME email source' with a specific verb and resource, and lists concrete outputs. It differentiates from create_email_test in the same tool family.

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

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

Explicitly states when to use: to debug a specific failing email when user can paste raw source; names create_email_test as alternative when resending is possible. This is ideal usage guidance.

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

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

Even with annotations already saying readOnly, idempotent, and non-destructive, the description adds concrete behavioral detail: 'fetches the page once over HTTPS, nothing is changed.' It also discloses the return structure (header presence/values, missing list, recommended config, server snippets), going well beyond the annotation hints.

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

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

The length is on the high side and includes a list of example headers, which is somewhat redundant for AI agents with common web security knowledge. However, the structure front-loads the core function, then gives behavioral detail, return summary, and usage guidance in a coherent flow. Each section earns its place, though tightening could help.

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

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

With no output schema, the description compensates by enumerating the exact return items (HTTPS status, each header with present/missing and value, missing list, recommended config, copy-paste snippets). Along with a single simple parameter and abundant annotations, this is fully sufficient for an agent to invoke 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?

Schema coverage is 100% and the schema's parameter description already states 'Domain name only, e.g. example.com (no URL, path, or port).' The tool description adds context about HTTPS and live scanning but does not add new parameter syntax or constraints, 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 opens with a specific action and resource: 'Scan a live website and report which HTTP security headers it currently sends.' It clearly distinguishes itself from the closely related sibling generate_security_headers by focusing on auditing a live site rather than generating a config.

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?

Ends with explicit when-to-use guidance: 'Use this to audit a real site's header posture; use generate_security_headers when you just want a fresh best-practice config...' This directly names the alternative tool and the deciding condition, which is ideal for an agent.

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

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

Annotations already indicate idempotent and destructive behavior, but the description adds valuable context: 'Idempotent DELETE — safe to call even if scan already finished or never started (returns acknowledgement either way)' and 'No auth, no side effects beyond freeing the upstream job slot.' This discloses the behavioral traits and side effects clearly, going beyond the structured fields.

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

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

The description is three concise sentences, front-loaded with the primary purpose, followed by idempotency, usage, and side-effect details. Every sentence earns its place with zero 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?

This is a simple one-parameter tool with annotations and a schema. The description covers purpose, usage timing, safety, side effects, and auth requirements, making it complete for an agent to decide when and how to invoke the tool.

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

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

Schema coverage is 100% with a clear description for scanId ('Deep scan ID returned by start_deep_scan'). The tool description merely repeats this ('Requires scanId returned by start_deep_scan'), adding no new semantic information. Baseline 3 is appropriate.

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

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

The description clearly states the action: 'Cancel an in-progress Internet.nl deep scan.' It uses a specific verb (cancel) and resource (deep scan), and distinguishes itself from related tools like start_deep_scan and get_deep_scan_status by describing its role. 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?

Explicitly states when to use: 'Use when the user changes their mind mid-scan or when polling get_deep_scan_status would otherwise time out.' It also contrasts with the sibling tools and notes the tool's idempotent nature, providing clear context for when it's safe to call.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior, and the description reinforces this with 'No auth or destructive actions' and 'safely fetches'. It also discloses output scope and limitations, adding behavior context beyond the annotations.

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

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

Every sentence contributes value: definition, behavior, outputs, limitations, and use case. It is appropriately compact for a multi-step readiness checker and front-loads the core purpose before diving into specifics.

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

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

With no output schema, the description carries the burden of explaining expected results, and it does so thoroughly: syntax, reachability, content type, certificate metadata, and explicit issues. It also contextualizes the check within a formal review process, making the tool self-sufficient.

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

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

Input schema covers the single `domain` parameter 100% including maxLength and format guidance. The description adds meaning by connecting the parameter to the `default._bimi` record lookup and overall check flow, going slightly beyond the schema baseline.

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

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

The description opens with 'Read-only BIMI readiness check' and specifies the exact resources involved: `default._bimi` TXT record, referenced HTTPS SVG, and optional VMC/CMC certificate. This clearly distinguishes it from sibling tools like check_spf or check_dmarc.

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 says 'Use for a technical preflight before a formal BIMI/VMC review' and enumerates what it deliberately does not do, such as certifying SVG Tiny PS compliance or validating the full trust chain. This gives the agent clear when-to-use and when-not-to-use guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive. The description adds valuable context: noisy providers are disabled, and it returns evidence of unavailable/disabled providers so timeouts aren't misreported as clean. This goes beyond the annotation baseline.

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

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

Five sentences, each serving a purpose: scope, input specification, output details, usage intent, and safety. Front-loaded with the core purpose. Zero 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 tool with no output schema, the description fully explains what the agent can expect (listed/clean, severity, removal metadata, unavailable/disabled evidence) and clarifies operational constraints (60 providers, auth/destructive notes). Enough for correct invocation and interpretation.

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 already documents both parameters (100% coverage). The description adds meaning: domain resolves MX IPv4 addresses, IP is a direct check, and at least one is required. This enriches the schema's basic field 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 it's a read-only query against DNSBL/RBL providers, distinguishing it from sibling check tools (e.g., check_spf, check_dmarc). It specifies the resource and action precisely, even noting it is not a delisting service.

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 ('mail-server reputation triage') and when not ('not a delisting service'), plus input requirements (domain or IP, at least one required). It doesn't name alternative tools but provides sufficient context for differentiation.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds explicit details: 'Single GET, no auth, no side effects,' which are not in the annotations but enhance transparency regarding HTTP method, authentication, and side effects. 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 concise and well-structured: two sentences covering the action, returned data, and usage guidance. It includes a clear list of tags and warnings without unnecessary verbosity, making it easy to parse and understand.

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 sufficiently explains what the tool returns: parsed tag map, policy strength assessment, alignment mode, and warnings. It also notes the read-only nature and lack of auth, covering all key aspects of context. No gaps are apparent.

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 description for the 'domain' parameter is complete: 'Domain name only, e.g. example.com (no URL, path, or port).' Since schema coverage is 100%, the baseline is 3, and the tool description does not add any additional parameter semantics beyond what the schema already provides.

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: read-only fetch and parse of the _dmarc TXT record. It also distinguishes from sibling check_sender_requirements by specifying its purpose for DMARC policy review, making it specific and unique among the many check_* 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 explicitly provides usage context: 'Use for DMARC policy review' and an alternative: 'use check_sender_requirements for combined Google/Yahoo SPF+DKIM+DMARC pass/fail verdict.' This gives clear guidance on when to use this tool versus a related one.

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 rich behavioral context beyond annotations: mentions the nine resolvers, defaults, return payload (percentage, inconsistency list), and explicitly states read-only, no auth, no destructive actions. It aligns with annotations and provides extra detail.

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 concise sentences, front-loaded with purpose, then usage, then safety. Every sentence adds value and there is 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?

The tool is well described: inputs (defaults), behavior (multi-resolver comparison), output (resolver responses, percentage, inconsistency list), and usage context. With full schema coverage and no output schema requirement, this is complete and actionable.

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 description only needs to add value. It does so by noting defaults ('record type A and region all') and giving context on domain (e.g., no URL/path/port), which complements the schema without redundancy.

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 compares DNS responses across multiple resolvers to detect propagation lag, missing answers, or inconsistent data. It uses a specific verb ('Compare') and resource ('DNS responses'), and distinguishes itself from the sibling lookup_dns tool by focusing on multi-resolver checks.

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 this tool ('records were just changed and you suspect staleness') and names the alternative for single lookups ('use lookup_dns instead'). This is exemplary usage guidance.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds 'no auth' and a latency estimate of ~3-8s, providing extra context beyond annotations without contradiction.

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 concise and well-structured in two sentences, covering scope, output, and alternatives without redundancy or unnecessary detail.

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's combined nature is well explained (what it checks, what it returns, when to use it). While the return format is not detailed, no output schema is provided, so it is sufficient 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?

The only parameter 'domain' is fully described in the schema (including format constraints). The description does not add further parameter details, so it earns the baseline score for complete schema 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 a combined email-security check covering SPF, DKIM, DMARC, blacklist status, and an aggregated score with prioritized issues. It distinguishes itself from siblings by noting it replaces multiple individual check_* calls.

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 provides when to use this tool vs alternatives: 'Use for one-shot email security overview; use check_sender_requirements specifically for Google/Yahoo bulk-sender compliance, or the individual check_* tools when you need only one signal.' This is clear guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false Kubernete. The description reinforces these with 'Read-only' and 'No auth.' It adds detail on the exact steps performed (PTR lookup, forward resolution) and output contents (PTR value, forward result, match verdict, warnings), which is valuable behavioral context beyond annotations. However, it doesn't mention any rate limits or error handling, but given the read-only nature, this is acceptable.

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 concise and front-loaded. It states the purpose, method, outputs, and use cases in three sentences without fluff. 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's simplicity (1 param, no output schema, but description details return values) and the presence of robust annotations, the description is fully adequate. Even though there's no output schema, the description lists the return components, which is sufficient.

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

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

The description doesn't add significant parameter semantics because the schema already fully describes the single 'domain' parameter (100% coverage). The description implies it's a domain name but the schema already says 'Domain name only, e.g. example.com'. So baseline 3 is appropriate.

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

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

The description uses a specific verb ('audit') and clearly identifies the resource (every IP backing the domain's MX records) while explaining the FCrDNS verification process. It distinguishes itself from sibling tools like check_blacklist by specifying its unique focus on reverse DNS 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?

Explicitly states usage scenarios: 'mail deliverability audits, SpamExperts-style cluster checks, and any why is our mail being rejected debugging' and recommends pairing with check_blacklist for reputation signals. This gives clear guidance on when to use and complements alternatives.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it performs a live UDP probe to port 443 and notes the expected timing (~2-5s due to UDP handshake timeout). It also implicitly states it is a network operation without stating side effects, which aligns with annotations. It doesn't contradict 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 concise, front-loaded with the tool's purpose, and every sentence adds value: it lists the three signals, explains the return values, gives use cases, notes exclusions, and mentions auth/timing. No wasted words.

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's moderate complexity (multiple signals, live probe, timing), the description is reasonably complete. It covers inputs (domain), process (signals), outputs (per-signal verdict plus aggregate boolean), and constraints (no auth, timing). Minor gaps: doesn't detail how failures are reported or whether partial results are returned, but given good annotations and schema, this is acceptable.

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 provides 100% coverage for the single 'domain' parameter, including an example and validation rules (no URL, path, or port). The description echoes the domain-only requirement implicitly by mentioning 'for a domain' but adds no additional semantics beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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 is a read-only HTTP/3 + QUIC support check for a domain, combining three specific signals (Alt-Svc header, HTTPS/SVCB DNS records, live QUIC probe). It distinguishes itself from sibling tools by explicitly naming its unique features and use cases, making it easy to select.

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 on when to use the tool: for validating CDN/Cloudflare HTTP/3 rollouts or auditing modern transport posture, and explicitly states it is not relevant for mail-only domains. However, it does not mention alternatives or when not to use it beyond mail-only domains, which would be stronger guidance.

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

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

Annotations already declare read-only/idempotent/non-destructive, but description adds operational details: DNS+HTTPS GETs, no auth, and exact return structure (mode, mx allowlist, max_age, warnings) that enhance transparency beyond the 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?

Two sentences deliver all essential information without redundancy. Front-loaded with the core function, followed by return details and usage guidance — no wasted words.

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, rich annotations, and no output schema, the description covers what it does, how to use it, what it returns, and its relationship to sibling tools. Nothing essential is missing.

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

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

Schema provides thorough description of the single 'domain' parameter (no URL/path/port, maxLength). Description reinforces its usage in DNS and HTTPS lookups but adds minimal new semantic value; schema already covers the key constraints, so a 3 is baseline, with slight bump for integration context.

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 identifies the resource (MTA-STS via TXT record and HTTPS policy file) and specific outputs (parsed policy, certificate validity, consistency warnings). Distinguishes from sibling check_smtp_tls by stating its unique focus.

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 (to verify enforced TLS for inbound mail) and directs to check_smtp_tls for live STARTTLS. Also notes 'No auth', clarifying prerequisites.

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

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

Adds behavioral details beyond annotations: single GET, no auth, returns informational follow-up items rather than false passes, and describes output structure (pass/fail/warning/info + readiness summary). No contradiction with readOnly/idempotent/destructive 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 slightly verbose but each sentence contributes meaning, is front-loaded with the core purpose, and flows logically. Could be tightened but remains effective.

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

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

With no output schema, the description adequately explains return format and scope. It covers limitations (messaging-level checks) and provides a complete picture for a simple domain-only preflight tool, considering the rich annotations and straightforward parameter.

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

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

Schema coverage is 100% for the single domain parameter, and the description adds no extra parameter semantics beyond what's in the schema. Baseline 3 is appropriate since the schema fully documents the 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?

The description clearly states it's a read-only domain-side preflight against Google/Yahoo bulk-sender requirements, enumerating checks (SPF, DKIM, DMARC, MX, PTR/FCrDNS) and explicitly distinguishing from message-level tools like analyze_raw_email and create_email_test.

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 says 'Use before a campaign' and notes which requirements are not covered (TLS, unsubscribe, etc.) plus directs to alternatives for message-level verification, providing clear when/when-not guidance.

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

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

Annotations already mark the tool as read-only, non-destructive, idempotent, and open-world, but the description adds valuable context: it connects and quits without sending mail, may take 10-30 seconds due to live handshakes, and requires no authentication. These behavioral details go beyond what annotations 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 tightly structured: it opens with the core action, lists the specific checks and return values, then gives usage guidance and caveats. Every sentence contributes meaningful information with no redundancy, achieving depth without 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?

With no output schema, the description explicitly enumerates the returned data (per-MX cipher/version, cert SANs, expiry days, FCrDNS verdict, STARTTLS-required flag), covering the return contract. It also mentions latency, authentication, and the scope (every MX host), leaving little ambiguity for 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?

The input schema fully documents the single 'domain' parameter with an example and constraints. The description does not add any parameter-specific semantics beyond what the schema already states (domain name only, no URL/path/port), so the baseline score 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 performs a live SMTP TLS check on every MX host, enumerating the exact protocol steps (TCP 25, EHLO, STARTTLS) and validation checks. It also distinguishes itself from siblings by naming check_mta_sts as the policy-layer counterpart, making the tool's scope unmistakable.

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

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

The description explicitly says 'Use to verify inbound mail TLS posture' and recommends pairing with check_mta_sts for the policy layer, providing clear when-to-use and an alternative tool. It also warns about potential slowness (10-30s) due to live SMTP handshakes, which helps the agent decide when to invoke 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?

While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context beyond that: it recursively traces the entire SPF lookup graph, counts DNS lookups against the RFC-7208 limit, and presents flattening guidance when over the limit. This enriches the agent's understanding of the tool's computational behavior and outputs, though it stops short of detailing exact return structure or pagination. Since annotations already cover safety, a high score is justified.

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 a single, dense paragraph that front-loads the core purpose ('Read-only SPF parse and validation'), then packs behavioral details (recursive walking, DNS count, RFC limit) and usage guidance in an efficient manner. Every sentence adds value, with no fluff or redundancy. It is appropriately sized for the tool's complexity.

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 only one parameter, a clear schema, and safety annotations, the description covers the essential behavioral aspects: what it does (parsing/validation), what it returns (mechanisms, graph, count, qualifier, warnings), and edge-case behavior (close to/over limit). It does not explicitly mention error cases (e.g., invalid domain syntax), but given the tool's read-only nature and the presence of an output schema-less environment, this is a minor gap. The description is sufficiently complete for an agent to make a confident selection.

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 a full description of the single 'domain' parameter, including format constraints (no URL/path/port) and a maximum length. The description adds no new parameter-level information beyond what the schema already captures, but it does contextually imply the parameter is a domain needed for SPF lookup. With 100% schema coverage, the baseline is 3, and the description does not detract from it.

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

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

The description clearly identifies the tool as a read-only SPF parser and validator for a domain, with a specific verb ('parse and validate') and resource ('SPF records of a domain'). It distinguishes itself from sibling tools like check_email_security and flatten_spf by detailing its unique recursive include/redirect walk and DNS lookup counting, making its purpose unambiguous.

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

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

The description explicitly states when to use this tool ('for SPF auditing or before adding new include: senders') and provides a clear alternative ('use check_email_security for the broader SPF+DKIM+DMARC overview'). This gives the agent concrete decision-making guidance, distinguishing it from a generic 'use for SPF' statement.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable context beyond that: it never fetches or cryptographically matches the live certificate, it resolves MX hosts when no port is given, and 'No auth or destructive actions' reinforces the safety profile.

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

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

The description is compact but information-dense, starting with the core purpose and then layering behavior, limitations, alternatives, and use cases. Every sentence contributes either to selection, invocation, or expectation-setting; there is no filler or repetition of schema data.

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

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

With no output schema present, the description compensates by listing returned data categories: parsed usage, selector, matching type, certificate data, syntax errors, and advisories. It also covers behavioral nuance, limitations, related tools, and intended workflow context, making it complete for an agent to select and invoke correctly among many DNS/email siblings.

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

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

Schema descriptions already cover 100% of the parameters, including domain format, port defaults, and protocol enum. The description adds semantic value by explaining how port and protocol combine into the constructed TLSA query (`_<port>._<protocol>.<domain>`) and how absence of port changes resolution behavior from explicit query to MX host discovery.

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-only TLSA/DANE DNS record check.' It clearly explains two operational modes (no port -> MX-host TLSA records; explicit port -> `_<port>._<protocol>.<domain>`) and explicitly differentiates itself from sibling check_smtp_tls by noting it does not fetch the live certificate.

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 explicit guidance: 'Use before publishing DANE records or troubleshooting DANE handover,' and says to pair it with check_smtp_tls when SMTP certificate evidence is needed. It also states what the tool does NOT do, which clarifies when not to rely on 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?

The description discloses behavioral traits beyond annotations: it specifies the tool is a non-idempotent POST, creates a fresh session each time without modifying prior sessions, returns a single-use email valid for 60 minutes, and requires no auth. This adds valuable context that annotations only hint at.

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 concise and well-structured, covering purpose, return value, behavior, parameter, usage scenario, and auth requirement in four sentences. Every sentence contributes essential information with no fluff or repetition.

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

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

Given the tool's role as a creation step in a workflow, the description is complete: it explains what it returns (test email and testId), the expiry, the language option, and exactly how to follow up (poll_email_test). With no output schema, the description fulfills the need to describe the return value 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 description coverage is 100% (the only param 'language' is described as 'Result language' with an enum and default). The description adds 'language controls result text (en/nl/de/fr, default en)', which is essentially a restatement of the schema info. It doesn't provide significant new meaning beyond what the schema already offers, 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 what the tool does: it creates a new inbound email-test session. It specifies the verb 'create' and the resource 'inbound email-test session', and distinguishes itself from siblings by explaining the returned testId is used by get_email_test or poll_email_test. This makes it 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 gives explicit guidance on when to use the tool: 'Use to debug an outbound message's SPF/DKIM/DMARC, headers, and spam triggers; after sending, call poll_email_test.' It also indicates the workflow and implicitly suggests not to use it for other tasks, providing clear context and next steps.

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?

Description discloses write-once nature, additivity, non-idempotency, and that a canonical POST creates one snapshot per call. It complements annotations (idempotentHint=false, destructiveHint=false) with concrete behavioral details like immutable and stable over time. 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?

Two densely informative sentences. Front-loads core action, then packs use cases, return values, and usage guidance without fluff. Every phrase adds value; 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 tool has no output schema, but the description explicitly lists all return artifacts (snapshot ID, ISO timestamp, SHA-256 hash, bookmarkable URLs for both formats). It also covers stability, compliance use cases, and alternative tools. Sufficient for an agent to understand behavior and expectations fully.

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 both parameters are already well-documented in the input schema. The description mentions 'domain' only implicitly and doesn't add parameter-specific guidance beyond schema. Meets baseline for full coverage but doesn't enrich parameter 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?

Clearly states the action (create an immutable evidence snapshot) and resource (current Everything Report for a domain). Differentiates from sibling get_everything_report by emphasizing stability and immutability, explicitly telling when to use this instead.

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 specifies when to use this tool (for ticketing, audits, compliance, LLM citations) and directs to get_report_snapshot for reading back. Also contrasts with get_everything_report for stable results. Provides clear alternatives and 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?

Goes well beyond the annotations by explaining the 50-selector heuristic behavior, the inconclusive-miss caveat due to no DKIM enumeration protocol, the exact lookup behavior, and the return contents. Also explicitly states 'No auth or destructive actions,' which extends the annotation 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?

Every sentence earns its place. The description is compact, front-loaded, and covers purpose, modes, outputs, alternatives, and safety 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 having no output schema, the description lists expected return values (discovery method, coverage note, key tags, strength, warnings). It also clarifies limitations and relationship to siblings, making the tool self-contained for agent 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?

The input schema fully documents both parameters with examples. The description adds crucial semantics by explaining how presence/absence of 'selector' changes the tool's behavior and provides source guidance for obtaining an exact selector (DKIM-Signature header or provider).

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?

Opens with 'Read-only DKIM check for a domain' – a specific verb+resource statement. It clearly distinguishes two modes (heuristic multi-selector vs exact single-selector) and differentiates from sibling check_email_security.

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 tells when to use exact mode ('whenever the selector is known') and directs users to check_email_security for a broader overview. It also warns that heuristic-mode misses are inconclusive, guiding 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description reinforces this with an explicit statement that the tool is read-only and 'never mutates DNS or domain state,' and adds details about the structured return content. It does not contradict annotations, and adds extra context about what the tool returns.

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 packed sentences, front-loaded with the main purpose and output. Each sentence adds distinct value: what the tool does, side-effect safety, and exactly when to use it. No wasted words.

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 3 parameters (2 required) and no output schema, the description is complete: it states the core function, the structured output fields, side-effect guarantees, required and optional parameters, and use cases relative to siblings. An AI agent has enough grounds to select and 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 coverage is 67% (domain and context have descriptions, issue only has an enum). The description compensates by giving concrete example enum values (spf_missing, no_dnssec) and explaining that the context object comes from prior scan output, which adds 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 the tool's function: asking the AI service for a plain-language explanation of a specific issue, and enumerates the output contents (severity, business impact, root cause, fix steps). It distinguishes itself from generate_dns_fix by noting it explains 'why' rather than providing the actual fix snippet.

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?

Explicit usage guidance is given: 'Use after scan_domain when an agent needs to walk a user through *why* a finding matters; use generate_dns_fix for the actual DNS record snippet that resolves it.' Also recommends passing context from scan output for better answers, which gives clear when-to-use and when-not-to-use direction.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds 'No auth, no side effects' and cautions about high maintenance and provider IP rotation. These traits are not in the annotations and add valuable 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 somewhat lengthy but packs essential details: purpose, usage, return content, and caveats. It is well-structured with a logical flow, though it could be slightly more concise without losing nuance.

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 the operation's purpose, output details (lookup counts, IP count, record length, split flag, maintenance warning), and practical advice. It is complete given the lack of an output schema.

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

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

The schema already fully describes the sole parameter 'domain' with a clear description. The tool description adds no additional meaning about the parameter, so it stays at the baseline for full schema 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 the tool's function: it flattens SPF records by resolving the full include/a/mx/redirect graph to literal IP addresses, returning a single SPF record within limits. This distinguishes it from sibling tools like check_spf or generate_spf.

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?

Explicit usage guidance is provided: 'Use when a domain hits too many DNS lookups (PermError) and removing unused includes is not enough' and references running check_spf first. This clarifies when to choose this tool over 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?

Beyond the annotations (readOnlyHint, openWorldHint, etc.), the description reveals additional behaviors: it returns the record, host, and warnings about common mistakes, and explicitly states 'Nothing is looked up or stored'. This adds meaningful context not captured by annotations and aligns with them.

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

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

The description is concise yet information-dense, with each sentence serving a purpose: it defines the tool, explains risks, provides best practices, and describes outputs. It is well-structured, front-loaded with the core purpose, and avoids 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 tool with 9 parameters and no output schema, the description covers critical context: policy trade-offs, reporting requirements, and common pitfalls, while also describing return values. It is sufficiently complete for an agent to use the tool correctly and safely.

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 100% schema coverage, the description adds substantial semantic value by explaining the real-world implications of parameters like policy, percentage, and rua, which are not fully captured in the schema descriptions. It clarifies how to use these parameters to avoid breaking mail delivery.

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 verb ('Build') and resource ('DMARC record'), clearly stating what the tool does. It distinguishes itself from siblings like generate_spf and check_dmarc by focusing on DMARC record generation and policy guidance, making its purpose unambiguous.

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

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

The description provides explicit guidance on when to use each policy (p=none, p=quarantine, p=reject) and explains the consequences, such as 'reject silently destroys legitimate mail'. It also advises always publishing rua and using percentage for gradual rollout, giving clear context for safe 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?

The description explicitly states it is a 'read-only POST' that 'never modifies the user's zone,' aligning with the readOnlyHint annotation. It adds detail about return content (proposed records, TTL, provider-specific notes) and side-effect-free behavior, going beyond the annotation without contradiction.

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 somewhat lengthy but each sentence adds value (purpose, return details, when to use). It is well-structured without redundancy, so it remains efficient despite covering multiple aspects.

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 is provided, but the description explains what the tool returns (proposed records, TTL recommendations, provider-specific notes). It also covers the workflow context (after identify problem, before verify). This makes it complete for an agent to use 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 description mentions all three parameters (domain, issue, context) and clarifies that context is 'from prior scan output.' While the schema already describes domain and context, the description adds the interrelationship (context for tailored output) and that issue is an enum; it does not enumerate the enum values but gives an example, which is adequate.

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: to generate copy-pasteable DNS record snippets that fix a specific issue, with an example (spf_missing → suggested SPF record). It distinguishes this from sibling tools like generate_spf or generate_dmarc by focusing on issue-based fixes.

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 usage guidance: 'Use after explain_issue or scan_domain identifies a problem; use lookup_dns afterwards to verify.' This clearly tells the agent when to invoke this tool and what to do before and after, satisfying the 'when vs alternatives' criterion.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description details that no scan is performed and nothing is read from the live site. It also discloses the output format (name/value pairs, server-specific configs, warnings) and the default behavior of choosing 'recommended' when no preset or config is provided.

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 appropriately sized for a tool with this complexity. It is front-loaded with the primary action, then clearly enumerates presets, config, return values, and usage context. Every sentence contributes useful information with no redundancy or 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?

Despite no output schema, the description fully explains what is returned (name/value pairs, per-server configurations, raw headers, warnings) and how to invoke the tool in different scenarios. It covers the nested config object and default behavior, making the tool complete and self-contained for an agent.

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%, but the description adds significant value by explaining the meaning of each preset ('recommended' safe baseline, 'strict' hardened nonce-based CSP, 'report-only' safe rollout) and the config object as an advanced override. It also clarifies the default behavior, which is not fully apparent from the schema alone.

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 a complete, best-practice set of HTTP security headers, using a specific verb and resource. It distinguishes itself from the sibling analyze_security_headers by explicitly noting it requires no scan and reads nothing about the live site.

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 when-to-use guidance: 'Use this to set up headers on a new or unscanned site; use analyze_security_headers first when you want to see what an existing site is already missing.' Also explains the choice of presets and the config option, covering alternative scenarios.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this by stating 'Nothing is looked up or stored — this is computation only.' It adds valuable context beyond the annotations, such as the warning that 'pass' policy 'should never be published' and the detail that it returns warnings and the DNS entry. While it doesn't delve into every error condition, the transparency is strong and aligned with annotations (no contradiction).

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 longer than typical, but every sentence earns its place—it packs essential domain knowledge, parameter guidance, and sibling differentiation into a compact narrative. It is front-loaded with the purpose and ends with usage caveats. While it could potentially be split into paragraphs, the density is appropriate for a tool of this complexity, so it's not verbose or redundant.

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

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

The description fully compensates for the lack of an output schema by explicitly listing exactly what the tool returns: 'the record, the lookup count, whether either the lookup or 255-character limit is exceeded, warnings in plain language, and the DNS entry to publish.' It also covers the critical SPF lookup limit, policy semantics, and mechanism examples, making the tool fully self-contained for an agent to use 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?

Although the schema has 100% description coverage, the tool description goes much further: it explains the meaning of each mechanism type with concrete examples (Google Workspace `_spf.google.com`, Microsoft 365 `spf.protection.outlook.com`), clarifies lookup costs (include/a/mx/exists/redirect cost one lookup; ip4/ip6 are free), and describes policy implications in depth ('fail' for production, 'softfail' for testing, 'pass' should never be published). This adds substantial semantic value beyond the schema's terse parameter 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 clear, specific verb-resource pairing: 'Build an SPF (Sender Policy Framework) record', then defines its purpose (DNS TXT record listing authorized mail senders). It explicitly differentiates itself from sibling tools (check_spf for reading/validating, flatten_spf for reducing existing records), leaving no ambiguity about what this tool uniquely does.

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 'when to use' guidance: it explains the reason to call this instead of writing the string manually (the 10-lookup limit and PermError risk), and directly names alternatives: 'Use check_spf instead to read and validate... and flatten_spf when an existing record is over the lookup limit'. It also clarifies that this is for building a new record from scratch, not modifying existing ones.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds critical behavior beyond that: private keys are refused, the hash is computed locally because a language model cannot hash, and it explains the consequences of DNSSEC absence and fail-closed semantics. No contradiction with annotations; these additions materially improve safety and outcome understanding.

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 a single well-structured paragraph that front-loads purpose, then skillfully explains security, parameters, and edge cases. Every sentence delivers value—no filler or redundancy. It is detailed yet scannable, with a logical flow from 'what' to 'how to use' to 'caveats'.

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 complex DANE generation tool with no output schema, the description fully covers inputs, expected return (record, hash, meanings, DNS entry), and critical operational pitfalls (DNSSEC, fail-closed, renewal). It also justifies the recommended settings, making it complete for an agent to invoke correctly and interpret results appropriately.

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%, but the description adds rich meaning: for pem it specifies accepted block types and explicitly forbids private keys; for host it clarifies MX-derived hostname; for usage/selector/matching it recommends and explains the semantic impact of each numeric value (3 1 1 profile, renewal survival). This far exceeds the schema's basic 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+resource: 'Build a DANE TLSA record from a certificate or public key', and clearly explains the purpose (pins which certificate a mail server may present). It differentiates from siblings like check_tlsa_dane (verification vs. generation) and generate_dns_fix (generic DNS fix), making its unique role explicit.

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 usage context: paste the PEM, recommended 3 1 1 profile for SMTP, host must be from MX record, and warns about DNSSEC and fail-closed behavior. It does not explicitly name alternative tools for verification (e.g., check_tlsa_dane), but the context is sufficient for an agent to know when to use this tool. No explicit when-not-to-use statement, but the guidance is strong.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description goes beyond by stating 'no scan triggered, no network call from this tool, no auth'—adding operational details about side effects and network behavior. It also specifies the output is a JSON with badgeUrl, which is useful behavioral information 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 concise, front-loads the core purpose, and each sentence adds value: it states the action, notes side effects, lists styles, and mentions an alternative. No fluff or redundancy. Structure is logical: purpose, safety, output, style options, usage guidance.

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

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

For a simple 2-param tool with no output schema, the description covers everything: purpose, behavior (no network call), output format, style enum meaning, use case, and alternative tool. It fully compensates for the lack of an output schema and leaves no ambiguity for the agent.

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

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

Schema coverage is 50%: domain has a description, style has enum/default. The description adds the style options ('flat, flat-square, plastic, large') and clarifies domain input ('Domain name only, e.g. example.com (no URL, path, or port)') which reinforces the schema description. It also implies the purpose of the style parameter by mentioning it's for badges. However, it doesn't explain how the badge URL is constructed (e.g., what the URL looks like), but the schema handles most semantics. Since coverage is 50%, the description partially compensates, but it could add a bit more detail on the style parameter's effect.

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 exactly what the tool does: 'Build the direct SVG badge URL for a domain's security score.' It specifies the verb (build), the resource (direct SVG badge URL), and clarifies it's pure URL construction with no side effects. It also distinguishes itself from the sibling tool get_pdf_report_link by naming the alternative.

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 tells when to use: 'Use for embeddable status badges' and explicitly contrasts with get_pdf_report_link for a downloadable full report. The description also clarifies that it's for README, GitHub, status pages, or wikis, giving clear context. No other alternatives are needed since the sibling list is extensive but only that one is relevant.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds that it is 'Pure data, no I/O, no auth,' which further clarifies that it is a safe, non-mutating operation. It also explains that it returns a canonical host, a do-not-use list, and preferred citation URLs, which gives insight into the output structure beyond what annotations provide. 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 a single, information-dense paragraph that front-loads the core purpose ('Return canonical IntoDNS.ai citation guidance') and immediately follows with the key distinction and usage guidance. It includes all essential details without fluff, making it easy to scan. 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 is a simple read-only lookup with one enum parameter and no output schema, the description sufficiently covers what the agent needs: what the tool returns, when to use it, and how it differs from a sibling. It clearly lists all valid topics, so the agent can correctly invoke it. Without an output schema, the description proactively outlines the return content (canonical host, do-not-use list, preferred citation URLs), which enhances completeness.

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 only one parameter (topic) with an enum and a default of 'scan_results', and the description explains the purpose of the parameter by listing the possible topics and stating it returns per-topic guidance. Since the schema covers the parameter's allowed values and default, the description doesn't need to do much heavy lifting, but it enriches the parameter's meaning by indicating the response is topic-specific. Baseline for high coverage would be 3, but the description goes a bit further by explicitly mapping topics to citations.

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: returning canonical citation guidance for IntoDNS.ai, with a specific verb ('Return') and resource ('canonical IntoDNS.ai citation guidance'). It explicitly differentiates from the sibling tool read_llm_discovery by noting the distinction between canonical citation guidance and raw machine-readable discovery files. Also, it lists exact topic values, so there's no ambiguity about what it returns.

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?

Proactive guidance is provided: 'Use whenever generating an answer that references DNS or email scanning evidence; use read_llm_discovery for raw machine-readable discovery files.' This explicitly states when to use and when not to use (and names the alternative tool). It also lists the topics for which it is applicable, which helps agents decide when to invoke this tool over siblings.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds context on side effects ('No auth, no side effects') and the nature of polling, but these are minor additions beyond the annotation set, justifying a slightly above baseline score.

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

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

Two sentences with clear structure: purpose, return values, usage requirement, and alternatives. No redundant wording or filler; 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?

The description covers return values (progress, scores, results, failures), usage context (after start_deep_scan, polling frequency), and alternative options. It is complete for the tool's purpose, even without an output schema.

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

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

The single parameter scanId is fully described in the schema ('Deep scan ID returned by start_deep_scan'). The description repeats that information without adding new meaning. With 100% schema coverage, 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 is a read-only status poll for a deep scan, returning progress and results. It distinguishes from sibling tools like scan_domain (fast single-vantage) and start_deep_scan (initiation), making its purpose specific and 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?

Explicitly instructs to use after start_deep_scan and advises preferring scan_domain for fast single-vantage scans. Also provides polling interval guidance (10-30s until status='finished'), giving clear when-to-use and alternative contexts.

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

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

Annotations already cover read-only and idempotence, but the description adds valuable behavioral context: 'pending' until delivery, then full SPF/DKIM/DMARC/headers/spam-score results, and no-auth access. This goes beyond the structured metadata without contradicting it.

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

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

Four sentences, each earning its place: purpose, behavior, dependency, usage timing, alternative, and idempotence/auth status. Front-loaded with the core action 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?

Despite having no output schema, the description sufficiently explains both possible return states ('pending' and full results) and the required input origin. Given the tool's simple read-only nature, this is complete and actionable.

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

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

Schema coverage is 100% and the single parameter `testId` is already well-documented in the schema. The description reinforces its origin from create_email_test but adds no significant new syntax or formatting detail.

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

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

The description uses a specific verb ('status read') and names the exact resource ('email-test session'). It clearly distinguishes itself from sibling tools by contrasting with poll_email_test and referencing create_email_test.

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 explicitly states when to use the tool: after sending a test message to the unique address. It also provides a direct alternative ('use poll_email_test instead') and identifies the required prerequisite (`testId` from create_email_test).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds 'No auth, no side effects' and explains latency variation (~5-15s depending on backend cache state), which goes beyond the annotations and clarifies expected execution behavior without contradiction.

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 a single well-structured paragraph that front-loads the main purpose and then provides context on latency, use cases, and nuances. Every sentence adds value, and 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?

Despite lacking an output schema, the description enumerates the major report components (DNS, email authentication, web/HTTPS, blacklist, sender requirements) and mentions the JSON vs Markdown output. It covers latency, side effects, and alternatives. It could benefit from explaining whether the report includes raw data vs summaries, but overall it's sufficiently 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?

Both parameters (domain and format) are fully covered by the input schema with descriptions that include examples and constraints. The description repeats the domain requirement ('no URL, path, or port') and mentions output formats, but doesn't add significant extra meaning beyond the schema. Given 100% coverage, baseline 3 is appropriate.

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

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

Description explicitly states the tool generates a complete live IntoDNS.ai report covering DNS, email authentication, web/HTTPS, blacklist reputation, sender requirements, and citation URLs. It distinguishes from siblings by naming scan_domain and create_report_snapshot as alternatives, making the purpose unmistakable.

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

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

Provides explicit when-to-use guidance ('when the user asks for everything, the full picture, or a deep current-state summary') and contrasts with scan_domain for faster scans and create_report_snapshot for immutable audit use. Also notes read-only, latency, and auth absence.

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

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

Annotations already declare readOnlyHint and destructiveHint, and the description adds value by noting the endpoint does not calculate rank, data may be stale, and no auth is required. These go beyond structured annotations to disclose useful limitations.

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, information-dense sentences with no redundancy. It front-loads the core purpose, then details modes and usage guidance, earning every word.

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 the two possible outcomes (list with score/timestamp or boolean membership) and notes the rank limitation. It covers all relevant aspects for a simple read-only tool with two optional 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?

Schema covers both parameters, but the description adds meaning beyond schema by explaining conditional behavior (if domain omitted vs. provided), including the return type change and default/max limits, which is not fully expressed in the schema alone.

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 fetches the IntoDNS.ai Hall of Fame, with specific verbs and resources. It distinguishes between two modes (list vs. membership check) and explicitly contrasts with scan_domain, making sibling differentiation 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?

Provides explicit when-to-use guidance and names an alternative tool (scan_domain) for current evidence, noting that Hall of Fame data may be older. This gives clear context on 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?

Annotations already cover readOnly, openWorld, idempotent, and destructive hints. The description adds extra context: 'internal Redis, AI-provider, and process details are intentionally redacted' and 'Single unauthenticated GET with no destructive actions', enriching behavioral understanding beyond the annotations.

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

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

The description is concise despite its length: every sentence adds value (purpose, redaction, usage, alternative, auth). It is front-loaded with the primary purpose and avoids 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?

For a simple health probe with no parameters and no output schema, the description covers return contents, redaction, usage context, and alternative tooling. It is fully complete for the tool's scope.

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

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

With zero parameters, the description has no need to explain parameters, and the baseline of 4 applies. The description doesn't mention parameters but doesn't need to; it clearly focuses on the tool's purpose and usage.

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 is a read-only health probe for the backend itself, not a target domain, and returns service status and timestamp. It distinguishes from siblings like get_stats and other domain-focused tools, fulfilling the specific verb+resource criterion.

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: 'pre-flight check before batch jobs' and 'to distinguish a service incident from a real DNS finding', and provides an alternative: 'use get_stats for public usage counters instead'. This is clear guidance with exclusions and 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses key behavioral traits: 'no scan triggered, no network call from this tool,' the return shape (`pdfUrl`), and the fetched URL's content type (`application/pdf`). It also clarifies auth requirements ('No auth'), adding meaningful 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 three sentences, front-loaded with the core action, and every sentence adds distinct value: what it does, what it returns, and when to use it versus alternatives. No wasted words.

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

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

For a simple one-parameter, read-only URL construction tool with no output schema, the description fully covers behavior, return format, auth, side effects, and alternatives. It is complete and self-sufficient.

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

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

Schema description coverage is 100% for the single `domain` parameter, including format constraints ('no URL, path, or port'). The description only refers to 'domain' generically and does not add new parameter-level details, 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 uses a specific verb ('Build') and clearly identifies the resource ('direct PDF report endpoint URL for a domain'), immediately distinguishing this from sibling tools. It also explicitly contrasts with get_badge_link and create_report_snapshot, making the tool's unique purpose unmistakable.

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

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

The description provides explicit usage guidance: 'Use for downloadable shareable reports' and names alternatives ('use get_badge_link for an embeddable SVG status badge instead, or create_report_snapshot for an immutable hashed evidence URL'). It also states 'No auth,' covering prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond these by disclosing the immutable JSON nature, SHA-256 content hash, timestamp inclusion, and the fact that no auth is required — a meaningful behavioral guarantee for audit scenarios. Credit is given for adding context that the annotations themselves don't capture, though the safety profile was already covered by the structured data.

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 sentences, front-loaded with the core purpose, using an em-dash and semicolon for efficient packing of information. Every clause contributes: what it does, what it returns, its key properties (read-only, hash, timestamp), and when to use an alternative. Zero 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?

For a simple 2-parameter tool with 1 required param and no output schema (JSON return must be self-contained), the description covers all critical aspects: purpose, return behavior, authentication state, immutability, and relationship to the sibling tool. No important context is missing given the tool's 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 coverage is 100%, so baseline 3 applies. The description adds provenance for snapshotId ('Requires snapshotId from create_report_snapshot') but doesn't add syntax, format, or semantic details beyond what the schema's property descriptions already provide. This is adequate but not exemplary.

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+resource combination ('Read a previously created IntoDNS.ai Everything Report evidence snapshot by snapshot ID'), names the exact partner tool (create_report_snapshot), and explicitly distinguishes itself from get_everything_report. It leaves no ambiguity about what this tool does.

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 an explicit when-to-use scenario ('Use to verify or re-read an audit-trail evidence record without re-running a live scan') and an explicit alternative with a clear exclusion ('use get_everything_report for current live data instead'). It names the sibling tool directly, making the choice unambiguous.

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?

While annotations already declare readOnly/openWorld/idempotent/non-destructive, the description adds meaningful behavioral context: the specific endpoint (/api/stats), what data is included and excluded (no personal data, no per-domain breakdown, no Hall of Fame count, no series), and the cache timestamp. This goes well beyond the annotations.

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

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

The description is compact (three sentences) and front-loaded with the main action, followed by exclusions, use case, and alternative. Every sentence adds information, with no repetition of schema or annotation fields.

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

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

For a zero-parameter, no-output-schema public stats tool, the description fully covers what the agent needs: endpoint, data returned, data not returned, use case, alternative tool, and safety/auth profile. No critical 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?

The tool has zero parameters, and schema coverage is effectively 100%. With no params, the baseline is 4. The description confirms the tool is a simple single-GET operation with no inputs, adding no unnecessary param detail.

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

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

The description opens with a specific verb+resource combination ('Read-only fetch of the public IntoDNS.ai aggregate counters') and explicitly lists the scope (domains scanned, security checks, cache timestamp). It also distinguishes itself from get_hall_of_fame, making the purpose unmistakable.

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

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

Provides explicit usage context: 'Use for a lightweight public usage snapshot or status display; use get_hall_of_fame for top-scoring public domains.' This clearly states when to use this tool vs an alternative, along with the unauthenticated GET detail.

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

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

The description adds behavioral context beyond annotations: it explains default behavior when both type and types are omitted (returns A records), what the response includes (TTL, raw rdata, DNSSEC AD bit), and constraints (no auth, rate limits only from upstream resolver). This complements the readOnly, idempotent hints without contradicting them.

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

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

The description is compact and front-loaded: the first clause states the core purpose, followed by parameter behavior, return type, usage guidance, and constraints. 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 DNS lookup tool with no output schema, the description covers purpose, parameters, return format, and operational constraints. It also places the tool within the sibling context, making it self-sufficient for an agent to select and 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?

Schema coverage is 100%, but the description adds important parameter semantics: it distinguishes between `type` (single) and `types` (array) and clarifies the default A record behavior. This goes beyond the schema descriptions, which only list the parameters without explaining the relationship or default.

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 does a 'Read-only DNS record lookup via DNS-over-HTTPS,' specifying the verb (lookup), resource (DNS records), and method (DoH). It also distinguishes from siblings by naming validate_dnssec and check_dns_propagation as alternatives for different use cases.

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?

Explicit when-to-use guidance is provided: 'Use for arbitrary record queries; use validate_dnssec for full DNSSEC chain validation, or check_dns_propagation for multi-resolver consensus.' This clearly states both the intended use and when to choose alternatives, plus notes about auth and rate limits.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds meaningful context about the scope (DNS/email only) and that it maps 'IntoDNS quickscan' to NIS2 measures, which clarifies what the tool actually does beyond the annotations. It does not repeat annotations and does not contradict them. A slight deduction for not explicitly stating it makes network calls, but the readOnly hint implies that.

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

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

The description is front-loaded with the core purpose, then lists outputs, scope limitation, and usage triggers. Every sentence adds value and there is no filler. It is structured logically and efficiently for its complexity.

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, so the description must explain return values, and it does (0-100 score, per-measure status, evidence rows, gaps, fixes). It also provides crucial scope context (DNS/email only) and usage guidance. Annotations cover safety. For a composite analysis tool, this is complete and sufficient.

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

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

Schema description coverage is 100%: both parameters (domain and lang) are fully described in the schema. The description does not add significant parameter information beyond the schema. It mentions the score is for a domain, but the schema already specifies 'Domain name only'. Since the schema handles the burden, baseline 3 is appropriate.

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

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

The description clearly states the tool computes a NIS2 Article 21.2 readiness score for a domain, using a specific verb ('Compute') and resource ('domain'). It lists the outputs (0-100 score, per-measure status, evidence, gaps, fixes) and distinguishes itself from sibling tools by focusing on NIS2 compliance. This is a specific, non-vague 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?

Explicitly provides when to use: 'Use when the user asks about NIS2 compliance...' and also notes the limitation that it only covers DNS/email layer, implying it should not be used for full NIS2 compliance assessments. This gives clear context and an exclusion criterion, which exceeds the baseline.

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

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

Annotations already cover readOnly, idempotent, and non-destructive hints. The description adds valuable behavioral context beyond that: 'parsed in-memory and not stored' and 'No auth, no side effects', which fully disclose the tool's side-effect-free and stateless nature. This exceeds annotation coverage.

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

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

Four sentences deliver purpose, input, output, and behavior with zero fluff. It is front-loaded with the key 'Read-only parser' phrase and each sentence adds information, creating a tight, well-structured description.

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

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

No output schema exists, so the description carries the full burden of explaining what the tool returns. It does so in detail: report metadata (org, report id, date range), published policy (p/sp/adkim/aspf/pct), per-source rows with IP, count, disposition, SPF/DKIM results, and pass/fail totals. It also covers input formats and side effects, making it 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?

The schema already has 100% coverage for both parameters (xml max 5 MB, gzipBase64 as base64 gzip). The description adds the relationship that only one is needed and identifies the XML as a DMARC report, but mostly restates schema details. With full schema coverage, 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?

Clearly states it is a 'Read-only parser for a DMARC aggregate (RUA) XML report' (RFC 7489), naming the specific verb and resource. It enumerates the exact JSON output structure including metadata, policy fields, and per-source rows, and is readily distinguishable from sibling tools like check_dmarc or generate_dmarc.

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

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

Gives explicit context: 'Use to programmatically read DMARC reports an agent fetched from the rua@ mailbox'. This makes the intended scenario clear. However, it does not explicitly name alternative tools or state when not to use it, so it misses the top score.

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?

Even though idempotentHint and destructiveHint annotations exist, the description adds valuable behavioral detail: it is an idempotent POST, returns 'pending' if no message, and parses only messages received since the last call. It also explicitly states no auth and no destructive side effects.

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

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

Three sentences, front-loaded with the core action, followed by behavior, prerequisites, usage guidance, and safety. Every sentence contributes meaning 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 single-parameter stateful tool with no output schema, the description sufficiently explains lifecycle behavior, return states, prerequisite ID source, and relationship to sibling tools. No significant informational gap remains.

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

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

Schema description coverage is 100% for the single testId parameter, so the schema already carries the semantic weight. The description only repeats that testId comes from create_email_test without adding new parameter detail, meeting the baseline.

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

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

Description clearly states it processes the latest received message in an email-test session, distinguishing it from sibling polling tool get_email_test. The verb 'Process' and resource 'email-test session' are specific and non-tautological.

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 tells when to use this tool ('actively trigger parsing after the user reports sending the test mail') and when to use the alternative ('use get_email_test for passive status polling without processing'). This is strong, actionable guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this with 'Pure HTTPS GET, no auth, no side effects.' It adds concrete context about the default resource (llms.txt) and the full enumeration of discoverable files, which goes beyond the schema 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?

Three sentences, all information-dense: the first lists the exact resources and default, the second gives usage context and an explicit alternative, the third states transport/auth/safety. No filler or repetition of schema content.

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

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

For a single-parameter read-only tool, the description is nearly complete: it covers what files exist, the default, when to use it, the alternative, and the no-side-effect nature. It doesn't describe the exact response format, but with no output schema and simple enum-only input, this is acceptable and arguably unnecessary.

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 enumerates every valid enum value for the 'file' parameter and notes the default. This fully compensates for the schema's lack of prose, though it adds no new meaning beyond listing the options.

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 ('fetch') with a distinct resource (IntoDNS.ai discovery files), lists the exact file options, and distinguishes itself from sibling get_citation_guidance by noting the difference between canonical prompt-routing files and a topic-narrowed citation list.

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

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

The description explicitly states when to use it ('when an agent needs canonical citation URLs, machine-readable API surface, or prompt-routing hints') and explicitly names the alternative (get_citation_guidance) for a different use case. It also notes the default file behavior and no-auth nature.

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 idempotentHint annotations, the description adds substantial behavioral context: it reads the current CSP from header/report-only/meta tags, inventories external origins, is rate-limited to 3 scans per 10 minutes, caches results for 10 minutes, typically takes 30-45 seconds, and explicitly states nothing is changed. 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 detailed but every sentence adds value: purpose, output contents, use cases, alternatives, performance expectations, rate limits, and read-only confirmation. It is front-loaded with the core purpose and avoids 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?

Despite having no output schema, the description fully explains what will be returned: detected current policy with issues, per-directive origin inventory, generated report-only and enforce CSPs, and plain-language notes. It also covers constraints, caching, rate limits, and safety, making it complete for a tool of 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?

Schema description coverage is 100% for both parameters, so the schema already documents url and strict. The description adds useful context for url (same-origin crawl up to 20 pages, cache behavior) but does not add significant meaning for the strict parameter beyond the schema's 'fewer broad allowances'.

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: 'Crawl a live website... and build a Content-Security-Policy for it.' It clearly differentiates from sibling tools by naming generate_security_headers as the generic no-crawl alternative.

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?

Explicit usage guidance is provided: 'Use this when the user asks to audit, analyze, or create a Content-Security-Policy for a real site, fix CSP console errors, or harden a site against XSS; use generate_security_headers for a generic best-practice header set without crawling.' This states both when to use and 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description reinforces by saying 'Read-only — no domain mutation, no destructive side effects'. It adds useful context beyond annotations, such as speed (~3-8s) and detailed output structure (grade, score, issue list, recommendations, citation URLs), and explicitly states 'No auth'.

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 concise and front-loaded: two sentences total. The first sentence covers purpose and outputs, the second covers alternatives and follow-ups. No redundant words; every clause 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?

Despite having no output schema, the description enumerates return elements (letter grade, numeric score, structured issue list, prioritised recommendations, result sections, citation URLs). It also covers usage context, speed, safety, authentication, and alternative tools. For a single-parameter tool with rich annotations, this is fully complete.

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

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

There is only one parameter, domain, and the schema description already provides thorough coverage (100%) including format guidance ('Domain name only, e.g. example.com'). The description doesn't add parameter-specific semantics beyond what the schema covers, so baseline 3 is appropriate.

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

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

The description clearly states the action: 'Run the fast IntoDNS.ai DNS and email security scan'. It specifies the resource (DNS and email security) and distinguishes from siblings by mentioning alternatives like get_everything_report and start_deep_scan.

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?

Explicit guidance is provided: 'The default tool for agent-visible scan evidence' and alternatives are named with their specific advantages (deeper single-shot report, Internet.nl-grade analysis). Post-scan steps are also suggested: 'use explain_issue or generate_dns_fix on any returned issue'.

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 claims 'Read-only — no domain mutation' while the annotations set readOnlyHint=false, which is a direct contradiction. The description also does not disclose other behavioral aspects like side effects or long-running nature beyond what the annotation hints suggest.

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 clear and organized but contains some redundancy (e.g., 'Internet.nl' repeated, 'scan_domain' mentioned twice). It remains concise and focused without unnecessary bulk.

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 appropriately explains that a scanId is returned immediately and that polling via get_deep_scan_status is required. It also names cancel_deep_scan for aborts. However, it omits mention of error handling or rate limits, which would improve completeness.

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 descriptions cover all three parameters (domain, scanType, name) with adequate detail. The description does not add extra semantics beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool starts a long-running deep scan and distinguishes it from the faster scan_domain tool. It specifies the verb 'start' and the resource 'deep scan', making the purpose unambiguous.

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

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

The description explicitly states when to use this tool (when scan_domain output is not strict enough or when an Internet.nl-grade audit is needed) and when to use the alternative (scan_domain for sub-10s answers). It provides clear usage criteria.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior; the description adds useful context beyond those: 'Single HTTP GET, no auth, no destructive actions,' plus the internal chain-walking and signature-checking behavior. It does not contradict 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?

Every sentence earns its place: purpose, validation behavior, return contents, usage guidance, and protocol-level details. It is compact, 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 one-parameter tool with no output schema, the description is complete: it explains what is validated, how it behaves, what it returns (chain steps, algorithm grades, boolean valid), and when to choose it over an alternative. No significant context gap remains.

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 has full schema coverage with a clear description ('Domain name only, e.g. example.com (no URL, path, or port)'), so the description need not add much. It reinforces the semantic by saying validation applies when the domain claims DNSSEC, but adds no additional syntactic or formatting detail beyond the schema.

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

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

Description specifies a clear verb+resource ('Read-only DNSSEC chain validation') and details the validation process: walks DS/DNSKEY chain, checks signatures, algorithm strength, key rollover state. It also distinguishes itself from sibling lookup_dns by noting that tool is for raw key data only.

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?

Explicit guidance is provided: 'Use when a domain claims DNSSEC; use lookup_dns(type='DNSKEY') for raw key data only.' This directly states when to invoke this tool and names the relevant alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint:false, but the description adds valuable behavioral context beyond that: 'Registrant personal data is usually GDPR-redacted — that is normal, not an error' and 'Data is sourced live from the IANA RDAP bootstrap with an rdap.org fallback'. This clarifies expected outcomes and prevents the agent from misinterpreting redacted data as an error. 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 efficiently structured and front-loaded with the core purpose, then detailed in a logical order: returns, data source, caveat about GDPR, and usage examples. Every sentence adds value; no filler or repetition.

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

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

Given the single parameter and absence of an output schema, the description thoroughly explains what to expect for both domain and IP inputs, includes data sourcing details, normalizes the GDPR redaction behavior, and offers usage guidance. It is complete and self-contained for this read-only lookup tool.

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

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

Schema description coverage is 100% and the parameter description in the schema already states 'A domain name (example.com) or an IPv4/IPv6 address'. The tool description repeats this almost verbatim ('`query` is a domain name or an IPv4/IPv6 address'), adding no new meaning. Baseline of 3 is appropriate since the schema handles the documentation.

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 is a 'Read-only WHOIS/RDAP lookup for a domain or IP address', specifies the exact data returned for domains and IPs, and explicitly differentiates from the sibling tool 'lookup_dns' ('for DNS records use lookup_dns instead'). This matches the high standard of a specific verb+resource with sibling differentiation.

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

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

The description provides explicit when-to-use guidance: 'Use to check domain ownership, age, or expiry, vet a suspicious domain, or find an abuse contact'. It also gives a direct alternative: 'for DNS records use lookup_dns instead', satisfying the when-not-to-use requirement clearly.

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