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

Annotations already cover read-only and idempotency, and the description adds real operational context: a 30-second ceiling, the fact that timing out is expected rather than an error, no replay of missed changes, and a per-IP concurrency cap. The phrase 'no replay or burn values' is cryptic but the rate-limit and timeout semantics are genuinely beyond what annotations convey.

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?

Three short sentences, front-loaded with the core behavior, with no filler. The one weak spot is 'no replay or burn values', which reads as internal jargon that an agent cannot act on.

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 explain what a returned change looks like versus a timeout, and it does not. Combined with three undocumented parameters and no guidance on how `last` interacts with the wait, the definition leaves too much for an agent to infer.

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 explain `key`, `last`, and `timeout` — and it only restates the 30-second bound that the schema already enforces via maximum. The `last` parameter, which appears to be the caller's known prior value and is central to correct invocation, is completely unexplained.

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 verb 'wait' and the notion of a 'visible change' are stated, but the resource is left implicit — the required `key` parameter suggests it watches a key, yet the description never says so. Against siblings like get_key and put_key, an agent can guess this is a blocking variant, but the definition does not make that distinction explicit.

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 notes that a timeout is a normal outcome, which is useful framing, but it never says when to choose this over polling with get_key or when to avoid it. There are no stated prerequisites and no named alternatives among the ten sibling tools.

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