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 does so well: '免费(仅建条目)' discloses that this only creates a database entry, not images or videos, and the anchoring explanation warns about video drift/hallucination if the product library is not built. It does not mention idempotency, error handling, or what happens on duplicate names, which prevents a higher score.

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 and front-loaded: it leads with the must-do flag, immediately states the action, then gives the rationale, the recommended next tool, and the cost/side-effect in a few short clauses. Every sentence earns its place and there is no redundant filler.

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 4-parameter create operation with no output schema and no annotations, the description is quite complete: it explains why the tool exists, when it is required, what it creates, the consequence of omitting it, and the downstream follow-up tool. The main gap is that it never states what the tool returns (e.g., a product ID) or that drama_id must already exist, which an agent might need for later steps.

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 only 50%, but the description maps several parameters by mentioning '名称/卖点/图', which corresponds to name, description, and image_url. However, the required drama_id parameter is never explicitly explained beyond the vague '广告项目' framing, so the description only partially compensates for the missing schema 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 names the exact action and resource: '往商品库加一个商品' (add a product to the product library) and enumerates the payload fields: name, selling point, image. It also positions this as the ad-product-creation step ('广告项目必做', '是广告的主体'), which distinguishes it from related sibling tools like create_prop or generate_product_sheet.

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 clearly marks when this tool is required ('★广告项目必做') and explains the failure mode if skipped ('不建产品库镜头里的产品会漂移/瞎编'), so an agent can determine when to invoke it. It also chains the next step ('建完用 generate_product_sheet 出设定图'), but it does not explicitly list exclusions or alternatives such as 'use create_prop for props', so it stops short of a full when-not specification.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals the server-side format gate (errors → 400 with the list returned as-is), the warning tolerance matching save_script, the fact that old scripts are saved to previous_script, the fallback recovery via get_script(include_previous=1), and the billing/speed characteristics. This goes well beyond what a minimal mutation-tool description would offer.

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 sentence earns its place: the core purpose is front-loaded, then the hard gate, then usage/exclusion conditions, then sibling differentiation, then rollback behavior. Bold markers and star bullets create scannable structure with zero filler or repetition. This is dense, pragmatic documentation rather than padding.

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 the tool's complexity, the lack of annotations, and the absence of an output schema, the description covers prerequisites, routing, side effects, and recovery comprehensively. The only notable gap is that it never states what a successful response contains or how an agent should confirm adoption succeeded — this is a minor omission because the gate and rollback behavior are well documented.

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%: content has a meaningful schema description, but episode_id has none. The tool description compensates for content by clarifying that it must be a complete production-annotated script that has already passed check_script_format, and by explaining the warning/error semantics that affect acceptance. episode_id receives no added semantics in the description, but its meaning as an episode identifier is reasonably unambiguous from the parameter name alone.

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 opens with a specific and unique verb+resource pair: 'directly adopt the external AI's script produced per template as a shootable script' (出口 A). It explicitly distinguishes itself from edit_rewritten_script ('首次落稿' vs '改已有改写稿') and from the set_script+rewrite_script alternative (出口 B), so there is no ambiguity about what the tool does or how it differs from 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?

Usage guidance is extremely explicit: it states when to use ('客户要求一个字都别改我的稿、且外部 AI 已经产出含制作层标注的完整稿') and when NOT to use (story-layer-only scripts, for which 出口 B is recommended). It also names the exact sibling tool edit_rewritten_script and clarifies the division of labor, including the 400 condition that differentiates them. No inference is required.

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

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

With no annotations provided, the description carries the full burden, and it discloses key behaviors: the operation runs in the background asynchronously, completion is detected through get_pipeline_status, and the voiceStyle field is not automatically populated. It also notes payment timing. It does not mention idempotency or overwrite behavior, but the critical operational traits are covered.

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 front-loaded with the main purpose, followed by dependency, timing, and async behavior. Every clause contributes useful information, and there is no filler. The punctuation-heavy style reduces readability slightly but not enough to lower the score further.

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 asynchronous tool, the description provides enough to invoke it correctly: what it does, what must happen before generate_tts, and how to know when it is done via get_pipeline_status. It does not state the immediate return value or what happens if invoked multiple times, but those are minor given the clear polling instructions.

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 0%, but there is only one parameter, episode_id. The description clarifies that 'this episode' is the target, which adds meaning beyond the bare integer schema. It does not explain where to obtain episode_id or any formatting expectations, but the schema already provides the basic constraint.

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: assign voices to all characters in the current episode, with clear selection criteria (gender, personality, age, role, project language). It also distinguishes itself from the sibling generate_tts by explaining that this step is a prerequisite for TTS.

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 explicitly warns that voiceStyle is not auto-filled and that generate_tts will lack voices if assignment is skipped, which tells the agent when this tool is required. It also gives sequencing: poll get_pipeline_status until assign_voices=done, then call generate_tts. It does not explicitly compare against per-character voice assignment siblings, but the all-characters scope is clear.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It discloses the critical non-destructive default (no overwrite unless overwrite=true), asynchronous execution, and the billing timing. It doesn't mention how to retrieve status or result, but the described behaviors are the most important ones for safe invocation.

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?

A single compact sentence conveys the key facts: what the tool does, the destructive default, the recommended timing, async behavior, and payment point. Every clause adds useful information, and the most critical safety detail (no overwrite by default) is front-loaded.

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 two-parameter async tool with no output schema or annotations, the description is largely complete: episode scope, overwrite semantics, timing, and async behavior are all covered. It doesn't mention polling via get_autofill_status or what the immediate response contains, but the existence of that sibling and the async note make the invocation safe enough.

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%; overwrite is already documented in the schema, and the description reinforces its default behavior. episode_id has no schema description, but the phrase '全集分镜' clarifies that the tool operates on an entire episode's storyboards, which helps an agent infer episode_id's role. This adds some value but doesn't fully compensate for the bare parameter 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?

The description states a specific action: AI one-click completion of missing storyboard fields for an entire episode. It clearly distinguishes this from generation by emphasizing it only fills gaps rather than creating storyboards. The recommended tag and scope (全集分镜) make its purpose immediately recognizable relative to siblings like generate_storyboards.

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 clear context: do it before image generation to improve storyboard completeness. It also notes the async nature and payment timing. It doesn't explicitly name alternatives or state when not to use it, but the corrective 'fill gaps, don't overwrite' instruction implies the main use case.

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

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

With no annotations, the description carries the full burden and discloses: deterministic, no AI, free; replace archives and does not reattach generated assets; user-authored prompts are never overwritten; auto_complete writes only empty fields and charges tokens post-paid; frame_visual_contract is ignored; speech rate will raise overflow shots. This goes well beyond what the schema conveys.

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?

Long but highly structured with ★ milestones and explicit field references; every clause carries operational intent. The density is justified by the tool's complexity, though it is heavier than necessary for an initial scan.

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 tool with no output schema, nested payloads, and post-import side effects, it names the key receipt fields (base_prompts_built, speech_duration_raised, speech_duration_overflow, auto_complete.prompt_shots, started) and the required polling/review flow. It covers prerequisites, side effects, cost, and next steps.

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 only partial, but the description explains mode=merge/replace semantics, dedupe behavior, image_prompt/video_prompt preservation, auto_complete behavior, and the need for a validated payload from check_bulk_import. episode_id remains minimally documented but is self-evident.

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 operation — importing a structured JSON payload to create/update an episode's characters, scenes, and storyboards with defined deduplication keys (name / location+time / storyboard_number). This clearly distinguishes it from related tools like check_bulk_import and autofill_storyboards.

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 three-step workflow (get_bulk_import_spec → check_bulk_import errors cleared → this tool), mode guidance for merge vs replace with a consent requirement, and auto_complete instructions including when to pass false. Names downstream tools to use after import (get_autofill_status, review_storyboards).

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

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

Discloses the core behavior (frame-to-frame handoff across an episode) and the postpaid-by-usage billing model, both beyond the tool name. However, with no annotations, it does not say whether the operation mutates existing frame assignments, whether it is asynchronous, or what it returns, leaving the side-effect and safety profile unclear.

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 front-loads the mechanism and benefit, then appends the billing note. Every clause earns its place and there is no redundant repetition of the schema.

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 tool this is brief but serviceable; however, with no output schema and no annotations it omits the result/status format, asynchronous behavior, and prerequisites in the larger frame-generation pipeline. An agent cannot tell whether calling it returns a finished chain or submits a job.

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 schema only defines episode_id as a positive integer; the description adds the 'whole episode' scope, which maps directly to that parameter. It does not explain preconditions such as whether frames must already exist, but for a single self-explanatory parameter this is minimally adequate.

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 that the tool creates an episode-wide head/tail frame relay chain, with the explicit mechanism: each shot's first frame inherits the previous shot's last frame. This is specific enough to distinguish it from sibling frame-generation tools, though it is phrased as a noun phrase rather than a direct imperative.

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 a clear use case: use this when inter-shot continuity is desired, and notes it is smoother than independent per-shot frame output, which is the obvious alternative. It lacks explicit when-not-to-use conditions or a named sibling tool, so it stops short of a full routing directive.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool is free ('免费'), does not persist data ('不落库'), and can be run repeatedly ('可反复跑'). It also describes concrete behaviors: it uses the exact import schema, turns silent import behaviors into warnings, and enumerates what each error/warning category means, including side effects like mode=replace replacing all storyboards.

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-structured: a bolded summary sentence, a return-value overview, then clearly labeled error and warning sections using stars and line breaks. Every sentence carries substantive information, and the pacing is appropriate for a tool with many validation rules. It is lengthy but not padded.

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?

Although there is no output schema, the description enumerates the top-level return categories (errors/warnings/stats) and lists the stats fields. It also details the specific error and warning conditions, which is enough for an agent to invoke the tool and interpret results. It could specify the exact output JSON structure, but the description is already highly informative for the tool's complexity.

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 already covers the single payload parameter completely (100% coverage) with its anyOf type and description. The tool description does not add significant parameter-level detail beyond what the schema provides, so the 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?

The description states a specific verb and resource: it is a pre-import JSON self-check that validates with the same zod schema as the import endpoint and surfaces silent behaviors as warnings. It clearly distinguishes itself from siblings by positioning itself as the go/no-go gate before bulk_import_storyboards, while tools like get_bulk_import_spec and check_storyboard_table serve different purposes.

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 clearly tells the agent when to use this tool: before running bulk_import_storyboards, to validate JSON and reveal issues that would cause import to fail or behave unexpectedly. It ends with an explicit conditional ('if this is green, bulk_import_storyboards can pass in one go'). It does not explicitly state exclusions or name alternative tools for other cases, but the usage context is unambiguous.

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

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

