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

No annotations are present, so the description carries the full disclosure burden. It adds a valuable non-obvious behavioral caveat: DNSBL lookups via public resolvers are often rate-limited, so a null `listed` result means 'unknown', not 'clean'. This goes beyond the obvious read-only implication of 'check'.

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 the scope list front-loaded and the caveat kept as a separate note. Every element earns its place, though the comma-separated enumeration is dense.

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?

All functional areas of the check and the most confusing result interpretation are covered. It stops short of describing the overall output shape, but the mention of a `listed: null` field offers a partial view of the return.

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 already fully documented in the schema with a 'Bare domain' example, and the description adds no new constraints or formatting details. Baseline 3 for high schema coverage 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?

Describes a specific resource ('a domain') with a precise verb ('Deep-dive ... check') and enumerates the exact tests performed (MX, PTR, DKIM, SPF, DMARC, DNSBL). The detail clearly differentiates it from siblings like email_address_validate or dns_propagation_check.

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

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

While it frames the tool as 'deep-dive', it does not explicitly say when to choose this over alternatives like domain_health_check or email_address_validate, nor does it state exclusions. Usage must be inferred from the scope of checks.

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