Skip to main content
Glama

Create a storyboard

create_storyboard

Draws the shots of a spot as one sheet of film frames in a grid, stills of one production with the same people, products and look in every frame and no text on the sheet, on the chosen image model (Tevyon's storyboard recipe). Write 2 to 8 shots with the user from their idea first, like a director: shot size and lens, camera move, the key moment, the light; products and logos come in as references and are copied one to one. Pass max_credits (from get_storyboard_price) and a new idempotency_key per intended storyboard. Images take under a minute; pass wait_seconds or poll get_job.

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": {
      "idea": "<idea>",
      "scenes": "<scenes>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "create_storyboard"
  }
}

Input Schema

NameRequiredDescriptionDefault
ideaYesThe spot in the user's words: what it is for, who is in it, the look.
lookNoOne line of art direction every frame shares: palette, light, set and one motif that runs through the film. Left out: taken from the idea.
modelNoAn image model from list_models (kind image). nano_banana_pro draws grids and keeps faces best.nano_banana_pro
formatNoThe format of each panel (and of the film made from it).9:16
scenesYesThe panels in order, 4 to 30 seconds together (the Kurzfilm's limits).
optionsNoThe model's own resolution or quality from list_models; left out: its best up to 2K.
referencesNoThe user's own uploads (create_upload, import_image): people, products, logos, app screenshots that look the same in every panel.
max_creditsNoThe credits from get_storyboard_price. Nothing starts if it now costs more.
wait_secondsNoSeconds to wait for the job to finish (0 to 50).
idempotency_keyYesA new unique string per intended storyboard, e.g. a UUID. Reuse it only to retry that one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare the generic write/idempotency profile, but the description adds material behavior: the credit guard means 'nothing starts if it now costs more', images finish in under a minute, references are copied one-to-one, and panels share one look with no text. It doesn't describe the returned job/image payload, but the operational traits an agent needs before calling 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.

Conciseness4/5

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

Two sentences, front-loaded with the deliverable, and every clause carries information (grid format, shared look, no text, shot-writing guidance, cost gate, idempotency, polling). The first sentence is a long run-on with many stacked clauses, which costs a little readability versus a genuinely crisp 5.

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?

For a 10-parameter nested-scene tool with no output schema, the description covers the workflow end to end: how to compose scenes, how to price and bound the call, how idempotency works, and how to wait or poll for the result. The main remaining gap is what the finished call returns (job vs. images), which the absence of an output schema leaves partly implicit.

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 coverage is 100%, so the baseline is 3, and the description earns a bump by giving provenance and intent for key params: max_credits must come from get_storyboard_price, idempotency_key is new per intended storyboard and reused only on retry, and wait_seconds trades off against polling get_job. It also conveys the 2-8 shot / reference-copy semantics that shape scenes and references.

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 opens with a specific verb and concrete output: 'Draws the shots of a spot as one sheet of film frames in a grid', with the shared-look and no-text constraints spelled out. That distinguishes it clearly from generic siblings like generate or run_preset, which don't produce a multi-panel storyboard sheet tied to one production's people and products.

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 real operating guidance: write 2-8 shots with the user 'like a director' before calling, source max_credits from get_storyboard_price, mint a new idempotency_key per intended storyboard, and either pass wait_seconds or poll get_job. What's missing is an explicit 'use this instead of X when…' comparison against siblings such as generate or run_preset.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources