Check that a page recovers when a read fails

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

Annotations say readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description is consistent with that: it drives a real browser, injects transient network faults, and clicks a retry control. It adds meaningful context beyond the annotations, notably that artifacts are written to a report folder with fix-brief.md and reproduce.mjs, and that faults run one endpoint at a time. It stops short of stating auth/session requirements (storageState) or the side effects of leaving faults applied if the run aborts.

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?

A single front-loaded sentence that leads with the action (loads healthy, then fails one GET) before the recovery logic and return payload. It is dense but every clause earns its place; the return-value enumeration is slightly overstuffed for one sentence but not wasteful.

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 10 parameters, no output schema, and open-world behavior, the description does a creditable job covering the return shape (outcome per fault, baseline failure reason, on-screen text, report folder). What is missing is failure/abort semantics and environment preconditions, but for a tool of this complexity it is close to sufficient.

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 70%, so the description must carry some load, and it does: it explains that recovery mode selects automatic-vs-retry behavior, that retrySelector only matters in 'retry' mode, and that each fault kind is exercised against a single endpoint. It adds no meaning for timeoutMs, storageState, readyText, or times, which the schema already documents adequately.

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 unusual precision: load healthy, fail one GET endpoint per fault kind, verify the ready marker returns either automatically or after clicking retrySelector. The one gap is sibling differentiation — run_recovery_probe and the start/stop_network_faults family are never named or contrasted, so an agent must infer that this is the end-to-end composite rather than a primitive.

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 only implied by the mechanics described; there is no explicit 'use this when' or 'prefer X instead' statement, and no stated prerequisites (dev/test app, browser availability) beyond a hint carried in the url parameter's schema text. The recovery enum ('automatic' vs 'retry') tells the agent it must know which recovery strategy the page implements, but not how to choose the tool.

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