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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), but the description adds genuinely non-structured context: per-call cost ($0.002 USDC via x402 across Base/Solana/Arc) and that failed calls are not charged, plus that revoked and CNAME-delegated DKIM keys are surfaced. This is meaningful cost/failure behavior an agent needs before calling a paid tool; only rate limits or latency behavior is unaddressed.

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?

Front-loaded with the resource and extracted fields, then the scope limit, then pricing — a sensible priority order. It is dense (one long first sentence) but nearly every clause is load-bearing; the pricing sentence is verbose yet justified for a paid tool.

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?

An output schema exists so return values need not be explained, and the description covers scope, reporting nuances (revoked/CNAME-delegated keys), and cost. Completeness is good; the only real gap is that it never points to the sibling DKIM/BIMI/DNS tools that overlap in purpose.

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, but the description adds semantics the schema lacks: the selector parameter falls back to trying 8 common selectors when empty, and the domain parameter is scoped to email-auth record lookups rather than arbitrary DNS. That fallback behavior is decision-relevant and earns above 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?

States a specific verb ('reads... DNS records') and resource ('DMARC, SPF, DKIM email authentication records'), and enumerates exactly what is extracted (p, sp, pct, rua; SPF all-mechanism; DKIM public keys). An agent can distinguish this from generic DNS or DKIM-only tools without opening the schema.

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?

Gives a clear scope exclusion — 'Reads the published DNS records only; it does not check alignment against a real message' — which tells the agent when this tool is the wrong choice for message-level authentication analysis. It does not name a sibling alternative (e.g., security_dkim_key_checker or security_bimi_record_audit), so it stops short of full 5-level routing guidance.

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