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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, but the description adds non-obvious behavior: the call is free/no-credits, the breakdown is asynchronous and takes minutes, and downstream paid steps require a human approval gate. It does not say what state the project is left in on partial failure or any rate limit, so it stops short of a 5.

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 core action and cost, then the timing caveat, then the pipeline, then the payment rule. Every sentence carries information, though the pipeline and payment sentences make it slightly long for a creation tool.

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 points to story_get_project for retrieving results and explains the async delay so the agent does not expect an immediate payload. Combined with annotations and a mostly-covered schema, an agent has enough to invoke it correctly; minor gaps remain around failure/partial-state behavior.

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 description coverage is 67%, so the schema already documents script_text, collection_id, output_language, and the episode-targeting options. The description only implicitly maps 'screenplay or story text' to script_text and adds nothing on collection_id, output_language, or the mutual exclusivity of the two target_episode_* parameters. Baseline 3 is appropriate.

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 ('Create a Wandura Story mode project from a screenplay or story text') plus the immediate side effect ('start the script breakdown'), and names the concrete artifacts produced (characters, places, props, episodes, scenes). The 'Story mode' qualifier cleanly separates it from cinematic_ads_create_project among the siblings.

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?

Gives an explicit next step ('The breakdown takes a few minutes; then call story_get_project') and lays out the whole Story-mode pipeline (create → wait → asset pictures → storyboards → scene videos → takes). It also flags the paid path ('story_quote → the person approves in Wandura → story_run'), so an agent knows what to call and in what order after this one.

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