Skip to main content
Glama

Talk to the video director

studio_video_message

One turn of the film's conversation with its director. The conversation turn is free; when an active persistent editing cap authorizes a requested paid edit, that edit may start without another Make approval and reports spend_pending plus editing_budget. Say what the film should be, or what to change, in the user's words: the scenes, their words, the music, the voice, captions, the style, the length, its playback speed, a scene made again or with a new person in it. (A plain speed change on a finished film — "make it 1.25x" — is set_studio_video_speed: free, one call per film.) The director writes and edits the film's storyboard straight away — except that a bare idea with no storyboard yet ("a reel for my bakery") may be talked through first: up to three short replies, one question each, before it writes; "just make it" or "decide for me" skips that. Every draft change is free and can be undone (edit_studio_video_storyboard undo, or revert_turn with the turn_id this returns). The turn itself is free. It may queue a requested paid edit when an active persistent editing budget authorizes it; that edit reports spend_pending and editing_budget with its actual charge. Without an active cap, no paid edit is queued from this connector turn. The film's initial make still uses the one button, which get_studio_video shows with its price, and only make_studio_video presses it. If the user asks to make the initial film in chat and no persistent cap is active, propose make_studio_video with the button's quote_hash and credits so the price is shown ON the card; otherwise confirm the price with them in words first, then call it. A requested paid edit within an active cap is handled by this turn and does not need another Make card. On a film made from their own video, ask here for new scenes before or after their clip (e.g. "a 14-second motion-graphics ending after my clip"): the director adds them to the same film at their price, joined into one export — never a second film to join. On their own talking footage, ask here for words on screen too — e.g. "split the big words around me, behind me": one phrase they say, set huge in two halves that frame them and pass behind them (the cut-out behind them is the one priced part of that plan). Returns the director's reply, changes (the edits it applied, each { id, summary }), turn_id when it changed anything, and ask when it has a question: answer with answer: { question_id, option_id }. ask.ideas offers three ideas (pick one by its option_id, or ignore them and keep talking); ask.scope asks whether a change is for one scene or all like it (scope:this / scope:all); ask.intake_form asks everything still missing at once (see its how_to_answer). Answers within about 40 seconds: a turn that takes longer answers still_working: true with asked_at — do NOT send the message again; poll get_studio_video until last_reply_at is later than asked_at, and read the reply, question, storyboard and button there.

Input Schema

NameRequiredDescriptionDefault
answerNoAnswer to the option card from `ask`
messageNoWhat the user wants, in their words. Pass on what they said and any concept or script they agreed; never add a visual style, treatment or medium they did not ask for (live film 408e93ad, 1 Nov 2026: "a video ad" was sent as "a motion-graphics video ad" and made as moving type). The director decides what each scene is made of.
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
concept_idNoDevelop this idea from a `concepts` plan
project_idYesProject id from create_motion_project. The bare project id or the library id ("studio-video:<uuid>" from list_creations / find_creation) both work.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / message / description
      Previous value: -"What the user wants, in their words"New value: +"What the user wants, in their words. Pass on what they said and any concept or script they agreed; never add a visual style, treatment or medium they did not ask for (live film 408e93ad, 1 Nov 2026: \"a video ad\" was sent as \"a motion-graphics video ad\" and made as moving type). The director decides what each scene is made of."
  2. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  3. Changed3 schema fields changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Project id from create_motion_project"New value: +"Project id from create_motion_project. The bare project id or the library id (\"studio-video:<uuid>\" from list_creations / find_creation) both work."
    • removedInput schema / properties / project_id / format
      Removed value: -"uuid"
    • addedInput schema / properties / project_id / pattern
      Added value: +"^(?:studio-video:)?[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"
  4. Changed1 schema field changed
    • addedInput schema / properties / answer / properties / form_text
      Added value: +{
      +  "additionalProperties": {
      +    "maxLength": 400,
      +    "type": "string"
      +  },
      +  "description": "Exact text for intake rows with allows_text, keyed by question_id",
      +  "propertyNames": {
      +    "maxLength": 60
      +  },
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say non-readonly, open-world, non-idempotent; the description adds far more: turns are free, drafts are undoable, paid edits only fire under an active cap and report `spend_pending`/`editing_budget`, at most three clarifying replies, and a ~40s timeout that returns `still_working` with instructions to poll get_studio_video rather than resend. That last point alone prevents a costly duplicate call.

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

Conciseness3/5

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

Front-loaded with the core purpose and the key sibling routing, but the body is a dense ~450-word wall with real redundancy: 'The conversation turn is free', 'Every draft change is free', 'The turn itself is free' repeat the same fact, and the active-cap/paid-edit rule is restated in three separate places.

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

Completeness5/5

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

For a complex, branching, open-world conversational mutation with no output schema, the description covers return values (`reply`, `changes`, `turn_id`, `ask`), the timeout/polling path, undo routes, and the paid-vs-free boundary. Nothing an agent needs to call it safely is missing.

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; the description earns extra by explaining the conversational `answer` contract — `answer: { question_id, option_id }`, and the three `ask` shapes (ideas, scope:this/scope:all, intake_form with how_to_answer) — which is genuinely semantic guidance beyond the schema's field descriptions.

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?

Opens with a specific verb and resource: 'One turn of the film's conversation with its director.' It then explicitly demarcates itself from siblings — set_studio_video_speed for a plain speed change, make_studio_video for the initial make, edit_studio_video_storyboard `undo` for reverts — so an agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and when-not-to-use rules with named alternatives: speed changes go to set_studio_video_speed, the initial film goes through make_studio_video's button, and paid edits only queue when a persistent cap is active. It also states the edge case where a bare idea may be talked through first and how to skip that ('just make it').

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