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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently warns that the payload is 'Heavy', which is valuable performance guidance. It enumerates the full data shape returned, so the agent knows what to expect. It doesn't explicitly state the tool is read-only/non-mutating, but given the flow_replay_* sibling set (with start/abort as mutation ops), the read-only nature is reasonably inferable from context.

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 tightly packed single sentence followed by an imperative usage warning. Every clause earns its place, and the heavy-payload warning is front-loaded near the end. It could arguably be split into shorter sentences for scanability, but it's efficient and wastes no words. Slightly verbose list of fields, but that list is the core value proposition.

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 diagnostic read tool with 100% schema coverage and zero parameters needing explanation, the description is largely complete. It explains what triggers it (stepIndex from summary), what granularity it returns (one step), and warns about cost (heavy). No output schema exists, so the field enumeration in the description serves the role of documenting return values. The main gap is not explicitly stating the tool doesn't mutate state, but the replay_* sibling set makes that clear.

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%, so the schema already documents both parameters thoroughly (replayId and stepIndex with 1-based note). The description adds value by explaining stepIndex comes from flow_replay_summary and clarifies the 1-based semantics, which the schema also states. The description's enumeration of returned fields relates to the output rather than the input params, so it adds marginal but non-duplicative context over the schema. Baseline 3 is appropriate.

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 clearly states it returns full data for ONE step of a replay, enumerating exactly what's included (action type, recorded element, locators, coordinates, page-source XML, scores, error message). The scope is crisp (one step vs the summary/status siblings), and it explicitly distinguishes from flow_replay_summary via the 1-based stepIndex note. Very specific verb+resource+scope.

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?

The description provides clear usability guidance: 'Heavy — call selectively for steps you want to diagnose.' This tells the agent when to use it (diagnosis) and implies when NOT to (avoid calling for every step given the payload weight). It references flow_replay_summary as the source for the step index, establishing a sequencing relationship. However, it does not explicitly name an alternative lighter tool for non-diagnostic needs, so it misses full points.

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