get_run_status

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

With no annotations provided, the description carries the full behavioral burden, and it delivers: it explains the background task behavior, typical multi-minute durations, the meaning of running:true/false, and the caveat that service restarts clear in-flight registrations. It also clarifies that a lack of result within 60 seconds is normal rather than a failure.

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 long but every section earns its place: purpose, timing expectations, polling loop, destructive-resend warning, and restart caveat. It is front-loaded with the core purpose and uses clear labels, making it easy for an agent to extract actionable rules without redundancy.

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 one simple parameter, no annotations, and no output schema, the description provides everything needed to call the tool correctly: when to use it, what the result means, how often to poll, and what to do after the run completes. The absent output schema is adequately compensated by the explanation of running:true and running:false semantics.

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?

The input schema only exposes episode_id with an integer type and no description, so the description supplies the missing semantic context by tying the parameter to 'this episode' and to the specific long-running tasks that generate runs. It does not explain how to obtain the episode_id value, but for a single self-explanatory parameter this is sufficient to invoke the tool correctly.

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 clearly states the tool checks whether an agent is still running for a given episode ('查这一集当前有没有 agent 正在跑'), identifying the exact resource and operation. It also distinguishes itself from related tools by naming rewrite_script, extract_assets, and generate_storyboards as originating tasks and positioning this tool as the only way to tell 'still running' from 'finished'.

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?

It gives explicit polling guidance: call every 30–60 seconds, treat running:true as 'keep waiting', and only use get_storyboards/get_script once running:false. It also provides a strong when-not-to-act warning about not resending long-running tasks, making the decision boundary very clear.

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