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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond these: it explicitly states the check uses only public information (DNS and HTTP requests), performs no port scanning or exploit testing, and explains how findings are structured. This exceeds the annotation coverage with relevant operational details.

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 detailed but not bloated; it front-loads the core answer in the first sentence and then expands on scope, return format, and security posture. Each sentence contributes useful information, and the alternative usage note is placed at the end. Slightly longer than strictly necessary, but every part earns its place.

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

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

With only one parameter and no output schema, the description carries the burden of explaining behavior and returns. It explicitly mentions the 0-100 score and findings tied to specific records, ensuring the agent knows what to expect. It also covers input restrictions and the broader scope of use, making it fully complete for correct invocation.

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

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

The schema fully documents the 'domain' parameter with constraints and a basic description. The tool description enriches this by specifying that bare domains work best, that full URLs or www prefixes are normalized, and that IP addresses, email addresses, or private/internal hostnames are refused. This adds practical guidance not present in the schema, going beyond the high coverage baseline.

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

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

The description states a clear, specific purpose: it answers whether a domain can be email-spoofed by checking SPF, DKIM, and DMARC records. It explicitly differentiates from the sibling scan_domain by scoping its focus to email authentication records and mentioning the broader alternative. This makes the tool's role 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 this tool: for any question about email spoofing, phishing impersonation, DMARC/SPF/DKIM setup, or domain protection. It also names the alternative (scan_domain) for a broader security picture, giving clear when-to-use vs. 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description does not contradict any of them. It adds substantial behavioral context beyond annotations: it explicitly states it 'makes ordinary GET requests for a small FIXED list of well-known paths', it does not brute-force/fuzz/enumerate, the list never grows or adapts, and it 'does no port scanning and no exploit testing'. It also discloses the operational fingerprint (requests are recognisable in logs), which is valuable for informed invocation.

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 average but every sentence earns its place: it front-loads the core purpose, then adds essential operational clarifications (fixed list, no enumeration), safety assurances (no port scanning), and usage context. There is no redundancy or filler; the structure is logical and information-dense without being bloated.

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 security-check tool with no output schema, the description comprehensively covers what an agent needs: what paths are checked (.env, .git/config, backups), how the check works mechanically, what it does NOT do, the return format (0-100 score plus per-path findings), and the target domain constraints. Given the tool's complexity and the absence of an output schema, nothing critical is missing.

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

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

Schema coverage is 100%, so the domain parameter is fully documented in the schema, establishing a baseline of 3. The description reinforces that bare domains work best and that IPs/emails/private hostnames are refused, but this largely duplicates schema guidance. The description adds minimal new semantic value beyond the schema, so a 3 is appropriate.

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

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

The description opens with a specific question ('is this domain publicly serving files it should not be?') and a precise verb-resource pair (checks a fixed list of well-known sensitive paths). It clearly distinguishes itself from siblings by stating what it checks (exposed files like .env, .git/config, backups) and what it explicitly does NOT do ('does not discover subdomains'), setting it apart from check_subdomain_takeover and scan_domain.

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 clearly states when to use this tool ('Use this for leaked secrets, exposed configuration, or accidentally published files') and what it excludes ('does not discover subdomains'). It implies differentiation from sibling scan_domain by describing a narrow, fixed-path check rather than a full scan. It could explicitly name alternatives, but the context is clear enough for an agent to decide correctly.

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

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

Annotations already mark the tool as read-only, open-world, idempotent, and non-destructive, and the description adds meaningful behavioral context: it uses only public DNS and ordinary HTTP requests, performs no port scanning or exploit testing, and returns a 0-100 score plus per-header findings. This goes beyond the annotations and is especially valuable since there is no output schema.

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 information-dense but every sentence earns its place: it opens with the core question, lists checked headers, explains the output, describes the non-invasive method, states the intended use cases, and points to the sibling tool for what it does not cover. There is 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?

With one parameter fully documented in the schema, safety annotations already provided, and no output schema, the description still explains the return value (score plus per-header findings), the method of checking, and what it does not cover. The tool definition is complete enough for an agent to invoke and interpret it correctly.

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

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

The schema description covers the single domain parameter 100%, including accepted formats and refused input types, so the description does not need to add much. The description adds no additional parameter detail beyond reinforcing that the domain is a website domain, which is appropriate given 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 states a specific verb ('Checks for') and resource (domain HTTP security headers), names the exact headers examined, and explicitly contrasts itself with check_tls by noting it does not check TLS certificates. This makes the tool's purpose unmistakable and distinguishes it from its siblings.

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 when-to-use guidance ('Use this for clickjacking, XSS mitigation, CSP or HSTS questions') and an explicit when-not-to-use case ('It does not check the TLS certificate itself — use check_tls for that'). It also clarifies what the check does not involve (no port scanning, no exploit testing), so an agent can select it appropriately.

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

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

The description goes well beyond the annotations. It discloses that the tool sends a small number of ordinary HTTPS GET requests to subdomains, resolves a fixed list of common subdomain names, and never registers, claims, or modifies anything. These details are not captured by readOnlyHint=true or other annotations and give the agent a clear picture of the tool's network behavior and safety profile. 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 front-loaded with the purpose, then explains the mechanism, clarifies non-actions, and ends with usage guidance. It is slightly long but every sentence carries relevant information—no fluff. The structure is logical and the critical safety points (HTTP requests, no modification) are given prominent placement. It earns a 4 rather than 5 because it could be tightened slightly without losing meaning.

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

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

There is no output schema, so the description must explain return values—it does: 'Returns a 0-100 score plus a finding per at-risk record, naming the record and the service it points to.' It also covers behavior, network impact, safety limits, and use cases. For a single-parameter tool with no nested objects, nothing an agent needs to call it correctly is missing.

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

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