With no annotations, the description carries full behavioral disclosure, and it is richly transparent: it states it is free, pure rules, no model, no persistence, and repeatable. It discloses subtle behaviors beyond a simple 'check' — placeholder_left counts as an error because placeholders would be treated as image content, scene length counts only story-layer words excluding annotation lines, and strictOnly warnings become rejections in strict mode.

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 adds distinct behavioral value: error/warning categorization, placeholder explanation, scene-length counting rule, usage workflow, and limitation. It is front-loaded with the core purpose, uses bold and bullets to structure dense information, and avoids redundant phrases, though it could be slightly tightened.

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 there is no output schema, the description compensates well by explaining that issues are returned as a message list and how to use it (pass it back verbatim). It covers the main edge cases and constraints an agent needs to invoke the tool correctly, though the exact response structure is not specified and the strict-mode behavior is only partially detailed.

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% and the single content parameter is already documented in the schema ('要检查的剧本正文(一次一集,上限 3 万字)'). The description confirms the parameter's role but adds no new semantics about format, limits, or accepted encoding beyond what the schema already provides, so a 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?

The description opens with '回填前的格式自查' and states it runs script text through platform criteria and returns issues item by item, which is a specific verb+resource. It also explicitly delimits its scope against rewrite_script, saying '它只查格式', and lists exact error/warning categories, making it distinguishable from sibling tools like review_script and get_script_format_spec.

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: external AI finishes → run this tool → send the returned message list back → re-check → set_script, and clarifies this tool checks only format while fidelity judgments are left to rewrite_script. It also states when it is NOT appropriate (fidelity checks requiring original-side input), which is clear exclusion guidance.

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

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

With no annotations, the description carries full burden, and it delivers: it states the tool is free, pure rules, no model, no persistence, and repeatable, which signals a safe, idempotent read-like operation. It also explains what errors (400-causing) and warnings (degraded imports) mean at the behavioral level, going well beyond the schema.

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 it is densely informative and well-structured with bold labels and bullet-like markers. It front-loads the core purpose, then uses each section to explain error/warning behavior and actionable next steps, so the length earns its place even if a slightly tighter version would be possible.

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?

Since there is no output schema, the description compensates by listing the returned top-level categories and detailing what the shots preview contains (seconds, shot size, camera move, markers, text word count). It also tells the agent exactly what to do with errors and warnings, making the tool's operation and consequences clear enough for correct invocation.

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% and the single parameter 'content' is already described with minLength and a 60k-character cap. The tool description adds no additional information about the parameter itself, so the baseline score of 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?

Description states a specific verb ('自检') and resource ('分镜表'), and immediately distinguishes itself from the import endpoint by noting it runs the same parser without importing. It also enumerates the return categories (errors/warnings/stats/shots), making the tool's role unmistakable.

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 opening phrase '导入前的分镜表自检' establishes the exact trigger: run before importing. The final line explicitly names import_storyboard_table and states that if this check is green, import will not have issues, which provides a clear decision rule and differentiates from the sibling import tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals the automatic transcription behavior, authorization/legal requirements, sample quality constraints, billing implications (fixed price per voice), and downstream usage dependencies. This is far beyond what the schema alone provides and gives the agent a complete picture of side effects and prerequisites.

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 moderately long but every sentence earns its place. It front-loads the core action and return value, then layers in prerequisites, constraints, pricing, and downstream usage. The use of bold and a warning marker improves scannability without adding 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?

For a 4-parameter tool with no annotations and no output schema, this description is complete. It covers what the tool does, what input is acceptable, what processing will happen, what it costs, what it returns, and how to use it with related tools afterward. No critical operational detail seems missing.

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 100%, so the schema already documents name, notes, sample_url, and sample_file_path, including the 'one of' relationship. The description adds useful context about sample content and authorization, but it does not add much parameter-specific semantics beyond the schema. A baseline of 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?

The description states a specific action ('clone a voice from an authorized audio sample'), the returned resource ('voice_id'), and explicitly notes that no prior character or drama is needed. It also distinguishes itself from related tools by naming speak_with_voice and set_character_voice as the next downstream steps. This makes the tool's purpose clear and separable from its 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?

The description gives explicit when-to-use context: it can be used without an existing character or drama, after cloning you can use speak_with_voice for auditioning/downloading, and set_character_voice is only needed when dubbing to film. It also gives sample requirements and cautions (authorization, ~10 seconds clear voice, no music/silence). This fully routes the agent through the intended workflow.

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

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

No annotations exist, so the description carries the full burden. It discloses that the tool modifies the ending mirror's action/description, that it is background/async, and that it can be a no-op if prerequisites are missing. This is strong behavioral disclosure for a mutation tool, though it does not mention reversibility or output/status.

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 very compact and front-loads the most important classification (optional, conditional, enhancement) before specifying behavior. Every clause adds essential information: prerequisite, effect, timing, async behavior. The dense use of ★ markers makes it a bit cryptic but still highly efficient.

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 mutation tool with no annotations and no output schema, it covers the key context: what it changes, when it must be called, and what happens without motifs. However, it does not clarify success/return values or how the async result is tracked, and the episode_id parameter is left entirely undocumented in prose.

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 0%, so the description must compensate for the parameter's meaning. The description never mentions episode_id or explains that the episode must be the one whose ending motifs should be completed. The parameter name is somewhat self-explanatory, but the description adds no direct value to it.

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 a specific action (补全缺失的视觉母题/嫁接视觉回响到结尾镜) on a specific resource (结尾段/结尾镜). It distinguishes itself by being marked as optional, conditional, and enhancement-specific, which separates it from general generation tools. Minor jargon ('视觉母题', '结尾镜') slightly reduces clarity.

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 explicit conditions for when to use it: only if the drama already has motifs set, otherwise it is a no-op. It also gives timing guidance (before rendering, after text step, background async). It does not name alternative tools or explicitly say when not to use it beyond the no-motif no-op condition.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the operation is async, free, hard-blocks with 400 on missing/in-progress videos, skips missing shots when force=true, leaves a trace, and returns non-blocking advisories. This is far beyond what a minimal description would provide.

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 every sentence earns its place: purpose, cost, async nature, preflight behavior, force behavior, advisory handling, and polling. It is front-loaded with the core purpose and uses formatting to separate blocking from non-blocking concerns.

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 tool with no output schema and no annotations, the description covers all operational essentials: what the tool does, its failure modes, the force flag, advisory semantics, and the polling tool to call afterward. An agent has enough context to invoke it correctly and interpret the response flow.

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%: force has a schema description, episode_id does not. The description compensates by making clear that the episode is the target of composition and by explaining the practical effect of force (skip missing shots, produce partial cut, leave a trace). It adds meaning beyond the bare schema, though episode_id semantics could be spelled out more directly.

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 verb and resource: composing all shot videos of an episode into a final cut. It clearly distinguishes this from related tools like trim_shot, split_shot, and get_final_cut by framing it as the terminal assembly step.

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 explains when to call it, what happens if preflight finds blockers, when to pass force=true to build a partial cut, and that advisories are non-blocking but should be resolved. It also directs the agent to poll get_final_cut after invocation, giving a clear follow-up path.

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

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

With no annotations, the description carries the full burden. It discloses that the tool creates a shell, auto-creates empty episodes, returns IDs, is free, and that minimal input leads to downstream inconsistency and rework. It doesn't mention idempotency or permissions, but the core side effects are transparent.

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?

Three compact sentences front-load the main action, then add a prioritized setup warning and the return-value summary. The structure is efficient and every sentence carries meaningful guidance, with only minor repetition of '免费'.

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 41-parameter tool with no output schema, the description adequately explains the creation flow, the important parameters to set, the risk of empty-shell creation, and what is returned. It doesn't enumerate defaults, but the schema already covers those.

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 98%, so the baseline is 3. The description adds value by grouping key parameters (project_type/setting_brief/ethnicity/aspect_ratio, and consistency anchors cinematography_prompt/art_bible/visual_lock) and explaining why they matter, which goes beyond the individual schema descriptions.

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 verb and resource: '新建一部短剧(剧壳)', and clarifies the unique behavior of automatically creating N empty episodes and returning drama_id and episode_id. This clearly distinguishes it from the many generate_* sibling tools.

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 clear invocation context by strongly recommending that foundational settings be set at creation time, listing the key fields, and warning that a title-only shell causes rework. It doesn't explicitly name alternative tools, but the 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.

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

With no annotations, the description carries the behavioral burden. It discloses non-obvious side effects: filling description automatically triggers setting-image generation, and billing is deferred ('后付'). It doesn't cover response format or error cases, but key behavioral context is present.

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?

Two short sentences, front-loaded with the core purpose, followed by the alternative and the side-effect note. No filler or repetition of schema details.

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 simple create operation with no output schema and no annotations, it adequately covers purpose, relationship to the sibling extract_assets tool, and cost/side-effect behavior. It omits return behavior and failure modes, but those are relatively low-risk for this kind of creation tool.

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 71%, so most parameter meanings come from the schema. The description adds value by explaining the behavioral consequence of the description parameter, but it does not elaborate on type, prompt, or physical_size_hint beyond what the schema already states.

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 uses a specific verb and resource: '往道具库加一个道具' (add a prop to the prop library). It also distinguishes this manual tool from the automatic extract_assets workflow, making its role 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 extract_assets as the automatic path and states this tool is for manual supplementary creation ('供手动补建'), giving an agent a clear when-to-use signal and an alternative.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and a use case, with no mention of side effects, irreversibility, permissions, or what happens to associated data. This is a significant gap for a destructive operation.

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 extremely concise—one sentence plus a parenthetical note—and front-loads the action. There is no wasted wording, and it is appropriately sized for a simple 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?

Given the lack of annotations and output schema, the description is insufficiently complete. It omits critical details such as deletion scope (hard vs soft), consequences for references, and post-deletion status/return value. For a destructive tool, this is a notable deficiency.

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 0%, and the only parameter (character_id) is not explained beyond its type. The description does not indicate how to obtain the ID or confirm it refers to a character, leaving the parameter semantics under-specified.

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 explicitly states 'delete a character' and gives a specific use case ('for mistaken creation/merging'), clearly distinguishing it from siblings like update_character or delete_scene. The verb+resource is specific and unambiguous.

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 provides context on when to use the tool ('use for mistaken creation/merging'), which implies when it is appropriate. However, it does not explicitly mention when not to use it or name alternatives, though the sibling set makes this fairly clear.

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

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

