Skip to main content
Glama

编辑分镜文字和时长

pavo_script_update_storyboard
Idempotent

Updates one storyboard segment by validating fingerprints, saving shot and scene text, durations, and media references, then reading back changes while preserving existing media and other fields.

Instructions

按get_storyboard的_mcp_fingerprints.storyboard核对后保存,同一次仅编辑一个片段,整集须逐段调用。shots每项含shot_id及content_rich/duration_sec;scenes每项含scene_id/content_rich,内容仅为一个本项目场景标签,细节写镜头正文。单镜时长为1至15整数,素材标签必须属于本项目。沿官网PATCH shots保存并回读文字、时长、素材引用、派生视频提示词;保护原媒体与其余字段。不生成、不付费;UNKNOWN禁止换号重投。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "episode_id": "<episode_id>",
      "shots": "<shots>",
      "scenes": "<scenes>",
      "expected_sha256": "<expected_sha256>",
      "operation_id": "<operation_id>"
    },
    "name": "pavo_script_update_storyboard"
  }
}

Input Schema

NameRequiredDescriptionDefault
shotsYes
scenesYes
episode_idYes
project_idYes
operation_idYes
expected_sha256Yes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false, openWorld=true), the description explains optimistic concurrency through expected_sha256 fingerprint checks, a read-back verification of text, duration, asset references, and derived video prompts, and partial-update protection for original media and other fields. It also states that the tool neither generates content nor incurs billing, and that UNKNOWN means the call must not be retried with a new id, which is critical and non-obvious behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loads the fingerprint-verification step, the one-segment-per-call rule, and the shots/scenes field layout before the save-and-read-back semantics. Every sentence carries information, though the extreme terseness of the UNKNOWN and '不生成、不付费' clauses makes them slightly cryptic.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with six required parameters, a 0%-described schema, and an output schema, so an agent needs the safety and concurrency context the description does provide. The gaps are the role of operation_id for idempotent retries and the role of project_id/episode_id, which are only implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and both shots and scenes are free-form objects (additionalProperties: true), so the description must carry the parameter meaning. It documents shot_id, content_rich, and duration_sec, the 1-15 integer range for duration, the requirement that asset tags belong to this project, and the scenes' single-tag constraint, but it leaves expected_sha256 and operation_id unexplained.

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

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: editing storyboard shot text (content_rich) and duration (duration_sec) for a project episode, and saving them. It explicitly names sibling get_storyboard as the source of the _mcp_fingerprints/storyboard to verify against, which separates this edit path from create_storyboard_shot and delete_storyboard_shot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear preconditions and process: verify against get_storyboard's fingerprints first, then save; edit only one segment per call; and call the tool once for every segment in an episode. It does not explicitly say when to use create_storyboard_shot or delete_storyboard_shot instead, so it lacks stated alternatives, but the context is otherwise unambiguous.

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