replay_status

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

No annotations are supplied, so the description carries the burden and does so: it declares read-only semantics, states 'SIDE EFFECTS: None' and 'LIMITATIONS: None'. That is more than most read tools provide, though it does not discuss failure modes such as querying when replay is inactive.

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?

Front-loaded purpose followed by labeled WHEN TO USE, SIDE EFFECTS, and LIMITATIONS sections. Every sentence is short and earns its place; 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?

With no output schema, the description compensates by listing the returned fields (active, timestamp, position), and with no annotations it declares the read-only profile. Adequate for a parameterless status probe, though the exact response shape and inactive-replay behavior remain unstated.

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?

Zero parameters with 100% schema coverage, so the baseline is 4. There is nothing further for the description to clarify about inputs.

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 ('Get current status of Bar Replay mode') and enumerates the return content (active, current replay timestamp, position). This cleanly distinguishes it from siblings like replay_start, replay_step, and replay_stop.

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 'WHEN TO USE' clause gives a clear condition: check whether the chart is in replay mode and what timestamp is displaying. It does not explicitly name alternatives or exclusions, but the retrieval vs. mutation distinction is obvious from the sibling names.

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