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

With no annotations, the description carries the full burden and does so well: it discloses per-page failure isolation ('a page that cannot be fetched is named individually and does not fail the batch'), the dual-hash behavior that lets markup churn be separated from real content change, and the commercial terms (60000 atomic USDC on Base via exact x402, with MCP handing off a challenge rather than paying). These are exactly the non-obvious traits an agent needs before invoking.

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?

Five sentences, each carrying distinct information: purpose and scope first, then the differentiator (change report vs raw hashes), then hashing rationale, then failure behavior, then payment. No restatement of the name or title and nothing padding-like.

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 nested-parameter tool with no annotations and no output schema, the description covers purpose, failure isolation, and the x402 payment handoff. It does not sketch the per-page result shape (e.g. changed/no_baseline/error fields) or clarify whether payment is per batch call, which would matter for an agent orchestrating repeated watches.

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 100%, including the baseline map's 'url to text_sha256 you last saw' semantics and the origin allowlist on urls, so the schema already does the heavy lifting. The description adds only the interpretive framing ('supply the previous text hashes', 'returns which pages actually changed'), which is useful but marginal over structured data. Baseline 3 is appropriate.

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 specific verb and resource with scope ('Watch up to ten reviewed public pages in one call') and immediately clarifies the return semantics: which pages changed rather than ten raw hashes. The 'in one call' / batch framing plus the dual HTML-and-text hashing rationale distinguishes it from the single-page page_fingerprint sibling without needing to open either 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 clear context for use: batch watching of up to ten pages, and that you must 'supply the previous text hashes' for change detection to be meaningful (otherwise every page reports no_baseline, per the schema). It never explicitly names an alternative such as page_fingerprint for single-URL work or states when not to batch, so it stops short of full routing guidance.

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