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

Annotations cover only safety/idempotency hints, but the description adds the full operating model: baseline now, scheduled re-checks, a receipt that fires (and a per-fire charge that applies) only on content changes. It also discloses the payment mechanism (x402 v2 PAYMENT-SIGNATURE header), the price ($222.00 USDC on Base or Arbitrum One) and the paid endpoint, which no annotation conveys.

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?

Front-loaded with the decision rule before mechanics, and every sentence carries information (scope, schedule, charging, payment, cost). It is dense for a single paragraph and the rhetorical opening costs a few words, but nothing is padding.

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 paid, stateful monitoring tool with an output schema (so return format needn't be described), the description supplies everything else an agent needs: the selection rule against siblings, scheduling semantics, when billing occurs, and the exact auth/payment path.

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 100% and the idempotency_key semantics are documented in exhaustive detail in the schema itself. The description restates the URL and interval inputs without adding syntax or constraints beyond the schema's min/max, so this is the baseline 3 case where the schema does the heavy lifting.

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?

States a precise verb and resource ('watch... tell me when it changes') and frames the scope against the obvious alternative framing ('is it up now'). It explicitly names ping and prove_it as the one-time counterparts, so an agent can distinguish this standing monitor from siblings without opening a schema.

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?

Gives explicit when-to-use ('the question is not is it up now but tell me when it changes'), when-not-to-use (one-time checks are ping / prove_it), and the unique position ('watch is the only standing check'). Also states the valid interval range, removing the last decision ambiguity.

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