The only parameter, 'domain', is fully documented in the schema with type, length constraints, accepted formats (bare domains best, URL or www. normalised), and exclusions (IP, email, private/internal hostnames). The tool description does not add any parameter-specific details beyond what the schema already covers. Since schema coverage is 100%, the baseline 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 opens with a precise question, 'does this domain have DNS records pointing at services someone else could claim?', and immediately states it inspects DNS records for dangling CNAMEs. This clearly distinguishes it from siblings like check_tls or check_security_headers, which target other concerns. The verb 'check' and the resource 'domain for subdomain-takeover risk' are specific and actionable.

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: 'Use this for dangling DNS, abandoned cloud resources, or subdomain hijacking risk.' It also clarifies what it does not do ('no port scanning and no exploit testing'), which implies exclusions. However, it does not explicitly name alternative tools or spell out when NOT to use it, though the sibling list makes those obvious. That is a minor gap from a 5.

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

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

Despite annotations stating readOnlyHint=true and idempotentHint=true, the description transparently discloses that the tool is NOT passive and triggers an active assessment from Qualys's infrastructure, which is a behavioral nuance beyond what annotations convey. It also clarifies it does no port scanning or exploit testing itself, and mentions it reuses cached results when available. This fully discloses the external side effect and safety profile without contradicting annotations—'readOnly' is still true in the sense of not modifying the target.

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

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

The description is well-structured and front-loaded with the core purpose, then lists specific findings, then warns about the active nature (critical for agent decision-making), and finally clarifies exclusions and sibling differentiation. Every sentence adds value, and the length is justified by the need to convey the active behavior and scope boundaries.

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

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

For a tool with one parameter and no output schema, the description is complete: it states what it returns (grade and specific findings), what it does NOT return (expiry, issuer, hostname validity), how it operates (external active assessment), and when to use it. It also covers edge cases (cached results) and exclusions. Nothing an agent needs to decide whether to call it and interpret results 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?

The schema already provides a thorough description of the 'domain' parameter: accepted formats, normalization, and explicit exclusions. The tool description adds no additional parameter-level semantics beyond what the schema states. Since schema coverage is 100% and the parameter is simple, the baseline of 3 applies—no further clarification needed.

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 precisely what the tool does: it answers whether a domain's TLS configuration has known weaknesses, returns the Qualys SSL Labs grade, and lists specific vulnerabilities it checks (Heartbleed, POODLE, RC4, etc.). It also distinguishes itself from siblings by explicitly saying it does NOT check HTTP security headers (use check_security_headers) and does NOT report certificate expiry/issuer/hostname validity, so an agent can differentiate it clearly.

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 when-to-use guidance: prefer it for a domain you own or are authorized to test, and warns it is NOT passive because it causes a third-party active assessment. It also provides exclusions (do not pass IP, email, private hostname) and points to the alternative tool for headers, plus suggests reading the certificate directly for expiry/issuer needs. This is complete routing guidance.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint=false, so the description's additional disclosure that it 'only reads scans that exist and are publicly retrievable by id' adds some context about access constraints. However, it doesn't elaborate on return format or error behavior beyond a brief mention of 'saved findings and score', which is not a significant behavioral disclosure.

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

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

The description is moderately concise, starting with a direct question and answer, then explaining usage in clear sentences. It front-loads the core purpose and efficiently states exclusions without excessive verbosity, though it could be trimmed slightly by removing redundant details.

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 provides a basic hint of what is returned ('saved findings and score') and outlines usage cases. It doesn't specify the exact structure of the result or handling of missing scans, but for a simple read-by-id tool with strong annotations, this is nearly complete.

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

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

Schema coverage is 100% and the schema description already explains the scan_id format ('from a nelprofessional.com scan page or report link'). The description repeats this but adds no new meaning beyond the schema, so a 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 it 'Fetches the stored results of a scan already run' by scan id, and explicitly distinguishes itself from scan_domain ('It cannot start a new scan: use scan_domain for that'). The verb and resource are 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?

It provides explicit when-to-use scenarios ('summarise it, compare it against a later scan, or turn it into a remediation plan') and names the alternative tool (scan_domain) for starting new scans. It also clarifies that it only reads publicly retrievable existing scans, leaving no ambiguity about scope.

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 and non-destructive, the description goes far beyond by detailing exactly what network actions occur (fetching well-known paths, resolving subdomains, querying Qualys SSL Labs which performs an active TLS assessment), and what does not happen (no port scanning, no exploit testing). This is critical context for a 'passive' scan tool and is unique added value.

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

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

The description is long but every sentence earns its place: it explains the scope, lists modules, provides usage guidance, clarifies 'passive', and sets expectations for authorization. It is front-loaded with the core purpose and then branches into detail. While not terse, it is well-structured and information-dense 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 complex scanning tool with no output schema, the description sufficiently covers what is returned (findings with per-module scores), safety implications, and operational boundaries. It notes the tool is free and explains why it is detectable in logs. An agent has all necessary context to decide when and how to invoke it.

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

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

The single 'domain' parameter is fully documented in the schema with restrictions (no IP, no email, no internal hostnames) and normalization behavior. The description adds no additional parameter-level detail, so given 100% schema coverage, the baseline of 3 is appropriate. It does not repeat or expand on the schema text.

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 runs every passive NEL VEIL module in one pass, returning findings with per-module scores. It explicitly differentiates from sibling tools by name ('check_email_spoofing', 'check_tls', etc.) and describes the broad use case ('how secure is this domain').

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

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

The description explicitly tells when to use this tool ('broad question') and when not to ('for a single specific question prefer the narrower tool'), names the alternatives, and even gives authorization guidance ('prefer running it against a domain you own'). This is comprehensive and leaves no ambiguity.

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