verify_page

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

Annotations already cover the safety profile (readOnly, non-destructive, non-idempotent), so the description's added value is strong: it discloses the skip-not-clean-verdict semantics on missing history and warns that page evidence is untrusted, both beyond structured fields. It still doesn't say how much history is required or what a skipped check does to the aggregate score.

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?

Four tight sentences, front-loaded with what the tool does and what it returns, then closing with the two operational caveats. No filler or restatement of the name.

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 no output schema, the description does sketch the return shape and the skip/trust caveats, which is the most valuable part. But for a tool with 6 parameters, a nested configurable policy, and no parameter documentation anywhere, the definition leaves a large gap an agent must close by reading the raw schema.

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% across 6 parameters including a nested policy object (severities, score_weights, ignore_http_statuses, overflow_tolerance_px). The description names none of these, so an agent gets no help on which checks can be requested, how severities/weights interplay, or what evidence_limit/timeout_ms control.

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 action (run deterministic checks) against a specific resource (current document measurements plus retained session diagnostics), and the return shape (statuses, severity, score, evidence references) tells an agent this is an aggregated verdict, unlike siblings such as get_console_errors or get_network_failures that return raw data. Sibling differentiation is implied by the aggregation framing rather than named explicitly.

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?

Usage is implied: this is something you run after a page has been exercised and diagnostics retained, since 'missing history yields skipped checks'. However, it never names when to prefer this over get_console_errors / get_network_failures or get_page_snapshot, nor states prerequisites such as an open session with recorded history.

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