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

Annotations declare readOnlyHint=false and idempotentHint=false; the description usefully confirms the write side effect ('Records an anonymous play'), which is exactly the context the annotation bar asks for. It also discloses the two-chapter one-at-a-time behavior. It stops short of clarifying whether repeated calls create duplicate plays, which matters for a non-idempotent tool.

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 sentences, front-loaded with the action and followed by the return shape; no filler. The parenthetical is dense but earns its space by summarizing the script payload.

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 contract and does so adequately (script contents plus play id). For a 9-parameter, non-idempotent entry-point tool the remaining gap is interaction between chapter and play_id on resume versus start, which the description only partially covers.

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 documents slug-vs-title, chapter, play_id and every code parameter. The description restates chapter-at-a-time and play id but adds no syntax or precedence rules (e.g. what wins when slug and versus_code are both sent). Baseline 3 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?

Names a specific verb+resource ('Loads a Plot Speaks story by slug or title') and states the two outputs (script and play id). It does not name the sibling it supersedes (list_stories, open_plot_speaks), so the agent must infer the boundary from the sibling list alone.

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 'starter' role is only implied by 'Records an anonymous play' and the chapter/play_id relationship described in the description. There is no explicit when-to-use-this-vs-alternatives guidance naming open_plot_speaks or list_stories, which an agent would need to pick correctly.

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