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

With no annotations, the description carries the full burden and discloses almost nothing: it does not say whether replay is read-only or mutates live state, whether an active capture job is required, whether it blocks, or what happens to an in-progress session. Only the bare implication of 'start' hints at a stateful, resumable operation.

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 short sentence is front-loaded and wastes no words, but here the brevity reflects under-specification rather than efficiency. The one clause that exists ('for a step') is the least informative part.

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?

A four-parameter stateful tool with no annotations, no output schema, and 25% schema coverage needs a description that explains prerequisites, effects, and parameter roles. This one provides none of that, leaving the agent unable to call it confidently.

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 only 25% — notification_message is the sole documented parameter. The description says 'for a step' but never explains captureJobId (required), recordingId, or objectiveId, so the agent cannot tell which identifier selects the recording to replay or why captureJobId is mandatory.

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 verb 'Replay' plus the resource 'saved session recording' does identify the action, and the sibling stop_session_replay makes the start/stop pair inferable from the name. However, 'for a step' is vague and the description never clarifies what a 'step' is here, nor how captureJobId, recordingId, and objectiveId relate to it.

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?

There is no guidance on when to start a replay versus alternatives such as open_live_preview, jump_to_step, or resume_manual, and no mention of stop_session_replay as the terminating counterpart. The agent must infer the entire usage context from the name alone.

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