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

Annotations already mark it as read-only, non-destructive, and open-world. The description adds meaningful behavioral context beyond that: it performs MX, SPF, and DMARC lookups over DNS-over-HTTPS, returns a deliverability summary in JSON, and costs $0.003 USDC. This gives the agent a sense of what the tool actually does at runtime without contradicting 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 short and information-dense: it conveys purpose, method, output format, and price in three compact fragments. The structure is front-loaded with the core purpose. Slight awkwardness in the 'JSON. Price.' fragment prevents a perfect score, but every element 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?

For a tool with one required parameter, no output schema, and read-only annotations, the description covers the essential context: what is checked, how, the output format, and the cost. It does not describe what the 'deliverability summary' contains or how to interpret it, but that gap is minor given the simple input and the presence of the JSON 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 schema has a single required parameter 'domain' with a clear description and an example ('gmail.com'), giving 100% schema coverage. The description mostly restates the domain concept and doesn't add new parameter-level details such as accepted formats or normalization behavior, so it stays at 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?

The description opens with a specific verb+resource: 'Email domain deliverability check', then defines what that means with a concrete question ('Can this domain receive mail, and is it configured seriously?') and the concrete checks performed (MX, SPF, DMARC). This clearly distinguishes it from generic tools like dns_lookup or 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 gives clear context for when to use it: when you need to evaluate whether a domain can receive email and how seriously it's configured. However, it does not explicitly state when NOT to use it or name alternatives (e.g., dns_lookup for raw DNS records), leaving the exclusion logic to inference.

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