get_script

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

With no annotations, the description carries the behavioral burden. It discloses that the call is free, that include_previous is off by default to avoid doubling response size, and that previous_script_available=true signals snapshot availability. It also notes that dramaturgy suggestions can be ignored if they don't affect the pipeline. This goes well beyond a bare read tool statement, though it doesn't address error/edge-case behavior.

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 dense but well organized: purpose first, workflow second, parameter-specific note last. Each sentence earns its place, though the long multi-clause sentences and inline annotations make it slightly harder to parse quickly than a more structured version would be.

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?

Given no output schema and no annotations, the description does a solid job of explaining what the tool returns, how it fits into the rewrite workflow, and when to request the previous snapshot. It lacks explicit mention of failure modes or response shape beyond the listed content, but for a simple read operation the description is largely complete.

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 50%: include_previous already has a schema description, and the tool description adds extra meaning by explaining the previous_script_available flag, the recovery use case, and the response-size rationale for the default. episode_id is self-explanatory and needs no elaboration, so the description compensates well for the partial schema coverage.

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 states a specific action ('读' a given episode) and enumerates the exact payload: raw content, AI-rewritten script, rewrite status, and dramaturgy suggestions. It clearly differentiates itself from rewrite_script and edit_rewritten_script by positioning this tool as the retrieval step in the rewrite workflow.

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 gives an explicit workflow: fetch rewritten_script with this tool, edit only the requested scenes, then submit via edit_rewritten_script without rerunning rewrite. It also explains when to set include_previous (recovery after accidental rerun or corruption), which is concrete and actionable.

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