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

The description asserts a complete no-op ("Nothing is read or changed"), while the annotations declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, i.e. a mutating, potentially data-destroying operation. The two signals directly conflict, so an agent cannot tell whether invoking this is harmless or irrevocable. Annotation Contradiction.

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 critical fact is front-loaded in the first two sentences and there is no boilerplate padding. Slight redundancy between "does not read a do-not-disturb window" and "would not change who can reach you," but both are short and clarifying.

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?

For a stub tool with no output schema, the description tells the agent everything needed to avoid a useless call. However, with six fully undocumented parameters and annotations that contradict the stated no-op behavior, an agent lacks the context to reconcile the safety profile.

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 0% for six parameters, including consequential-sounding ones (confirm, acknowledgedAmountUsd, idempotencyKey) that the description never mentions or explains. The only implicit guidance is that parameters are irrelevant because nothing happens, which does not help an agent that decides to call it anyway.

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 identifies the resource (a do-not-disturb window) and immediately states its actual status: the call router ignores such a window and the tool is not yet supported. That is more useful than a bare verb+resource statement, though it never contrasts itself with the sibling clear_do_not_disturb, which an agent could reasonably confuse it with.

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?

"This tool is not yet supported" plus "would not change who can reach you" is an unambiguous do-not-use signal, which is exactly the guidance an agent needs here. It stops short of naming an alternative (clear_do_not_disturb, or set_availability for reachability), so a 4 rather than a 5.

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