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.

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

Annotations already cover safety (readOnlyHint true, openWorldHint false), yet the description still adds real behavioral content: the exact verdict set, the rule that a problem only counts as gone when a complete run verified it, and that early-stopped runs are never treated as fixes. It does not discuss failure modes for invalid report paths or how verdicts are weighted, keeping it below a 5.

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?

Three dense sentences, all front-loaded: purpose and return shape first, then the correctness rule, then the input-volume hint. No sentence is redundant and nothing is buried.

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 carries the return value and does so by naming the verdicts and the Markdown block, which is enough for an agent to know what comes back. The remaining gap is minor: it never says what happens when the sides are from different checks or how a bad path surfaces.

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%, so the baseline is 3. The description does add meaning to the array parameters — it explains why multiple reports per side are allowed (repeated runs) and gives the label parameters concrete purpose ("such as main and a branch"), but it contributes no format details beyond the schema.

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?

The description gives a precise verb and resource ("compares reports of the same check from before and after a change") and enumerates the full verdict vocabulary plus the returned artifacts (per-problem outcome, Markdown PR block). It does not name the closest sibling (verify_change) or state how it differs, so it stops short of full sibling differentiation.

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?

"Give several reports per side for repeated runs" is an explicit usage instruction, and the "complete run" rule tells the agent when a comparison result is trustworthy. There is no guidance on when to prefer verify_change or what to do when inputs come from a single run, so exclusions are absent.

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

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

Annotations already mark it read-only and open-world, and the description adds genuinely new limits: only successful page-fetch and XHR reads are captured while native, IPC and service-worker traffic is invisible. That coverage gap is the key behavioral fact an agent needs before trusting a negative result; only the return format/pagination detail is missing.

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?

Three short sentences with zero filler, front-loaded with the mechanism and output, then the hand-off, then the limitation. Every sentence earns its place.

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 carries the burden of describing results and does so ('lists the JSON GET requests'), plus a caveat about what it misses. It could say more about ordering, volume, or how signed-in state affects visibility, but an agent has enough to 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 coverage is 100%, so durationMs, url and storageState are already documented, but the description still adds meaning by tying capture to the page-load window ('while it loads'), clarifying what durationMs governs. Marginal but real value on top of the schema.

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?

The description states a specific verb and resource ('Opens a page in headless Chromium and lists the JSON GET requests it makes while it loads') and scopes the output to JSON GET reads, which clearly separates it from siblings like compare_reports or verify_change.

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?

It gives an explicit downstream use: 'Use it to choose the endpoint for check_read_recovery,' which tells the agent when this tool precedes another. There are no explicit when-not conditions or named alternatives beyond that hand-off, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds the meaningful detail that sources are analyzed statically "without running them," and it discloses the TypeScript dependency, which the annotations do not. It also sketches the response shape (each suspect names the read and the check), going beyond the structured fields without contradicting them.

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 is scanned and what counts as a suspect, then the workflow tip and the prerequisite. Nothing repeats the title or the schema verbatim, and every sentence contributes.

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 compensates by explaining what a returned suspect contains, and it covers the static-analysis behavior, the branch-diff workflow, and the TypeScript requirement. For a three-optional-parameter read-only scanner, nothing an agent needs in order to call it correctly is missing.

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%, so paths, changedSince, and includeTests are already fully documented, and the description only echoes the changedSince="main" case. Baseline 3 is appropriate; the description adds negligible semantics the schema does not already carry.

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?

The description gives a specific verb and resource ("Reads JavaScript and TypeScript sources, without running them") and names the two exact defect patterns it looks for, UNKNOWN_AS_EMPTY and FAILURE_ONLY_LOGGED, which makes the tool's remit unambiguous. It never names or contrasts with the sibling read-analysis tools (find_page_reads, check_read_recovery), so an agent working from names alone still has to infer the split.

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 changedSince \"main\" to scan only what a branch changed" supplies a concrete usage context, and "Needs TypeScript in the project" is a real prerequisite that prevents failed invocations. There are no explicit when-not conditions or pointers to the sibling tools for adjacent questions, so the guidance is clear but not complete.

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

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

