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

Beyond the minimal annotations, the description extensively discloses behavior: it is paid via x402, the first unpaid call quotes the price, payment is supplied in `_meta['x402/payment']`, the receipt appears in `_meta['x402/payment-response']`, and no account or API key is needed. It also reveals that the wait is durable across process death and that the body is never returned, only the verdict.

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 core information is front-loaded and the payment flow is explained clearly, but the description is verbose for a tool definition. The closing feedback solicitation ('Complaints, questions, quote requests...') is not needed for tool selection or invocation, so not every sentence 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?

For a complex paid tool with no output schema, the description is remarkably complete: it explains the pricing model, the quote-then-pay sequence, where to put the payment, where the receipt will appear, how to read the result later, and that no account is required. The schema fills in the remaining parameter-level details.

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 input schema already covers all parameters at 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that price is a function of intervalSeconds × ttlSeconds and by framing the predicate as the condition that ends the watch, which helps the agent reason about how the parameters interact.

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: poll a URL from the service's vantage point on the caller's interval until a predicate matches or the TTL expires, then keep the verdict for collection. It clearly names the resource (a durable watch) and distinguishes itself from the sibling watch_read by explaining that the reply carries an id that watch_read can retrieve.

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?

It gives clear when-to-use context: an agent needs a wait that survives its own process dying, which the tool uniquely provides. It also explains the two-step paid workflow and points to watch_read for retrieving the result, but it does not explicitly state when not to use it or compare it against other sibling polling/monitoring tools.

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