Quotes the point cost to break a script episode into storyboards. Returns estimated_points and quote_id without charging, allowing user approval before generating the storyboards.
报价:把某一集的剧本拆成分镜(storyboards)要多少点。返回 estimated_points 与 quote_id。零扣费。拿到后把点数告诉用户征求同意,再用 quote_id 调 generate_storyboards。
| Name | Required | Description | Default |
|---|---|---|---|
| episode_id | Yes |
Changes observed during successful MCP inspections.
v0.1.57Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses that this is a zero-charge quote operation, that it returns an estimate rather than performing generation, and that a consent step must precede the actual generation. It does not mention rate limits or error cases, but no side effects are hidden.
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 segment earns its place: purpose, return values, zero-cost guarantee, and required follow-up workflow. It front-loads the core function before the usage instructions, with no filler or repetition of schema fields.
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 tells the agent exactly which fields to expect and what to do with quote_id. For a single-parameter quote tool, it covers the full calling context: input, output, cost behavior, and the required next action. Nothing essential 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 description coverage is 0%, so the description needed to compensate for the single episode_id parameter. It contextualizes the parameter as '某一集' and connects it to the script-to-storyboards quote, but it does not add much detail beyond the property name and integer type. The parameter is simple, but the description only minimally enriches 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 states a specific verb (quote), resource (breaking a specific episode's script into storyboards), and outcome (cost estimate with estimated_points and quote_id). It also distinguishes itself from generate_storyboards, which is the follow-up generation step, so the agent can tell it apart from the many quote_* 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?
It explicitly prescribes the workflow: obtain the quote, show the points to the user and get consent, then call generate_storyboards with quote_id. It also notes zero deduction, signaling that this tool is safe for a non-committal cost check. This is explicit when-to-use and next-step guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.