deliverability-doctor

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

With no annotations provided, the description carries full behavioral disclosure responsibility, and it delivers. It states the method (public DNS only), denies any contact with the target ('Nothing is sent to the domain'), details the checks performed including a specific RFC edge case, and clarifies the output type ('graded report with concrete fixes'). This is unusually thorough for a tool definition.

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-loads the primary purpose, and every clause contributes information: scope, methods, output, input flexibility, and non-intrusiveness. No wasted words or repetition of the tool's name.

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 DNS tool with no output schema, the description is complete. It covers the operation's effect, the accepted input variants, the technical checks, the return format, and the side-effect profile. Nothing an agent needs to decide whether to call this tool 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 baseline is 3. The schema already documents that the single parameter accepts 'Domain, URL, or email address.' The description adds the phrase 'bare domain,' which slightly clarifies accepted formats but does not materially expand on the schema's meaning.

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

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

The description opens with a specific verb and resource: 'Checks whether a domain can be email-spoofed, using public DNS only.' It then enumerates the exact protocols checked (SPF, DMARC, MX, DKIM) and explicitly states it returns a graded report. This unambiguous scoping also distinguishes it from the sibling compare_email_security, which by name is comparison-focused rather than single-domain verification.

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

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

The description provides clear usage context: it is a passive, non-intrusive check that 'uses public DNS only' and sends 'nothing... to the domain.' This tells an agent when to select it (e.g., for safe reconnaissance). However, it does not explicitly mention the sibling tool or define when to use compare_email_security instead, so the alternative-selection guidance is implied rather than fully stated.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It states the core action and the return format, but does not mention whether the operation is read-only, any authentication requirements, or potential limitations. The basic behavior is transparent, but depth is limited.

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

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

The description is two concise sentences with no redundant wording. The primary action and output are front-loaded, and the second sentence adds a practical use case. Every word earns its place.

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

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

Given the tool's simplicity (1 parameter, full schema coverage, no output schema), the description is largely complete: it defines the input range and the return shape. It could optionally clarify what 'grades' mean or reference the sibling tool, but nothing needed to invoke 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?

Schema description coverage is 100%, so the baseline is 3. The description's '2–5 domains' repeats the schema's minItems/maxItems constraints without adding extra meaning. It does not clarify domain format, examples, or how the 'email-security check' is performed per domain.

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 (runs the email-security check), the resource scope (2–5 domains), and the output (comparison table with per-domain grades). It is distinct from the sibling check_email_security because it explicitly supports multiple domains and comparative output, though it does not directly name or contrast the sibling.

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 a useful example scenario ('checking your domain against competitors'), which implies when the tool is valuable. However, it does not explicitly state when to use this tool versus check_email_security, nor does it offer exclusions or alternatives.

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