No annotations are present, so the description carries the full burden of disclosing side effects. It only says 'delete' and 'free', without mentioning irreversibility, impact on dependent data, permissions, or other behavioral consequences. The destructive nature is implied but not elaborated.

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 extremely concise and front-loaded, using only a few words to convey the core action. However, it is so minimal that it borders on under-specification, especially for a destructive operation.

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 delete operation with no annotations and no output schema, the description omits deletion scope, reversibility, cost implications beyond 'free,' and expected response. It is minimally viable but not complete enough for an autonomous agent to understand side effects.

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 0%, and the description does not explain prop_id, how to obtain it, or what it refers to beyond the schema's type and minimum. Although prop_id is self-suggestive, the description adds no semantic value beyond the 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?

The description states a specific action ('delete') and resource ('prop'), distinguishing it from sibling tools like create_prop, update_prop, and get_props. It is not a tautology and clearly identifies the operation.

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?

No guidance is provided about when to use this tool versus alternatives, what prerequisites exist, or what conditions make deletion appropriate. The verb implies the purpose, but no explicit usage context or exclusions are given.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states '删除一个场景' and '免费', revealing no side effects, irreversibility, permissions, or impact on related resources. For a destructive mutation tool, this is a critical omission.

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 extremely short and front-loaded with the core action. It is concise to a fault, but the dimension measures appropriate sizing not informativeness. The '免费' addition is questionable but does not bloat the entry significantly.

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?

The tool is simple with one parameter, but given no annotations, no output schema, and zero parameter documentation, the description leaves critical context missing. An agent cannot know whether deletion is permanent, whether it cascades to related assets, or what constitutes a valid scene_id. This is inadequate for a destructive operation.

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 0%, and the description adds no meaning beyond the schema. The only parameter, scene_id, is left undocumented; the agent receives no guidance on what it represents, how to find it, or any format expectations. The description does nothing to compensate for the schema's lack of detail.

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 verb and resource: '删除一个场景' (delete a scene), which is clear and unambiguous. It doesn't explicitly distinguish from sibling delete tools, but the resource 'scene' is distinct enough that an agent can infer this is the deletion action for scenes.

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?

No guidance is given on when to use this tool versus alternatives. There is no mention of alternatives like update_scene for modifying instead of deleting, nor any conditions or prerequisites for calling delete_scene. The only extra information is '免费' (free), which is irrelevant to usage selection.

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

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

