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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered by structured data. The description is consistent with this but adds almost nothing: it does not mention that this performs a live DNS lookup, what happens on NXDOMAIN or missing selector records, or how failures are reported. The added value is minimal beyond confirming the read semantics.

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?

One short, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity borders on under-specification rather than ideal density.

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 should convey what comes back — raw TXT record, parsed key, validity verdict, or error — but it does not. For a diagnostic DNS tool the agent cannot predict the response shape or interpret an empty result, which is a meaningful gap.

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 carry parameter meaning, yet it only restates the two parameter names inline ("domain and selector"). It does not explain what a DKIM selector is or how a wrong selector causes an empty result, leaving the agent dependent on the schema's regex pattern alone.

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?

Specific verb and resource: "Read the DKIM public key record for a domain and selector." It clearly separates itself from check_spf, check_dmarc, and check_bimi by naming the DKIM record type, though it does not explicitly reference any sibling tool for contrast.

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?

There is no guidance on when to use this tool, no prerequisites (e.g., domain must be DNS-resolvable), and no mention of related tools like check_dmarc or check_dns_propagation that an agent might need alongside it. The agent must infer the usage context entirely from the name.

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