check_storyboard_table

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.