Extract motion templates from storyboards to standardize movement language across the whole drama. Requires existing storyboards—generate them first to ensure consistent action phrasing throughout the production.
从分镜自动抽取动作模板(统一全片运动语言)。需先有分镜(先 generate_storyboards)。文本步后付不欠费。
| Name | Required | Description | Default |
|---|---|---|---|
| drama_id | Yes |
Changes observed during successful MCP inspections.
v0.1.57Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses a dependency and mentions a billing/payment condition ('text step post-pay'), which adds useful context. However, the billing phrase is cryptic, and it does not describe side effects, output, blocking behavior, or what happens if storyboards are missing.
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 compact and front-loaded with the core purpose. The prerequisite is clearly separated in the second sentence. The only structural flaw is the unclear '文本步后付不欠费' phrase, which is concise but confusing.
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?
For a one-parameter generation tool, this is minimally adequate: it gives a clear purpose, the key upstream dependency, and a billing note. However, with no output schema it does not say what result to expect, and it does not point to get_motion_templates for later retrieval.
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 0%, and the description mentions no parameter names or value semantics. It only indirectly hints that the drama_id should correspond to a drama that already has storyboards. That is a weak constraint but not a complete compensation for the missing parameter documentation.
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 identifies the action: automatically extract motion templates from storyboards, with the stated purpose of unifying the film's motion language. It does not explicitly contrast itself with the sibling get_motion_templates, but the verb 'generate/extract' makes the productive nature clear.
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 explicitly names the prerequisite ('storyboards must exist first') and even names the upstream tool to call first: generate_storyboards. It does not discuss when not to use this tool or mention alternatives like get_motion_templates, but the ordering guidance 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.