Kuro

Save a video beat sheet

save_video_analysis

DestructiveIdempotent

Store your beat sheet for an analysed video. Read measure_video first. Emit exactly one shot object per shot in the bundle, with the same index — a beat sheet whose indexes do not match the measured shots is rejected and nothing is stored. image_prompt and motion_prompt should describe the shot for a DIFFERENT subject: that is what makes the format reusable. Costs no credits.

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": {
      "upload_id": "<upload_id>",
      "beat_sheet": "<beat_sheet>"
    },
    "name": "save_video_analysis"
  }
}

Input Schema

Name	Required	Description	Default
`upload_id`	Yes
`beat_sheet`	Yes

Output Schema

Name	Required	Description	Default
`author`	Yes
`status`	Yes
`message`	Yes
`upload_id`	Yes
`shot_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026
- changedInput schema / properties / beat_sheet / properties / shots / items / properties / motion_prompt / maxLength
```
Previous value: -1000New value: +6000
```
First observedOct 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses atomic validation failure ('a beat sheet whose indexes do not match the measured shots is rejected and nothing is stored'), the zero-credit cost of the call, and the requirement that image_prompt/motion_prompt target a different subject. These are the exact behaviors an agent needs and none are inferable from destructiveHint/idempotentHint.

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

Conciseness5/5

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

Five short sentences, front-loaded with the precondition before the validation rule and the prompt guidance. Every sentence carries a distinct, actionable constraint; no filler.

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?

Given a deeply nested schema with zero field descriptions and an output schema that covers return values, the description covers the highest-risk failure mode and the reusable-format rationale well. It is still thin on the structural fields (beats vs shots, allowed roles/shot sizes) that an agent must populate blind.

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

Parameters3/5

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

Schema description coverage is 0%, so the description has to carry the semantics and it only partially does. It usefully constrains the shots array (one object per measured shot, matching index) and the content of image_prompt/motion_prompt, but leaves the many nested fields — role, shot_size, camera enums, beats, tags, hook, structure — entirely 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?

States a specific verb and resource ('Store your beat sheet for an analysed video'), which is plainly distinct from the read-side siblings get_video_analysis and measure_video. The precondition reference to measure_video pins down exactly which artifact this persists.

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?

Explicitly names the prerequisite tool ('Read measure_video first') and states the hard acceptance condition (indexes must match measured shots or nothing is stored). It does not spell out what to do instead when a beat sheet already exists or how to read one back, so it stops short of full alternative routing.

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

All Kuro tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?