Verify domain authentication

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the operation reads public DNS, which is useful behavioral context, and that it reports each record. No contradiction with annotations, but it does not disclose potential edge cases like DNS lookup failures or rate limits.

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 sentences with no waste. The primary action and scope are front-loaded in the first sentence, and the second sentence provides a concise rationale without derailing the core definition.

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 what the tool reads and why, and the read-only annotations cover safety. However, it lacks an explicit explanation of the dkim_selector parameter and does not describe the exact return format or how to interpret the reported records. With no output schema, a bit more detail would make it fully self-contained.

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 0%, so the description must compensate. 'Domain' is clearly implied as the domain to check, and 'DKIM' hints that dkim_selector is related to DKIM lookup. However, the optional dkim_selector parameter is never explicitly explained, and there is no guidance on how omitting it affects the DKIM check. This is a meaningful gap for a two-parameter tool.

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 ('Read') with a clear resource ('SPF, DKIM and DMARC for a domain in the public DNS') and states the output ('report each record'). This distinguishes it from siblings like vaemail_dns_requirements (setup requirements) and vaemail_diagnose_deliverability (broader deliverability diagnosis), making the tool's role 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 implies a usage context by warning 'Without SPF and DMARC, large mailbox providers file the mail as spam,' which suggests this tool is for checking authentication before sending. However, it does not explicitly state when to use this tool versus alternative sibling tools, nor does it mention any exclusions or prerequisites.

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