Record reproducible web flow

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

The description adds context beyond the annotations: 'execute' and 'store' indicate the tool performs real browser actions and persists a recording, which is consistent with destructiveHint=true and readOnlyHint=false; there is no annotation contradiction. However, it fails to disclose what makes the operation destructive (real side effects on the target application), that it depends on a live session, or what 'bounded' means operationally in terms of execution limits.

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 a single compact sentence with no filler, earning conciseness credit. But its structure is flawed: the list 'exact locator checks, named ordered checkpoints, optional desktop/mobile viewport contracts and failure scope' has ambiguous grouping - it is unclear whether 'optional' scopes only viewport contracts or also failure scope - making the sentence harder to parse than necessary.

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 tool with deeply nested schemas, 10 action kinds, 5 locator kinds, and 0% parameter documentation, a 28-word sentence is not nearly complete. It omits prerequisites (live sessionId), the action vocabulary, the relationship between checkpoints.offset and the actions array, and the required minimums on failureSignature and acceptanceChecks. The output schema covers return values, but input construction guidance is under-specified.

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%, so the description carries the full burden but only telegraphs concepts: 'viewport contracts' maps loosely to viewports/failureViewports, 'failure scope' to failureSignature, 'adaptive-risk signals' to risks, and 'named ordered checkpoints' to checkpoints. It does not explain the critical distinctions among acceptanceChecks, failureSignature, regressionChecks, and checkpoints, nor how sessionId, requestedLevel, buildReference, or serverStateReset should be populated. For 14 parameters with 6 required, this is materially insufficient.

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+resource ('Execute and store a bounded pre-fix reproduction') and enumerates distinguishing features (exact locator checks, named ordered checkpoints, viewport contracts, failure scope, adaptive-risk signals) that separate it from siblings like web_replay_seek or web_browser_action. However, the dense jargon ('pre-fix reproduction', 'adaptive-risk signals', 'viewport contracts') requires significant inference, and no sibling is named explicitly, so it stops short of full clarity.

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?

No when-to-use guidance is provided. The description never mentions alternatives, prerequisites (e.g., that an active session from web_session_start is required, given the required sessionId parameter), or exclusions. Only the phrase 'pre-fix reproduction' hints at a lifecycle context, but it is not explicit enough to help an agent choose between this tool and web_browser_action, web_issue_capture, or web_replay_seek.

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