readOnlyHint=true already tells the agent this is a safe read with no side effects, so the bar is lower. Beyond that, the description adds genuinely useful signal: what is counted (total proxy connections, per-rule matches and faults) and how to read a zero-fault rule as a likely misconfiguration.

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?

Two tight sentences. The core output description comes first, and the troubleshooting hint follows, so an agent gets the essential behavior immediately.

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 must convey the return shape, and it does: a total proxy connection count plus per-armed-rule matched and faulted counts. Adding an explicit note on when to run it relative to the start/set tools would make it complete.

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?

The tool takes zero parameters, so there is no parameter semantics for the description to explain. The baseline for a parameterless tool applies cleanly, and there is nothing misleading about the omission.

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: reports proxy connection counts and, per armed rule, matched and faulted counts. This clearly separates it from the sibling control tools (start/set/stop_network_faults) which configure rather than report.

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?

Mentions 'armed rules', implying this is consulted after rules are set, but never explicitly says when to call it versus siblings like compare_reports or find_suspects. The line about a rule that faulted nothing indicates a misconfigured host or unused proxy, which is useful diagnostic guidance even though it is about interpreting results rather than selecting the tool.

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

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

Adds genuine behavior beyond the annotations by disclosing the return value ('exit code and output') and the accepted command set. However, despite destructiveHint=true and openWorldHint=true, it never warns that commands may mutate state or require setup/permissions, and 'See the package docs' defers the details an agent most needs before invoking an arbitrary-command runner.

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?

Well front-loaded, but the same command list is enumerated twice — once inline with parenthetical qualifiers and again as a flat 'Commands:' list — which is pure repetition. The closing 'See the package docs' sentence mostly shifts work elsewhere rather than informing.

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?

Covers the essentials for a generic command runner with no output schema: valid commands, output shape (exit code + output), and --json. Missing is any statement of side effects, permission/setup requirements, or what happens on failure for a tool flagged destructive and open-world, which is a meaningful omission for a catch-all runner.

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?

The schema documents args only generically, but the description supplies the actual valid command vocabulary (check, discover, action, reads, windows, observe, refresh, android, doctor) plus --json guidance, which meaningfully constrains args[0] where the schema has no enum. timeoutMs is never mentioned, and 'see the package docs' leaves per-command configuration unresolved.

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 ('Runs a Recovery Probe command') and enumerates the concrete commands it accepts, so an agent knows exactly what surface it covers. The 'has no dedicated tool' phrase is a strong scoping clue that differentiates it from named siblings, though 'Recovery Probe' itself is jargon that offers no domain anchor.

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 a clear fallback rule: use this only for commands that have no dedicated tool, which is exactly the routing decision an agent needs when siblings like check_read_recovery or network_fault_summary exist. It also advises passing --json where supported, but never names a specific sibling to prefer or states what happens when a dedicated tool does exist.

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

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

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds genuinely non-obvious behavior: the call replaces rather than merges existing rules, fault windows are measured from invocation time, and dropOpen forces reconnection for persistent clients. No contradiction with the annotations, though it doesn't explain whether the change is reversible or scoped to a session.

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?

Three short sentences, front-loaded with the replacement/restore contract ahead of the secondary details. Dense and jargon-heavy but every sentence carries a distinct fact; minor packing of two ideas into the dropOpen sentence.

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 rule-array fault-injection tool with no output schema and no annotations covering side effects, the description covers the replace/restore contract, timing origin, and dropOpen. It still leaves the fault modes and count semantics unexplained, which is a meaningful gap for correctly constructing a rule.

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% and only the host pattern has any inline documentation, so the description must compensate. It does explain restore and dropOpen and clarifies that fromMs/untilMs windows are relative to this call, which is valuable, but the fault enum values (refuse/reset/stall/delay) and count remain undefined anywhere.

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?

The description states a specific verb and semantics: it replaces the armed rule set, or clears it entirely via restore: true. It doesn't name the sibling tools (start_network_faults/stop_network_faults) that an agent would otherwise confuse this with, so sibling differentiation is only implied.

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?

