check_dkim

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds behavioral context by explaining it probes multiple selectors, validates algorithm strength, and reports key strength, which goes beyond annotation details and helps the agent anticipate multiple DNS queries and analysis. No contradictions with 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 three sentences, each adding distinct value: what it does, what it validates, and when to use it. It is front-loaded with the primary verb and object, contains no fluff or redundant phrasing, and is appropriately sized for the tool's simplicity.

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?

Given the schema fully documents parameters and an output schema exists, the description does not need to explain return values. It covers purpose, usage context, and behavioral details (selector probing, algorithm validation, key strength reporting), which is more than sufficient for a read-only DNS checking tool. The description is complete for this complexity level.

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 100% parameter description coverage, so the baseline is 3. The description adds slight meaning about selector behavior ('Probes common selectors') which connects to the optional selector parameter, but it does not elaborate on format or force_refresh beyond what the schema already states. The added value is minimal but not redundant.

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 clearly states the tool looks up DKIM records for a domain, probes common selectors, validates signing algorithms (RSA-1024/2048, Ed25519), and reports key strength. This distinct purpose differentiates it from sibling tools like check_spf, check_dmarc, and check_mx, and the verb 'look up' combined with the resource 'DKIM records' is specific and actionable.

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 provides a clear use case: 'Use to verify that outbound email signatures are cryptographically sound.' It also notes it is part of the scan_domain audit, giving context for when it might be invoked. However, it does not explicitly state when not to use it or name alternative tools, though the purpose naturally excludes other DNS record checks.

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