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

Goes well past the annotations: discloses the ~15s typical latency and the 25s wait ceiling, the daily quota (5 free / 15 paid), the one-script-at-a-time limit, and the prerequisite that the user has at least one video left. Annotations only flag it as a non-idempotent, non-destructive write; the quota-consumption behavior an agent must respect comes entirely from the text.

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 with the value proposition ("about 15 seconds without making it: free"), then workflow, then constraints, then the async fallback. Sentences are dense but each carries a distinct decision-relevant fact; nothing is boilerplate. Minor cost: some fragments ("free, it doesn't use any videos") read as crammed rather than clean.

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 7 params at 100% schema coverage and no output schema, the description supplies what structured fields cannot: latency, quota, the one-script-at-a-time limit, the prerequisite of remaining videos, and the handoff to make_video/get_script. The only soft spot is that the successful return shape (script id + lines) is implied through the make_video handoff rather than stated.

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 descriptions of idea, facts, style, voice, keyword and sales already carry their own meaning; the tool description mostly restates defaults and prerequisites rather than adding syntax or format guidance. The mention of "script_id + lines" pertains to the downstream make_video call, not to this tool's inputs. Baseline 3 for a well-documented schema.

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 ("writes the script of a video") plus the key differentiator — it does not produce the video itself, and it is free because no video is consumed. That contrast makes it immediately separable from make_video and preview_video_edit.

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?

Explicit workflow: generate, show the lines to the user, let them revise, then call make_video with script_id + lines. It also names the fallback path ("if it isn't ready yet, call get_script") and the eligibility condition, so both the happy path and the alternative are covered.

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