It gives conditional guidance for one branch ('removes them all with restore: true') and implies replacement semantics for the other, which is useful. But it never says when to prefer this over start_network_faults or stop_network_faults, leaving the main routing decision to inference.

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

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

Annotations already declare this is non-read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: connections pass through until rules are armed, faults apply per host to whole connections, and HTTPS remains end to end. It does not describe the returned environment's structure in detail, but the key runtime behavior is disclosed.

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?

The description is three tightly written sentences with the primary action front-loaded. Each sentence contributes useful scope, usage sequencing, or behavioral detail, and there is no redundant repetition of annotations or schema constraints.

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?

The description covers the tool's main behavior and its relationship to set_network_faults, which is the most important context. However, with no output schema, the returned environment is only mentioned vaguely, and the sole input parameter is not explained at all. For a startup tool with one optional parameter, those gaps leave it only minimally complete.

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?

The schema has one optional parameter, port, with 0% description coverage. The description never explains what the port parameter controls, whether it has a default, or what happens if it is omitted or already in use. The schema only provides type and range constraints, so the parameter's meaning remains undocumented.

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?

The description states a specific verb and resource: starts a loopback HTTPS proxy for an app's own connections. It also scopes the proxy to SDKs, main processes, CLIs, or test runs, making it distinguishable from sibling tools that arm faults or stop the proxy.

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?

It gives clear usage context: start the app or tests with the returned environment. It also routes the agent to set_network_faults for arming rules and clarifies that connections pass until then. It does not explicitly cover when not to use this tool or when to call stop_network_faults, so it falls short of a full 5.

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

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

Beyond the annotations, the description discloses three concrete side effects: all faults are removed (not selectively), the proxy is closed, and a final summary is returned. It stops short of stating idempotency behavior or what happens if no proxy is running, which matters for a teardown call.

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?

One short, front-loaded sentence with the primary action first and the byproducts after. No filler.

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 zero-argument teardown with annotations covering safety, this is nearly complete: side effects and the returned summary are named. The remaining gap is that the summary's shape is unspecified and there is no output schema to fall back on.

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?

The tool takes zero parameters, so there is nothing to disambiguate; the description correctly says the scope of removal is everything rather than a subset. Baseline for a parameterless tool 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 resource ('removes every fault, closes the proxy') and implies the teardown counterpart to start_network_faults and set_network_faults. It is clear what the tool does, though it never names a sibling tool to sharpen the boundary.

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: the agent must infer that this is the cleanup step after start_network_faults. There is no explicit when-to-use/when-not, no prerequisite (e.g. an active proxy), and no mention of the summary-only alternative network_fault_summary.

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

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

Annotations only declare that this is not read-only and is closed-world; the description adds substantial behavior beyond that: it records baseline runs, reruns checks, compares both sides, scans changed lines, and defines the VERIFIED condition and NOT_VERIFIED gating. It stops short of describing response formatting or persistence details, but the verdict semantics are unusually well disclosed.

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?

The description is dense but front-loaded: the baseline workflow comes first, then the verification mechanism, then the pass/fail rule. Most sentences carry useful information, though the phrase about scanning changed lines is slightly compressed.

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 stateful verification tool with no output schema, the description sufficiently explains prerequisites, invocation timing, what the tool does, and what determines VERIFIED versus NOT_VERIFIED. It does not document the plan file format, but that is deferred to the plan file itself.

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%, so the schema already defines the plan path and baseline boolean. The description adds operational meaning beyond the schema by explaining when to set baseline true versus false and how the plan file drives the verification checks.

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 (verify), resource (a code change), and evidence model (before/after runs). It clearly positions itself against siblings like find_suspects and compare_reports by explaining that it reruns the plan's checks, compares runs with the baseline, and scans changed lines for suspects.

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?

Explicitly instructs the agent to call with baseline true before changing code and without it before declaring the change done. It also states a clear exclusion: do not call a change done while it is NOT_VERIFIED.

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