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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals that this is a network read operation that also mutates state ('mark the domain active') and that it's a polling operation subject to propagation delay. It doesn't cover the negative case (what happens when records aren't yet visible) or idempotency, but the core behavior is clearly exposed.

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?

Two sentences, zero waste, with the core action front-loaded in the first sentence and the timing caveat delivered efficiently in the second. Every part 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?

The tool is simple (1 param, no output schema) and the description covers action, condition, and polling timing. However, gaps remain: the `name` parameter is never explicitly defined, and — critically for a propagation-dependent tool — the description doesn't state what happens when records aren't yet visible (failure, retry, or no-op), which an agent needs to handle the polling loop correctly.

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% — the single required `name` parameter has no meaning in the schema. The description never explicitly defines `name` as the domain to verify; it only implies it through repeated references to 'the domain.' Since coverage is zero, the description must compensate by defining the parameter explicitly, and it does so only implicitly.

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 states a specific action — 'Re-read DNS now and mark the domain active' — tied to a clear condition ('if its SPF and DKIM records are visible'). The verb+resource is precise and clearly distinguishes this from siblings like add_domain (creation) and list_domains (listing), establishing verify_domain as the activation/verification step in the domain lifecycle.

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 practical timing guidance: 'DNS takes minutes to hours to propagate; poll this every few minutes, not every few seconds.' This tells the agent when and how often to invoke the tool during propagation. It doesn't explicitly name alternatives or state when not to use it, but the polling cadence is concrete and actionable.

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