No annotations are provided, so the description carries the disclosure burden. It discloses the operational scope (user's own cloned voice library), the protection of public voices, and that the operation is free. However, it does not explicitly state that deletion is permanent or describe downstream effects, such as impact on character voice assignments.

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 a single, front-loaded sentence that conveys action, scope, an exclusion, and cost information without redundancy. Every clause adds relevant information for correct tool invocation.

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 deletion tool with no output schema and no annotations, the description covers the essential context: what is deleted, whose voice library is affected, and what cannot be deleted. The lack of explicit return-format or error-handling details is a minor gap for such a simple destructive operation.

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 schema already documents voice_id with a format example ('lib:12'), achieving full coverage. The description adds semantic value by implying that the ID must reference one of the user's cloned voices rather than a platform public voice, which is not explicit in the 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?

The description uses the specific verb '删除' with an explicit resource: '我音色库里的一个克隆音色' (a cloned voice in my voice library). It also clarifies that platform public voices are not deletable, which distinguishes this from voice-generation and voice-listing 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?

The description clearly communicates when-not to use the tool: it cannot be applied to platform public voices, so the agent understands only user-owned cloned voices are valid targets. It does not explicitly name alternatives like list_voices or clone_voice, but the ownership boundary provides clear guidance.

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

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 over-delivers: it discloses that the tool performs full-text overwrite ('本工具是全文覆盖' so unchanged scenes must be preserved verbatim), that it is free/instant/deterministic ('免费、秒级、结果确定不抽卡'), that it rejects calls for episodes never run through rewrite_script (400), and that damage is recoverable via get_script(include_previous=1). These traits go far beyond what the bare schema conveys.

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 front-loaded — the first line delivers the core decision (use this, not rewrite_script) before any workflow detail, and the numbered three-step guide with ★ markers keeps it scannable. Nearly every sentence adds distinct operational value given the tool's full-overwrite semantics; only minor redundancy (免费 appears twice) and the dense wall-of-text prevent a perfect economy score.

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 tool with no annotations and no output schema, the description covers the essential invocation knowledge: what to send (the full script), how to prepare it (get_script → selective edits → full resubmission), the failure mode (400), and the recovery path (include_previous=1). The remaining gaps are minor — the return value is never described, and episode_id semantics are implied rather than directly documented.

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 only 50% (episode_id has no description), but the description more than compensates: the script parameter gains critical semantics — it must be the complete rewritten script because the tool overwrites the whole document, and untouched scenes must be copied back verbatim rather than sent as fragments. episode_id also gets meaningful context: it must reference an episode that has already passed through rewrite_script, which is the precondition for success.

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 opens by naming the tool's exact role: ★改稿的首选通道(修改 AI 改写后的可拍稿) — the primary editing channel for AI-rewritten scripts. It names a specific verb (edit/write script_content), a specific resource (the rewritten script), and explicitly contrasts itself with rewrite_script, so an agent can distinguish it from its closest sibling without opening any schema.

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 usage rule is explicit: '改写成功一次之后,所有修改都走这里,不要重跑 rewrite_script' — with the reasoning that rewrite_script restarts from the original and discards current fixes. It also states a hard exclusion (episodes that haven't run rewrite_script get a 400, so it's not a bypass channel for original scripts) and prescribes the exact 3-step workflow (get_script → edit only target scenes → resubmit full text).

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

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

With no annotations, the description fully carries the behavioral disclosure burden, and it does so thoroughly. It reveals that the tool mutates the shot in place, requires prior user confirmation, has model-specific cost/billing implications, may extend the environment per instruction with WAN models, and returns a 400 error for unsupported interval parameters on H3/WAN. This is unusually transparent.

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: main purpose first, then model options and constraints, then the mandatory quote confirmation flow. Every sentence adds actionable information, and the warning about H3/WAN interval unsupported is positioned effectively. It is appropriately sized for the complexity of the 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?

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the essential prerequisites, model selection, interval constraints, and the critical quote-before-edit process. It does not describe the return value or follow-up status behavior, and it lacks explicit routing against alternative shot-editing tools, but an agent can call it correctly with the information provided.

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 description adds meaningful semantics beyond the schema, especially for the model parameter, explaining tradeoffs like 'hailuo-3=MiniMax H3 强保真编辑约1/3成本' and 'wan3.0...强语义编辑约4折'. It also clarifies the behavior of start_sec/end_sec and the quote_id workflow. With schema coverage at 67%, the description compensates for most gaps, though storyboard_id and reference list limits remain underexplained.

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 opens with '确认后就地编辑某镜视频' and clearly states the core action: edit a shot video by instruction, optionally with reference assets or interval replacement using start_sec/end_sec. This identifies a specific verb and resource, but it does not explicitly distinguish itself from related sibling tools like trim_shot, split_shot, or regenerate_shot_video.

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 explicit workflow guidance: call the corresponding quote_* tool first, relay estimated_points to the user, obtain explicit consent, and only then call this tool with the returned quote_id. It also warns against passing start_sec/end_sec with H3/WAN models. However, it does not discuss when to use this tool instead of sibling alternatives like regenerate_shot_video or split_shot.

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

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

With no annotations provided, the description carries the full disclosure burden and meets it: it warns that prompts, including hand-tuned ones, will be rewritten; that it runs asynchronously; that it is paid for after the text step; and that doing it too late forces expensive regeneration. This is unusually explicit about side effects and cost.

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 tightly packed and front-loads the most important caveats (optional, side effects) before the effect and the timing warning. The use of parentheticals and ★ markers is a bit dense, but no sentence is wasted and the ordering supports decision-making.

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 single-parameter async mutation tool with no output schema or annotations, the description covers the essential operational context: effect, side effects, timing, optionality, async behavior, and payment. The main gap is the unexplained episode_id and the lack of any pointer to how async completion is observed, but the core calling decision is well covered.

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 lone required parameter episode_id is never explained. The phrase '全集 image_prompt' indirectly implies the target is an episode, but the description does not tell the agent that episode_id selects which episode's prompts will be enhanced, nor does it clarify expected input semantics beyond the integer type.

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 precise action ('AI batch enhance') and a clear resource ('the full set of image_prompt'), and adds critical scope qualifiers: optional, side-effectful, rewrites existing prompts, and must run before generate_frames. This makes it easy to tell apart from read-only prompt getters and later frame-generation steps.

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 explicit when/when-not guidance: only do it when a client explicitly requests it ('客户点名再做'), it is not required to complete an episode ('非跑通一部片的必需'), and it must be done before generate_frames because changing prompts after rendering stales images and wastes money. No alternative tool is named, but the decision to use or skip it is fully specified.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read-only/export nature, zero cost, non-involvement of the platform, and exposes three non-obvious failure modes about TTS audio, trim offsets, and time-base semantics. This goes well beyond what the schema or annotations could convey.

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?

Though long, every section earns its place: the core result is front-loaded, the workflow is numbered, pitfalls are grouped under a clear warning heading, and the alternative is stated last. The structure makes the density manageable.

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 tool with one parameter, no output schema, and no annotations, the description is remarkably complete. It not only explains what is returned but names key manifest fields, warns about offset and trim semantics, and routes the agent to the correct downstream tool and alternative.

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 schema has one self-explanatory parameter, episode_id, and the description references '本集' but never explicitly defines the parameter or its meaning beyond that. Since schema description coverage is 0%, the description does not fully compensate, though the single parameter is simple enough that this is a minor gap.

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 and resource: exporting a per-episode handoff manifest with download URLs for raw clips, dialogue, SFX, music, and subtitles. It clearly differentiates itself from compose_episode by emphasizing that the platform does not perform final assembly, so an agent can distinguish it from sibling tools without opening schemas.

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 provides an explicit recommended workflow, names the follow-up tool get_handoff_toolchain, and gives the exact condition for choosing the alternative compose_episode. This is unusually clear when-to-use and when-not-to-use guidance, leaving little to inference.

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

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

With no annotations present, the description carries the full disclosure burden and delivers strong behavioral detail: the operation is background-asynchronous and minute-level, do not treat 60 seconds as failure, a missing/failed review gate causes a 400, a stale review_token auto-invalidates after content edits, errors block by default, and acknowledge_review should only be set when the client is fully informed. This goes well beyond what the schema alone provides.

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 extremely long and contains large blocks unrelated to extract_assets, such as video-engine selection, resolution decisions, world-concept defaults, and external-rewrite workflows. While it is organized with sections and emphasis markers, most of the content is pipeline-level guidance rather than tool-specific usage, making it heavy and likely to dilute the agent's attention.

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?

The description thoroughly covers prerequisites, hard review gates, async behavior, and status polling via get_run_status. However, with no output schema, it never says what the tool returns or how to retrieve the extracted character/scene/prop data after completion (e.g., get_assets is not mentioned). An agent could invoke the tool correctly but still be unsure what result to look for.

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 67%, and the schema already describes review_token and acknowledge_review. The description reinforces those semantics with pipeline context (e.g., review_token must come from review_script; acknowledge_review only for informed client override), but it adds almost nothing about episode_id, and the additional explanation largely restates what the schema already says. This is adequate but not compensating beyond the 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?

The opening sentence states a specific action and resource: "从可拍稿提取角色/场景/道具" (extract characters/scenes/props from the shooting script) and explains why it matters ("下游一致性的地基"). This clearly differentiates the tool from asset-generation or review tools such as generate_character_sheets or review_script.

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 is unusually explicit about when to call this tool: it requires a prior rewrite_script output, requires review_script to have been run first, and mandates passing the review_token. It also places extract_assets precisely in the pipeline: set_script → rewrite_script → review_script → extract_assets → storyboards, and warns against building character/prop assets before storyboarding.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose one important side effect: the result is saved back to the project (并存回项目). However, it does not say whether an existing setting_brief is overwritten, what gets returned, or how the save is keyed, and the billing-like clause adds confusion rather than a clear behavioral guarantee.

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 core sentence is short and front-loaded, clearly stating the action first. The standalone clause 文本步后付不欠费 does not clearly earn its place and reads as confusing noise. The description is compact but would benefit from removing or clarifying that clause.

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 simple 2-parameter tool with no output schema, the description conveys the main action and side effect but omits the semantics of drama_id, the shape of the saved setting_brief, and overwrite/return behavior. Even for a low-complexity tool, these gaps make the description incomplete.

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 50%: raw_text is documented as 世界观原文, while drama_id has only its name and type. The description confirms that raw_text is the source text and implies drama_id selects the target project through 存回项目, but it never explicitly explains drama_id or the output format of the setting_brief. It adds some context but leaves a required parameter mostly implicit.

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 first sentence names a specific verb and resource: extract a concise setting_brief from world-view raw text and store it back into the project. This distinguishes it from sibling extraction tools such as extract_assets and extract_visual_lock. The appended phrase 文本步后付不欠费 is opaque, which prevents a perfect score.

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 no guidance on when to use this tool versus alternatives like extract_assets, extract_visual_lock, or generate_world_concept. There are no selection criteria, exclusions, or context cues beyond the main action, so an agent must infer usage from the tool name alone.

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

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

With no annotations, the description carries the full behavioral burden. It does reveal that the tool writes a visual_lock rather than merely returning data, but it omits side effects, persistence, permissions, and response format; the cryptic '付不欠费' clause is not enough to count as meaningful disclosure.

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 core instruction is compact and front-loaded, but the second clause '文本步后付不欠费' is cryptic and does not earn its place; it obscures the intended usage timing. The description is short but not cleanly structured.

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?

There is no output schema and no annotations, so the description should clarify what is returned/written, dependencies, and parameter resolution. It only names sources and purpose, omitting visual_lock structure, how characters are resolved, prerequisites, and return 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 coverage is only 50% because drama_id has no description. The description maps '世界观 Brief' to setting_brief but never explains how '角色' is supplied or how drama_id resolves the character context, leaving the agent to guess at the core input semantics.

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 verb ('抽取', extract), a resource ('世界观 Brief + 角色'), and the output artifact ('visual_lock') with its purpose (unifying image style/ethnicity). This is enough to distinguish it from siblings like extract_setting_brief, though the trailing billing phrase adds noise.

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?

There is no explicit when-to-use or when-not-to-use guidance, no alternative tools are named, and the '文本步后' timing hint is buried in an unclear billing note. An agent cannot reliably decide between this tool and related style/art-bible tools.

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

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

With no annotations, the description carries the full behavioral burden. It mentions that the tool reads characters and metadata and runs after the text step, but it does not disclose side effects, persistence, output format, or cost behavior. The phrase '付不欠费' is cryptic and does not meaningfully clarify billing.

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 a single compact sentence with a useful parenthetical breakdown and a front-loaded action-object pair. It is easy to scan, though the trailing '文本步后付不欠费' is somewhat opaque.

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 generation tool with no annotations and no output schema, the description leaves important gaps: what the output is, what state changes occur, what 'text step' precisely refers to, and how the billing note should be interpreted. It offers only a rough invocation context.

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 schema has one parameter, drama_id, with 0% description coverage, and the description does not mention this parameter at all. It only hints at consumed data ('读角色+元数据'), which indirectly relates to the drama context but does not compensate for the missing parameter explanation.

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 gives a clear action ('生成美术圣经') and specifies the content dimensions (色调/材质/气质) plus the data source (读角色+元数据). It is distinguishable from sibling generation tools, though the term 'art bible' itself is not explained.

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 provides a sequencing cue ('文本步后') indicating this tool should be used after the script/text step. However, it does not state when not to use it or name an alternative among the many sibling generation tools.

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

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

With no annotations to fall back on, the description carries full disclosure burden and succeeds: it reveals async background execution, postpaid billing, the returned segment count/estimated duration, stale-flag semantics (bgm_stale=true), and the fact that generated BGM does not automatically enter the existing final cut. No contradiction with annotations (none provided).

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 every sentence earns its place: scope, async/billing, return value/polling, finalization requirement, and the rerender pitfall. It is front-loaded with the core action and preserves the most important integration warning near the end 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?

For a one-parameter async tool with no output schema, it tells the agent what it returns, how to monitor progress, how to get the BGM into the final cut, what get_final_cut's bgm_stale means, and which sibling to avoid. The full relevant workflow is covered.

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 never formally defines episode_id. However, the tool name, the phrase '整集' (entire episode), and a single self-explanatory required property make the parameter's role reasonably inferable. The description compensates little beyond the schema, but the ambiguity risk is low.

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?

Description opens with a specific verb+resource: '给整集生成/更换 AI 配乐(按情绪弧线)'—generate or replace AI BGM for an entire episode by emotional arc. It is unmistakably distinct from audio siblings like generate_tts and generate_sfx, and from episode finalization tools like compose_episode.

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?

Explicitly tells when to use the tool (for episode-level BGM generation/replacement), how to follow up ('用 get_bgm_status 轮询生成进度'), and which workflow is required to apply results ('必须重新 compose_episode'). It also provides a clear exclusion: '别用 re-render(吃旧时间线,不含新配乐)'.

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

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

With no annotations, the description carries the disclosure burden and it does so well: it reveals 后台异步, the quote-confirmation prerequisite, and the warning 不要擅自确认. It does not cover permissions, failure modes, or return/polling response details, but the key operational behavior is disclosed.

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?

Every sentence earns its place: scope limitation, sibling alternatives, progress-checking, and the quote-confirmation workflow. The warning is separated and front-loaded after the purpose, making the critical usage constraint easy to spot.

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 2-parameter async tool with no output schema, the description covers purpose, alternatives, prerequisites, and progress monitoring. It omits details about immediate return value and failure/edge-case behavior, but these are not blocking given the async pipeline-status guidance.

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 only 50%: quote_id is explained in the schema and the description reinforces that it must be the quote_id returned after user consent. However, episode_id has no semantic explanation in either the schema or the description, so one of two parameters remains under-documented.

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 and resource: 批量出角色定妆图 and emphasizes ★仅定妆图, distinguishing it from generate_character_sheets and generate_portraits_and_sheets. It makes the tool's scope immediately identifiable without needing to inspect sibling schemas.

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 says to call quote_* first, relay estimated_points to the user, wait for explicit consent, then call with the returned quote_id. It also directs users to generate_character_sheets or generate_portraits_and_sheets when sheet assets are needed and to get_pipeline_status/get_storyboards for progress.

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

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

Since no annotations are provided, the description carries the full burden. It discloses important behavior: the output acts as a shot-consistency anchor, it is more complete than the portrait, the character must already have a 定妆图, and usage is billed after the fact. However, it does not detail side effects (e.g., whether an existing sheet is overwritten) or error behavior if the prerequisite is not met, so it is not a perfect 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?

The description is compact and every clause earns its place: the core function is front-loaded, the distinction from the batch sibling is immediate, the prerequisite is stated, and the billing note is included. No filler or repetition.

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?

The description covers purpose, alternatives, precondition, and cost, which is good for a simple tool. However, it leaves episode_id's role undocumented, does not describe what happens if the prerequisite is unmet, and offers no information about how the output is returned or retrieved. Given 2 parameters and 0% schema coverage, these omissions make it only partially 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 description coverage is 0%, so the description must compensate for the two undocumented parameters. It does not explain what character_id or episode_id mean or how they interact. character_id is somewhat inferable, but episode_id's purpose is entirely unclear, leaving a meaningful gap in the agent's ability to call 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 uses a specific verb and resource: '给单个角色出三视图设定图' (produce a three-view design image for a single character). It also differentiates itself from the sibling generate_character_sheets by explicitly stating the batch alternative and from the 定妆图 by noting it is more complete, so an agent can clearly identify when this tool applies.

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 explicit when-to-use guidance: use for a single character, and use generate_character_sheets for an entire episode's batch. It also names a clear prerequisite ('该角色已有定妆图') that must be met before calling, effectively ruling out invalid invocations.

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

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

With no annotations, the description carries full behavioral burden. It reveals batching behavior, no duplicate billing, pay-per-use, 2–4 minute pending window, ready vs rejected states, how to read sheet_fail_hint, retry policy, and when to run precheck. Exceptionally transparent for a generation tool.

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 information-dense: purpose, prerequisite, billing, and status handling each earn their place, and the main action is front-loaded. Slightly dense single paragraph, but justified given no annotations.

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?

Covers preconditions, monitoring, failure modes and recovery in detail, which is crucial because there is no output schema and no annotations. The only material omission is documentation of the episode_id parameter and the immediate call result/return value; otherwise it is 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?

The sole required parameter episode_id is never mentioned in the description, and schema coverage is 0%. With no description coverage, the tool should explain how episode_id relates to the 'whole-drama' scope; its absence leaves an agent to guess whether to use drama_id, episode_id, or project context. Schema type/required are the only clues.

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?

Clearly identifies batch generation of multi-view turnaround design sheets for all characters in the drama, and explicitly states it only generates for characters lacking sheets. This distinguishes it from sibling portrait/prop/sheet tools and states the resource and verb.

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 explicit prerequisite (character must have a definitive portrait), states it blocks and prompts if missing, instructs polling get_characters for sheet_status instead of re-clicking, and provides retry/conflict routing to run_precheck. This is explicit when-to-use and when-not-to-use guidance.

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

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

No annotations are present, so the description carries the full behavioral disclosure burden. It only reveals a prerequisite and an unclear payment phrase ('文本步后付不欠费'); it does not say whether the tool creates a stored resource, runs asynchronously, overwrites an existing color script, or returns anything. Side effects and follow-up behavior are largely opaque.

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 short and front-loaded: action, purpose, then prerequisite. However, the final clause '文本步后付不欠费' is awkward and ambiguous, so it does not clearly earn its place and weakens the otherwise compact structure.

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?

The core invocation is simple with only two params and no nested objects, but the lack of annotations and output schema raises the burden on the description. It omits what happens after generation—such as whether the result is stored, returned directly, or retrievable via get_color_scripts. For a generation tool, this is a material gap in operational context.

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 only 50%: episode_id has a description, but drama_id does not. The phrase '该剧/集已有剧本文本' ties both parameters to the prerequisite and conveys the drama/episode distinction, which is a small addition beyond the schema. It does not explain drama_id's meaning or the exact relationship between drama_id and episode_id beyond the schema's 'optional' hint.

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 concrete action (生成 = generate) and a specific resource (剧目色彩脚本 = drama color script), with a parenthetical clarifying the goal: unifying the whole film's color mood. The 'generate' verb contrasts naturally with the sibling get_color_scripts, so an agent can distinguish creation from retrieval. It does not explicitly name that sibling, but the action+resource pairing is unambiguous.

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 provides an explicit prerequisite: the drama/episode must already have a script text, which tells an agent when the call is valid. It also groups drama and episode via '该剧/集', hinting at the optional episode-level invocation. However, it does not mention get_color_scripts as the alternative for reading existing color scripts, nor does it state when not to generate.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add one useful behavioral trait: '按用量后付' ('billed by usage after the fact'), warning that invocation may incur cost. However, it does not disclose whether generation is synchronous, whether it creates or replaces an existing asset, what output the caller receives, or any permission requirements, so transparency is only partial.

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 short and front-loaded with the main purpose, but the second part '图片步,按用量后付' is grammatically awkward and likely contains a typo ('步' appears to be '按' or a mis-split phrase). The billing note could be clearer, so the text is concise but not cleanly structured.

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 tool with no annotations, no output schema, and only one parameter, the description gives the basic action and billing note but omits important operational context: expected return value or job ID, asynchronous behavior, cost magnitude, and when to prefer this over generate_drama_poster or generate_episode_poster. An agent would likely struggle to know what to do with the result or whether this is the correct tool.

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 0%, so the description must compensate for the single drama_id parameter. The phrase '整部剧' helps clarify that drama_id refers to a whole drama rather than an episode, which is useful given many sibling tools are episode-scoped. But it does not explain the parameter format, how to obtain the ID, or what value is expected, leaving the agent to infer most parameter semantics from the schema's integer/exclusiveMinimum constraints.

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 verb and resource: '给整部剧生成片头封面图' ('generate the opening cover image for the entire drama'). It is clear this is a generation action scoped to a whole drama, which helps separate it from episode-level tools. However, it does not explicitly distinguish itself from similar siblings like generate_drama_poster or generate_episode_poster, so it stops short of a 5.

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?

There is no guidance about when to use this tool versus alternatives. No exclusions, no references to sibling tools, and no context about whether this is the right choice for a drama cover versus a poster. The scope '整部剧' is implicit but no explicit selection criteria are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose two useful behavioral facts: the operation runs asynchronously in the background (后台异步) and billing is pay-per-use after the fact (按用量后付). However, it does not explain what happens after completion, how to retrieve results, or whether existing deliverables are overwritten.

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 extremely compact and front-loaded with the main purpose. Both clauses add distinct value: scope/action and async/billing behavior. It loses a point only because the brevity contributes to some ambiguity about exactly what 'all deliverables' includes.

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 async tool, the description names the input context (brand film), confirms async execution, and states billing. But without an output schema or annotation, it does not tell the agent how to track the async job or obtain the generated deliverables, which is a meaningful gap for an async operation.

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 schema has one self-descriptive parameter, drama_id, with 0% description coverage. The description adds the useful contextual hint that the drama should be a brand film, which gives the parameter meaning beyond the raw integer type. It still does not describe the parameter explicitly, but the single parameter is simple enough that the added context is adequate.

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 clear action: one-click generation of all deliverables, scoped to a brand film (品牌片). It does not enumerate which deliverables are included, and it does not explicitly contrast with siblings like get_deliverables, so it falls short of a 5, but it is clearly not a tautology.

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 implies this tool is used when the user wants all deliverables generated at once, and the brand-film scoping gives some context. However, there is no explicit when-to-use vs. alternatives guidance, no exclusions, and no mention of sibling tools.

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

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

With no annotations, the description carries the disclosure burden. It adds one useful behavioral trait—'按用量后付' (billed by usage)—but says nothing about async behavior, return values, side effects, or prerequisites. The cryptic '图片步' phrase further weakens transparency.

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 short and front-loaded with the main purpose, which is good. However, the second sentence is garbled ('图片步,按用量后付') and does not cleanly communicate its intended meaning, reducing overall clarity.

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?

This tool has no output schema and no annotations, so the description should explain return behavior and any necessary preconditions. It does not mention what the agent receives after generation, whether the call is asynchronous, or whether the drama must already exist. The simple single-parameter schema prevents a lower score, but the gaps are material.

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 does not explain drama_id beyond the term '整部剧'. It omits how to obtain a valid drama_id, whether existing dramas are required, or any constraints beyond the integer type already in the 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?

The description states a specific action ('生成海报图') with a clear resource ('KV poster') and scope ('整部剧'). This cleanly distinguishes it from sibling tools like generate_episode_poster and generate_cover.

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?

Usage is implied: the '整部剧' wording suggests it is for full-drama posters rather than episode or cover posters. However, it never explicitly names alternatives or states when to prefer this tool over generate_episode_poster or generate_cover.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses two important traits: execution is asynchronous in the background, and billing is usage-based and postpaid. These add significant value beyond the plain name and schema.

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?

Two short clauses convey purpose, scope, async behavior, and billing with no filler. Every word earns its place.

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?

The description covers scope, async execution, and billing, but does not tell the agent how to track completion or retrieve results after the asynchronous run. Since there is no output schema, this is a noticeable gap for a background task.

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 0%, so the description must compensate. It clarifies that episode_id refers to the entire episode, but it does not explain the expected state or prerequisites of the episode, nor any constraints beyond what the schema already states.

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 specifies a concrete action (automatically match) and a clear resource (visual effects for an entire episode). The use of '视觉特效' (visual effects) distinguishes it from the sibling tool generate_sfx (sound effects).

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 clearly indicates episode-level scope: use this tool when visual effects need to be automatically matched for a whole episode. It does not explicitly name alternative tools or state exclusion conditions, which prevents a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pay-per-use billing ('按用量后付'), which is useful, but it does not disclose whether generation is synchronous, what output is returned, whether it triggers follow-up jobs, or any side effects beyond the billing note.

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 short and front-loads the main purpose, which is good. However, the second fragment '图片步,按用量后付' is unclear and likely contains a typo, reducing the overall clarity and making the concise structure less effective.

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?

The tool has no output schema and no annotations, so the description should explain what the agent can expect after invocation. It does not mention return format, asynchronous behavior, or status checks. The billing note is helpful, but the overall description is incomplete for safe and correct invocation.

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 schema only provides episode_id as an integer greater than 0 with no description. The description's '某一集' clarifies that this ID refers to the target episode for the poster, adding meaning beyond the bare schema. However, it does not explain how to obtain the ID or what values are valid, and schema coverage is 0%.

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 a specific verb ('生成') and resource ('某一集' poster image), making the core function understandable. It also implicitly distinguishes this from sibling tools like generate_drama_poster by specifying episode-level scope. However, it does not explicitly contrast against similar poster/cover tools, leaving some ambiguity.

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?

There is no guidance on when to use this tool versus alternatives such as generate_drama_poster or generate_cover. The phrase '给某一集' implies an episode-specific use case, but no explicit context, prerequisites, or exclusion criteria are provided.

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

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

No annotations are provided, so the description carries the full burden, and it delivers: async background dispatch, frames_planned is a planned count not a success count, pending/ready/failed status semantics, slow generation, 402 failure mode, review_token invalidation, and skip-existing behavior. There is no annotation contradiction.

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 carries operational value, and it is front-loaded with the core async batch behavior before warnings and prerequisites. Bold text and bullets make the dense content scannable rather than a wall of text.

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?

Despite lacking an output schema, the description explains the key response field (frames_planned), how to determine real completion via get_storyboards/get_jobs, failure causes, required preceding steps, and sibling alternatives. Nothing essential for correctly invoking the tool is missing.

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 high, but the description adds critical semantics beyond the schema: frame_type must match the quote and controls which shots get filled, review_token is a mandatory credential from review_storyboards, and acknowledge_review is for informed override only. This materially reduces misuse risk for the trickiest parameters.

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: batch-generate frames asynchronously after confirmation. Clearly distinguishes itself from generate_shot_frame (single-frame regeneration) and upload_shot_frame, so sibling differentiation is explicit.

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 explicit when-to-use and when-not-to-use guidance: use for missing frames only, existing frames are skipped by design, and re-generating an existing frame requires generate_shot_frame. Also mandates the quote_* confirmation flow, the review_storyboards prerequisite, and polling via get_storyboards instead of retrying.

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

Does 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.

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

With no annotations, the description carries the full burden. It discloses the core behavior (writing scriptContent) and adds a billing note ('按用量后付'). Yet it doesn't state whether the operation overwrites existing content, whether lyrics and story must already exist, or whether the call is asynchronous – leaving notable gaps for a no-annotation tool.

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 two concise sentences with no filler. It front-loads the purpose, then adds pipeline context and a billing note, each sentence earning its place. The structure is dense and efficient.

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 tool, the description provides sufficient context: input source (lyrics+story), output (scriptContent), and follow-up steps (extract_assets → 分镜). It doesn't discuss return values or job status, but with no output schema that is not strictly required. A minor gap is the lack of explicit statement that drama_id must reference an existing MV project, though this is implied.

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 0%, and the description adds no meaning about the required drama_id parameter. The name alone suggests it identifies the drama/project, but the description never explains how to obtain it, what it represents, or any constraints beyond the schema's integer type. With low coverage, the description was expected to compensate but did not.

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 verb and resource: '据歌词+故事写首集可拍剧本(写 scriptContent)' – write a shootable first-episode script based on lyrics and story, specifically writing scriptContent. It also sets the tool's position before the standard pipeline ('之后走标准 extract_assets → 分镜 → …'), helping distinguish it from downstream tools and from siblings like generate_mv_story.

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 provides clear context for when to use the tool: for MV projects, when you have lyrics and a story, to produce a first-episode script. It also indicates the next steps to follow. However, it doesn't explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

With no annotations, the description carries the disclosure burden, and it does add useful behavioral context: the operation can run in the background or synchronously and is billed by usage. It does not disclose side effects, whether an existing story line is overwritten, retry behavior, or required prior state, so coverage is partial.

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?

Two concise clauses: the first states the core function, the second captures execution mode and billing. There is no filler, and the key information is front-loaded.

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, the description is minimally workable, but there is no output schema and no note about what the tool returns, how to retrieve results, or how this step fits after set_mv_lyrics and before generate_mv_script. These gaps reduce overall completeness.

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 0%, and the description does not explain drama_id at all. The parameter name and exclusiveMinimum constraint imply a drama/project identifier, but the description never clarifies that this ID carries the lyrics or project context needed to generate the story.

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 ('AI 编一个 MV 故事线') and a clear resource (an MV story line based on lyrics), so an agent knows what the tool produces. However, it does not differentiate this from sibling tools such as generate_mv_script or generate_scene_groups, which could plausibly overlap with 'story line'.

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?

There is no guidance on when to use this tool versus generate_mv_script, set_mv_lyrics, or other generation alternatives. The '后台/同步,按用量后付' note is operational rather than a selection criterion, and no prerequisites such as lyrics already being set are mentioned.

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

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

With no annotations, the description carries the full disclosure burden and covers two-stage execution, per-call advancement, dependency on portrait readiness, and pay-per-use billing. It stops short of describing failure or timeout behavior, which prevents 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?

The description is dense and front-loaded with the essential workflow, then adds readiness polling and billing details. Each clause contributes operational guidance, though the Chinese shorthand makes it less accessible than a structured English version.

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 multi-stage generation tool with no output schema, the description explains the workflow, dependency, readiness signal, and next steps well. The missing definition of episode_id and lack of error-handling guidance are the main gaps.

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 schema provides no description for the single required episode_id, and the description never mentions or explains this parameter. The workflow around characters implies an episode scope, but this is indirect and does not compensate for the 0% 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 clearly states the tool's combined deliverable: final-look images plus setting sheets, and labels it as the recommended production-line standard. This combined scope distinguishes it from the separate portrait-only and sheet-only sibling tools.

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 sequencing logic: if characters lack final-look images, call once to generate them, then call again after they are ready to batch-produce setting sheets. It also names get_characters as the readiness check, but it does not explicitly say when to prefer the dedicated single-purpose siblings.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the tool performs AI generation and mentions billing behavior (pay per usage, no arrears), which is useful. It does not disclose whether an existing product image is overwritten, whether the operation is synchronous, or what the output is, but the core generation behavior is visible.

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-loads the main purpose and resource. The billing note and downstream-consequence note add relevant context, though the phrasing is slightly run-on and the emoji/asterisk adds noise without blocking understanding.

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 tool with no output schema and no annotations, the description covers the core purpose and one important consequence, but omits return behavior (e.g., image URL, job status) and whether existing sheets are replaced. These gaps prevent full autonomy for an agent choosing and invoking the tool.

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%, so the description must compensate. It refers to 'a product in the product library,' providing context that product_id refers to an existing product ID. It does not explain how to obtain the ID or what values are valid beyond being a positive integer, but the single simple parameter leaves little ambiguity.

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 — AI generates a setting image (设定图) for a product in the product library — with a clear resource. It distinguishes itself from related sheet tools by emphasizing 'product' rather than character or prop, though it does not name those siblings explicitly.

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 implies when to use the tool by explaining the downstream failure if a product has no setting image: video generation will fail to find an anchor and product drift occurs. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions, leaving usage guidance to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It fails to mention whether generation is asynchronous, whether it mutates data, what inputs are required beyond prop_id, or any side effects. The payment phrase '按用量后付不欠费' is unrelated to tool behavior and confusing.

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 short but includes an unclear fragment '图片步' and an irrelevant billing note, which wastes the little space available. It is under-specified rather than effectively concise.

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 one parameter, no annotations, no output schema, and no behavioral details, the description is severely inadequate. An agent cannot reliably determine how to call this tool, what it returns, or how it differs from similar prop-related tools.

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 0% and the description provides no explanation of prop_id or how it relates to the generated image. The sole parameter is left entirely undocumented in human-readable terms.

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 phrase '给道具 AI 出设定图' indicates the tool generates a setting/concept image for props, which is a specific verb+resource action and loosely distinguishable from siblings like generate_character_sheet and upload_prop_sheet. However, the wording is terse and the meaning of '道具 AI' is ambiguous, so it is not fully 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?

No guidance is given on when to use this tool versus alternatives such as upload_prop_sheet, generate_product_sheet, or get_props. The description does not mention any distinguishing use case or selection criteria, leaving the agent without direction.

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

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

The description discloses a key behavioral trait: the operation is asynchronous ('后台异步'), which is important for an agent to know it cannot expect an immediate result. However, with no annotations at all, the description carries the full burden; it does not explain how to monitor completion, whether it overwrites existing groups, or what the output looks like. It adds some transparency but leaves notable gaps.

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 appropriately short, with two focused pieces of information: what the tool does (including a clarifying parenthetical) and the async nature. Every word earns its place, and the key action is front-loaded. No fluff or 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?

For a tool with one parameter, no annotations, and no output schema, the description is incomplete. It fails to explain the required input (episode_id), what the invocation returns or how to poll for async completion, and whether there are dependencies on existing scene data. These gaps prevent an agent from confidently calling the tool and interpreting the result.

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 schema provides only the parameter name 'episode_id' with no description, and schema_description_coverage is 0%. The tool description does not mention episode_id at all, leaving the agent to infer its meaning from the name alone. This does not compensate for the lack of schema descriptions, so the description adds no semantic value beyond the structured 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?

The description clearly states a specific verb and resource: 'generate scene groups' and explains the core behavior ('group consecutive shots'). The parenthetical about being the foundation for continuous long takes/batch image generation provides useful context, but it does not explicitly name sibling alternatives (e.g., get_scene_group_plan), so differentiation is conveyed by context rather than direct contrast.

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 implies when to use this tool: as a prerequisite ('地基' / foundation) for continuous long takes and batch image generation. However, it does not state when not to use it, mention alternatives, or provide explicit preconditions. The usage context is inferable but not clearly spelled out.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses that execution is background/asynchronous, that it must be preceded by an approved quote, and that the agent must not unilaterally confirm. It does not describe return values or job-status tracking, but the key behavioral traits are honestly and prominently stated.

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 main purpose and async behavior are front-loaded in the first clause, and the critical workflow warning follows without padding. Every sentence earns its place, and the warning is compressed but complete.

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 covers purpose, async behavior, and the mandatory quote-confirmation flow well. It falls short by not stating what the async call returns or how to track completion (e.g., a job id or status tool), and the phrase '对应的 quote_* 工具' is slightly ambiguous among the many quote_* siblings, though quote_id's schema description narrows it.

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%: quote_id is described in the schema and additionally explained in the description as coming from the quote tool and requiring user approval. However, drama_id is left only with a type and minimum constraint, and the description adds no meaning for it. Partial compensation for the coverage gap.

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: after confirmation, batch-generate scene images, and notes it is asynchronous. It clearly separates this execution tool from the quoting step by requiring a quote_id from a quote_* tool, so an agent can distinguish generate_scene_images from quote_scene_images and upload_scene_image.

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: first call the corresponding quote_* tool, relay estimated_points verbatim, wait for explicit user consent, then call this tool with the returned quote_id. It also warns 'don't confirm on your own', which is a clear exclusionary rule against invoking without approval.

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

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

With no annotations, the description carries the transparency burden and does add real value: it states the operation runs in the background asynchronously and is billed post-paid by usage. It does not mention how to check job status or what happens on failure, but the disclosed async and cost behavior is beyond the schema.

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?

Two short sentences, zero filler, with the action and scope in the first sentence and lifecycle/cost behavior in the second. Extraordinarily lean while still being informative.

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 an async operation with no output schema, the description tells the agent it is background and paid, but it does not specify the return value/job ID or how to monitor completion. Since this is a single-parameter trigger, a status-check pointer would make it 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 description coverage is 0%, yet there is only one parameter, episode_id, whose meaning is partially conveyed by '整集' (whole episode). The description does not explain constraints or effects of the parameter beyond that, but the self-evident name plus episode scoping make the gap modest.

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 names a specific operation ('automatically match + generate SFX') and scopes it to an entire episode, which clearly distinguishes it from siblings like generate_tts, generate_bgm, and generate_effects. It doesn't explicitly call out sibling differentiation, but the SFX+episode scope is unambiguous.

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 establishes the context (whole-episode SFX matching/generation) so an agent can infer when to pick it, but it does not state explicit exclusions or name alternatives, and it omits prerequisites or when not to use it.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses that regeneration overwrites existing frame images, marks the shot video as pending regeneration, preserves the unaffected side when reopen_pair_id is used, does not re-bill for preserved candidates, and explains completion via polling get_storyboards. It also warns against unauthorised confirmation, making side effects and process risks clear.

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: the core action and side effects come first, followed by the reopen_pair_id inheritance flow, then the mandatory quote confirmation warning. Every sentence carries operational meaning; the length is justified by the tool's complexity and the need to prevent incorrect retry or billing behavior.

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 tool with no output schema and a complex asynchronous workflow, the description is remarkably complete. It covers prerequisites, side effects, overwrite behavior, billing implications, the exact polling completion condition, and the required quote confirmation ritual. An agent has enough context to call the tool correctly in both the normal and reopen_paths.

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 83%, so the baseline is already decent. The description adds real semantic value beyond the schema by explaining how reopen_pair_id interacts with frame_type, how quote_id must be obtained and matched, and the default behavior for image_model. The only notable gap is storyboard_id, which has no schema description and is not explicitly explained in the description, though its meaning is inferable from the tool's context.

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 opens with a specific verb and resource: generating or regenerating a frame for a single shot, and says it is asynchronous. It distinguishes itself from the external 'generate + upload' path, explicitly positioning this tool as the correct way to fix a shot's frame, which differentiates it from sibling upload tools like upload_shot_frame.

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 explicit when-to-use guidance: use this instead of external tools because they break consistency; use reopen_pair_id only when get_storyboards returns that field, otherwise use normal frame_type retry. It also gives a concrete prerequisite for tail frames and mandates the quote-before-call flow, so an agent knows exactly when and how to invoke it.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is destructive (replaces the whole episode's storyboards, loses already-generated images, costs money), asynchronous (returns immediately with status:generating), slow (5–10 minutes typical), and gated by a review token. It also discloses token invalidation, default error blocking, and the customer-decision rule for acknowledge_review.

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 well-organized with ★ markers, bolded warnings, and critical information front-loaded. Each block has a clear purpose, though the repeated waiting-time warnings ('分钟级', '5~10 分钟', '单次 LLM 调用 3~7 分钟', '60 秒…3 分钟内查不到分镜都是正常的') are somewhat redundant and could be condensed without losing the anti-resubmission message.

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 destructive, asynchronous tool with no output schema and no annotations, this definition is unusually complete: it covers async return, polling, progress checking, replacement behavior, review gating, and quote confirmation. It falls short only by not explicitly explaining where a run identifier comes from for get_run_status and by leaving episode_id semantics implicit.

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 high (80%) and the schema already documents most parameters. The description adds extra meaning for review_token (token invalidates if content changed; can re-review for free) and acknowledge_review (don't decide for the customer), and clarifies that quote_id comes from a quote_* tool after user approval. However, episode_id has no schema description and the tool description only implies its role via '整集'.

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 quickly identifies the action ('确认后拆镜' / storyboard generation), the target resource (整集分镜), and the asynchronous execution model ('后台跑,立即返回 status:generating'). It also differentiates itself from sibling tools by telling the agent to poll with get_storyboards and check run progress with get_run_status.

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 explicit required prerequisites and exclusions: do not call before review_script (or you get 400), do not confirm without an approved quote_id, use confirm_replace=true only when knowingly replacing existing storyboards, and do not resubmit while a run is active. It names the relevant sibling tools (review_script, quote_*, get_storyboards, get_run_status) and explains which one to use when.

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

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

The description explicitly discloses that the operation is asynchronous ('后台异步'), which is valuable behavioral context. However, with no annotations provided, the description carries a heavier burden; it does not mention side effects, how to monitor completion, or whether existing transitions are overwritten. It adds one key behavior but leaves others undisclosed.

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 extremely concise: one short sentence with no filler. It front-loads the core purpose and includes only essential extra information about asynchronous execution. Every word earns its place.

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 an asynchronous mutation tool with no annotations and no output schema, the description is incomplete. It does not say what response the agent should expect, whether a job ID is returned, or how to check the status of the background operation. The agent would struggle to invoke and monitor this tool correctly with only this description.

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 schema provides only the parameter name and type for episode_id, with 0% description coverage. The description partially compensates by clarifying the operation applies to an entire episode, but it does not explain how to obtain the ID, what format is expected, or how the ID maps to a specific episode beyond the name. It adds some meaning but not enough to fully cover the schema gap.

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 ('自动加转场', automatically add transitions), the target resource ('整集', the whole episode), and concrete examples ('闪白/玻璃碎裂等'). It clearly distinguishes itself from sibling tools like generate_sfx or generate_effects by naming the transition-specific operation.

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 implies the use case: add transitions to a completed episode. However, it gives no explicit when-to-use or when-not-to-use guidance, and does not name alternatives that might be more appropriate in other circumstances. Usage context is present but not fully developed.

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

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

There are no annotations, so the description carries the full burden. It discloses that the operation runs in the background ('后台异步'), that billing is usage-based, and that there is a hard prerequisite on voice assignment. It does not mention how to check completion status or whether re-running overwrites existing TTS, which prevents 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?

The description is compact: four short clauses each carry a distinct fact — scope, pipeline timing, prerequisite, and async/billing behavior. The main purpose is front-loaded. The phrase '按用量后付不欠费' is slightly awkward and less essential than the other details, so it is concise but not perfectly smooth.

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 async tool with no output schema and no annotations, the description covers the key preconditions and async behavior well. However, it omits how the agent will know when the background job finishes or whether it returns a job identifier for status polling. This is a meaningful gap for an asynchronous pipeline step.

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%, so the description must compensate. It indirectly clarifies episode_id by saying '整集' (whole episode), indicating that the parameter targets the episode whose dialogue should be dubbed. It does not explain how to obtain the episode_id or verify that the episode is ready for TTS, but the single simple integer parameter is reasonably contextualized.

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 opens with a specific verb-object pair: '给整集所有对白批量配音(TTS)' — batch-dub all dialogue for a whole episode. This clearly distinguishes it from single-line TTS tools like speak_with_voice and from voice-assignment tools like assign_voices, and it further positions the tool in the pipeline as the audio step before final cut.

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 states when to use the tool: before final delivery, after assign_voices has been run. The prerequisite '前置:先 assign_voices 给角色分配音色' is concrete and actionable. However, it does not explicitly contrast with alternatives such as speak_with_voice or explain when not to use batch dubbing, so it falls just short of a 5.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses auto-abort on insufficient balance, rejection when no first frame exists, review-token invalidation after content changes, default error blocking, and potential wasted charges/defective output if acknowledge_review:true is used carelessly.

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 appropriately dense for a multi-gated tool, with clear ordering: main action, prerequisites, review gate, and quote confirmation. Each sentence carries distinct operational value, and visual markers (★, ⚠️) help the agent prioritize critical constraints.

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?

Despite no output schema and no annotations, the description covers preconditions, rejection causes, failure behavior, the review workflow, token lifecycle, quote flow, and post-invocation polling. An agent has enough context to invoke the tool correctly and route the user through the required confirmation steps.

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?

Beyond the schema's 75% parameter coverage, the description adds operational meaning: quote_id must come from an approved quote with estimated_points relayed to the user, review_token is tied to review_frames findings and can expire after content edits, and acknowledge_review should only be true when the customer explicitly insists despite errors. This goes well beyond the bare schema descriptions.

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's action: '确认后批量出视频' and '一条后台链跑完整集', defining it as batch full-episode video generation after confirmation. It distinguishes itself from single-shot generation tools through explicit batch/full-episode wording and the polling instruction via get_storyboards.

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 when-to-use guidance: must call review_frames first, must call a quote_* tool first and obtain explicit user consent, and must use the returned quote_id. It also tells the agent what to do next ('用 get_storyboards 轮询 video_url') and warns against self-confirming quotes or overriding review errors on the user's behalf.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions reading three inputs and 'generating' a lock prompt, but does not disclose whether this mutates state, what the returned prompt structure looks like, whether it consumes credits, or whether it is a safe read-only operation. The cryptic phrase '文本步后付不欠费' is ambiguous and does not meaningfully clarify 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 main action is front-loaded and compact, but the trailing phrase '文本步后付不欠费' is unclear and appears to confuse rather than inform. The parenthetical listing of inputs is useful, but overall the sentence carries some ambiguity that a cleaner structure could avoid.

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 and no annotations, the agent is left without information about what the tool returns, whether it is safe to call, and how it sequences with surrounding pipeline steps. The description provides the input context but is incomplete for correct invocation beyond the drama_id parameter.

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 0%, and the description does not mention drama_id at all. The only parameter is simple and inferable from its name, but the description adds no guidance on how to obtain or validate it, so the agent must rely entirely on the schema's minimal type information.

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 verb ('生成' / generate), a specific resource ('视频风格锁 prompt' / video style lock prompt), and the intended effect ('统一视频生成方向' / unify video generation direction). This clearly distinguishes it from sibling generation tools like generate_videos or generate_mv_story.

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 clear usage context: it reads brief/artBible/visualLock and is meant to lock the video generation direction. It does not explicitly exclude alternatives or name sibling tools, but the purpose is clear enough that an agent can infer when this step is appropriate in the pipeline.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses that this is a mandatory, often-forgotten pipeline step, that it must not run silently because it consumes points, and that it requires client confirmation. It also notes fixed after-the-fact payment and a prerequisite on setting_brief length, adding meaningful behavioral context beyond the verb 'generate.'

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 key information is front-loaded: mandatory default, deliverable format, then billing and prerequisite warnings. It is compact and dense with no filler, though the heavy use of parentheticals and Chinese punctuation makes it slightly less readable than a structured description 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?

For a one-parameter tool with no annotations and no output schema, the description covers the essential calling context: when to run it, prerequisites, deliverable shape, and client-confirmation/billing rules. It does not explain what the response returns or what to do if setting_brief is below 30 characters, but it is sufficient for correct invocation in the main flow.

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 schema has only one parameter, drama_id, with 0% schema description coverage, so the description needs to compensate. It indirectly references the target drama by requiring its setting_brief to be ≥30 characters, but it never explicitly explains that drama_id identifies the drama whose setting brief is checked. This gives partial guidance but leaves the parameter mapping implicit.

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 uses a specific verb and resource: it generates a world-concept image in a fixed four-cell layout (panorama/era/main scene/color), with the purpose of improving visual consistency. It clearly distinguishes this from sibling generation tools by naming the exact deliverable structure.

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 explicit trigger conditions: it is the default step after storyboards, should not be skipped, and requires setting_brief ≥30 characters. It also states the billing workflow (notify client of estimated points, get confirmation before running, no silent charges). It does not name alternative tools for when-not-to-use, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only operation ('读') and mentions '免费' (free), but does not explain what aggregation means, whether results are paginated, how images are represented, or any side effects or prerequisites. The safety profile is only partially conveyed.

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 core sentence is concise and front-loaded with the main purpose. However, the trailing sentence '免费。' is irrelevant fluff that does not earn its place, diluting the focus of an otherwise tight definition.

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 simple one-parameter tool without an output schema or annotations, the description should at least hint at the response format or aggregation structure. It lists asset categories but omits what the aggregated result looks like, whether it is grouped, and how images are returned. An agent would still have significant ambiguity after reading it.

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 0%, and the description makes no mention of the drama_id parameter or how to obtain/use it. The parameter name is self-explanatory and the schema encodes its type and constraint, but the description adds no value beyond the schema, failing to compensate for the coverage gap.

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 verb (读/read), a resource (全部资产聚合 of a drama), and enumerates the asset types covered (characters/scenes/props/images). This clearly distinguishes it from per-type getters like get_characters, get_scenes, and get_props, though the term '聚合' (aggregation) could be more explicit about what shape the data takes.

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?

No guidance is provided on when to use this tool versus alternatives such as get_characters, get_scenes, get_props, or extract_assets. The description simply says it reads all aggregated assets and is 'free', without stating any selection criteria, exclusions, or related workflows.

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

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

With no annotations provided, the description carries the full burden, and it excels: it discloses the operation is free, the batch runs asynchronously, review tokens become invalid after content changes, per-shot/episode timing, polling constraints, and failure semantics. This goes far beyond what any annotation would typically provide.

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 a dense but efficient paragraph: core purpose and response shape first, then all critical usage constraints. Every sentence carries actionable information, with no filler or repetition.

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 polling tool with no output schema, the description is complete: it embeds the response format, specifies polling intervals, warns about token invalidation, explains failure handling, and names the downstream tools to gate on. An agent has everything needed to call and interpret the tool correctly.

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 schema only declares episode_id as an integer >0 with no description, so the description must compensate. It does so by repeatedly referring to '本集' (this episode), tying the sole parameter to the episode whose autofill batch is queried, and listing the associated status fields. It does not explicitly name episode_id or discuss invalid IDs, but for a single self-evident parameter this is adequate.

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 uses a specific verb '查' (check) with a specific resource: the episode's background autofill batch, and it lists the exact status fields returned. It clearly distinguishes itself from generic status tools by naming the batch's origin (auto_complete / autofill_storyboards) and its AI fill-in purpose.

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 conditions: must wait for status=done before review_storyboards/generate_frames, poll at intervals ≥10 seconds, and handle failed/fail>0 by inspecting the fail count and rerunning autofill_storyboards. This is concrete, sequential guidance for when and how to use the tool.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a read-only status query, reports cost (free), summarizes the returned data (running, tracks, cue count), and warns that completing BGM requires a separate compose step to affect the final cut. The main omission is a fuller status enumeration or error behavior, but the key traits are well covered.

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, then packs return contents, cost, and workflow caveat efficiently. The single dense sentence is slightly crowded but every clause earns its place; no filler is present.

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 status tool with no output schema, the description provides a good high-level return summary and an important downstream dependency (compose_episode). It could be more explicit about possible states or empty results, but an agent has enough context to invoke it correctly.

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?

There is one parameter, episode_id, with 0% schema description coverage, so the description must compensate. The phrase '某集' indicates the tool operates on an episode, which together with the parameter name makes the meaning reasonably inferable, but the description does not explicitly state that episode_id is the required episode identifier.

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 verb (查/check), a clear resource (AI BGM generation status of an episode), and enumerates the exact payload contents (running flag, stored track list, cue count). This clearly differentiates it from generation triggers like generate_bgm and from downstream composition via compose_episode.

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 actionable context: the tool is free, reports generation state, and clarifies that a completed BGM status does not automatically enter the final cut, requiring compose_episode afterward. It does not explicitly name alternatives or state when not to use it, but the workflow guidance is strong.

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

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

Annotations are absent, so the description carries the full burden. It does disclose the operation is a query ('查'), the fields returned, and that it is free. However, it provides no explicit read-only confirmation, error behavior, or data-freshness context.

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?

A single compact sentence carries the purpose, the return fields, and the cost note with zero filler. Every element earns its place, and the key information is front-loaded before the free note.

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 simple one-parameter status read with no output schema, the description covers purpose, return fields, and cost, which is largely sufficient. The main gap is the absence of alternatives guidance, but the low complexity keeps this from being a significant deficiency.

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 0% and drama_id has no per-parameter documentation. The description minimally compensates by establishing that the tool operates on '一部剧' (a drama), which clarifies drama_id's referent, but it adds nothing about where to source the id or its constraints beyond the 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?

The description states a clear verb (查/check), a specific resource (a drama's budget status), and enumerates the returned fields (budget/spent/remaining). The budget-status focus makes it distinguishable from siblings like get_cost_estimate or get_drama, though it never names those alternatives explicitly.

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 only guidance is '免费' (free), which speaks to cost rather than when to use this tool versus alternatives. It gives no conditions, no exclusion criteria, and no hint about when to prefer get_budget_status over related tools like get_cost_estimate.

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

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

With no annotations, the description carries the full burden, and it goes well beyond the obvious: it notes the call is free/static/no charge, discloses that unresolvable references are silently skipped, warns that stage directions in dialogue will be spoken, states that filled prompts are used verbatim without platform overrides, and says frame_visual_contract is ignored during import.

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?

Despite being long, the description is dense and structured with visual markers (★, bold, inline code), front-loading the core purpose before usage guidance and contract key points. Every section earns its place and no filler is present.

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?

There is no output schema, so the description carries the full burden of explaining what the returned contract contains, and it does so thoroughly: template, example, external prompt, checklist, enums, limits, top-level structure, deduplication rules, reference behavior, and import semantics. An agent has enough context to call and use the result correctly.

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 tool has zero parameters and an empty input schema, so there is no parameter ambiguity to resolve. The description adds useful semantic context by naming the returned contract fields and the top-level JSON shape, which is more than the empty schema provides.

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 opens with a specific verb and resource: retrieving the format contract for bulk-import JSON. It enumerates exactly what the contract contains (template, filled_example, external_prompt, checklist, enums, limits), and it distinguishes itself from the sibling import_storyboard_table by clarifying the structured-JSON vs text-table split.

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 states when to call this tool: when the customer has structured data or wants an external AI to produce JSON, and it says to call it before bulk_import_storyboards. It also gives an exclusion: if the customer has a text storyboard table, use import_storyboard_table instead.

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

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

With no annotations provided, the description carries full behavioral burden and does well: it discloses that the tool is free, local, does not access the network, and incurs no charge. It also explains the section-selection behavior and return categories, though it does not explicitly state 'read-only' or describe side-effect absence beyond implication.

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 densely packed with essential routing information, front-loaded with usage triggers and key constraints (free, local, no cost). All content earns its place, though the heavy parenthetical lists make it denser than strictly necessary.

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?

Despite having no output schema, the description thoroughly documents the return structure, including entry points, pipeline stages, review gates, QA tools, optional boosts, billing, and common requests, plus the section filter behavior. It also gives a concrete misuse example to anchor correct usage, making it effectively complete for an agent to invoke correctly.

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% and the schema already documents the single optional section parameter. The description adds value by explaining what each section value contains (entry_points, pipeline, review_gates, etc.) and restating the filter behavior, going beyond the bare enum names in the 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?

The description clearly identifies this as a '功能地图' (capability map) that answers 'which tool should be used when' rather than describing what a individual tool does. It explicitly contrasts itself with sibling tool descriptions and provides a concrete failure example, making its purpose and differentiation unmistakable.

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 names explicit trigger conditions: first contact with the server, when clients ask what the server can do or where to start, and when unsure which tool fits the material. It lacks an explicit 'do not use when you already know the exact tool' exclusion, but the contrast with tool descriptions implies this boundary clearly.

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

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

No annotations exist, so the description carries the full burden. It discloses the read-only nature, free cost, the complete status enum semantics, the meaning of rejection, and the financial risk of repeated retries. This is unusually transparent for a status-list tool.

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 and dense, but each section earns its place: purpose, status definitions, and retry decision logic. It is front-loaded with the core read operation before diving into edge-case handling.

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 serves as the only documentation of return structure and status behavior. It covers key statuses, rejection reasons, retryability, and next-step tools. It stops short of showing a concrete example response, but nothing essential for calling the tool is missing.

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?

There is only one parameter and schema coverage is 0%, so the description should compensate. It refers to the resource as '某一集', which maps to episode_id, but it does not explain the parameter by name or add format/usage detail beyond the schema's integer requirement.

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 opens with a specific verb ('读') and resource ('某一集的角色列表'), and further specifies the contained fields: names, portrait/sheet readiness. It clearly separates this read-only status tool from generation siblings by framing it as a status inspection endpoint.

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?

Includes explicit actionable guidance: do not re-trigger pending items, retry once for consistency_rejected via generate_character_sheet, and run run_precheck before retrying structurally impossible rejections. This names exact alternatives and the conditions that select them.

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

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

With no annotations, the description carries the behavioral burden. It explicitly labels the operation as a read ('读') and states a precondition: the color script must already have been generated. It also notes the operation is free ('免费'). This is good transparency for a read-only tool, though it does not describe failure behavior when no script has been generated.

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 two short sentences with no wasted structure. The core purpose is front-loaded, and the supplementary sentence adds useful contrast with the generation sibling. '免费' is extra but not harmful and still concise.

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 read-only tool with no output schema, the description provides the essential information: what it reads, for which scope, and that a prior generation step is required. It does not describe the return format, but that is less critical when the operation is a simple fetch and the resource is already defined.

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 schema has 0% description coverage and the description does not explain drama_id. However, the description's use of '该剧' (the drama) ties the single parameter to the target resource, and the parameter name is self-explanatory. Some compensation is present, but it does not explicitly describe the parameter or its constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.