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

Adds real provenance beyond the annotations: the check is evaluated against the live page at plan time, similar existing checks are surfaced, monitor cost is compared to remaining quota, and open decisions are returned for the user. 'Saves the plan and changes nothing in the account' correctly reconciles with readOnlyHint=false/destructiveHint=false. Idempotency and any auth requirements are unaddressed.

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 correctly with the trigger condition, but the return-value sentence is a five-clause semicolon run-on ('...or the automatic checks that hold there when no check is named; any check of the site...; its cost in monitors...; and the decisions...') that is hard to parse on one pass. Length is defensible given 13 params and no output schema, but the packaging costs readability.

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?

With 13 parameters, no required params, and no output schema, the description carries the full burden of explaining returns — and it does: pass/fail of the live trial, text locations, automatic checks when none is named, duplicate-check detection, quota cost, and outstanding decisions. An agent has enough to select and call it correctly.

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 a very thorough selector description and an enum for check_type, so the schema already carries the parameter burden. The description adds only partial meaning — the severity/interval/name decision ids behind `answers` are hinted at ('the decisions to put to the user: how serious a failure is and how often to check') but no parameter is explained directly. Baseline 3 applies.

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 object ('plan/watch what a page says or shows') and enumerates the concrete check families (text/button presence, error absence, price range, change detection). It explicitly distinguishes itself from the nearest sibling: 'Not for whether the site is up: plan_site watches that.'

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?

'Use this when the user wants FlareWarden to watch...' gives a clear triggering condition, and the closing clause rules out plan_site. It also covers the revise path ('plan_id ... to change it or answer its decisions') and the delegate path ('accept_recommended'). What it omits is routing to add_content_check for actually creating the check — the plan/apply relationship is implied by 'Saves the plan and changes nothing in the account' but never named.

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