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

Annotations already flag a non-readOnly, non-idempotent write, but the description adds genuinely non-derivable behavior: invalid replies are refused with the reason and the identical step is returned for re-run, and the call yields the next step or the finished episode. That explains the retry loop and the non-idempotent hint rather than restating it.

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 payload, followed by the return/refusal semantics; there is no filler and each clause carries information an agent needs.

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 correctly covers the return value (next step or finished episode) and the failure path. It handles the nested 'output' object at a conceptual level, though it does not describe the step/reply_format structure or the episode_id parameter, leaving minor gaps for a stateful multi-step workflow tool.

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 67% (episode_id has no description), so the schema does most of the work for output and agent_id. The description adds some meaning by tying the 'output' payload to the step type (character turn vs narrator recap), but says nothing about episode_id or agent_id, so it only marginally exceeds the baseline.

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 uses a specific verb+resource ('Hand in the output of the current step of a date') and enumerates the two payload shapes (speaking character's turn reply, narrator's recap JSON). An agent can distinguish it from the read-only sibling get_own_date_step by the 'hand in' framing, though the sibling is never named.

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?

Usage is implied rather than stated: you call it after producing a step's output, and if refused you re-run the same step. There is no explicit 'when not to use' and no named alternative (e.g. get_own_date_step to fetch a step instead of submitting one), leaving the agent to infer the workflow boundary.

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