Skip to main content
Glama

Create a video project

create_motion_project

Start a film (does not spend credits). Returns project.id. Optional, as on the Video tool's start screen: kind (ad, reel, explainer, talking_head, polish) brings that kind's usual length, shape, voice and captions; format is a ready format's slug and recipe_id one of the brand's saved recipes, both from list_studio_video_templates (a recipe carries its own kind, so do not send both); look is what the film is made of — filmed (generated footage), photo (the photos of the brand moving in 3D), motion (motion graphics — the director decides from the brief whether to draw it scene by scene or cut it to the music as one film, and can show the product in use), kinetic (motion graphics cut to the music, chosen outright), website (the real site of the brand on screen) or auto (decided per scene, the default). Next, describe the film with studio_video_message: the director writes its storyboard, edits to it are free and undoable, and get_studio_video shows it with the price of making it; make_studio_video makes it once the user agrees to that price. Poll get_studio_video until ready. The same film is visible to the owner in Creative Studio. THEIR OWN VIDEO (a talking head, a recording, clips to cut together): send from instead of kind/format/recipe/look — one of video_url (an https link to an MP4, WebM or MOV up to 80 MB; it is stored in the brand's Library first), asset_id (a video from list_brand_assets), asset_ids (several, in order: a rough cut, joined with join_studio_video_cut — a finished film's project_id counts as a clip too, its export joined as it is, so two finished films are joined without re-opening either), post_id (a calendar post's video) or cut_of (a joined cut's project id). Free: the clip is read and put on the timeline; then studio_video_message says what to do with it (clean the voice, captions, motion graphics cut to what they say, a new background, presenter or voice, or NEW SCENES before or after their clip — drawn motion-graphics beats on the same timeline, joined into one export, never a separate film) and the director prices it — nothing is charged until approve_studio_video_plan. title names the film (otherwise it is named after the clip).

Input Schema

NameRequiredDescriptionDefault
fromNoMake the film from their own video — exactly one of its fields
kindNoWhat the film is for
lookNoWhat the film is made of. Only when the user named it ("motion graphics", "AI footage", "filmed"); otherwise leave it out and the director decides per scene. Never infer a look from a concept, a static ad or your own taste.
titleNo
formatNoA template `slug` from list_studio_video_templates
brand_idYesBrand workspace id from list_brands
recipe_idNoA recipe `id` from list_studio_video_templates
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.
aspect_ratioNoe.g. 9:16, 16:9, 1:1
duration_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / look / description
      Previous value: -"What the film is made of"New value: +"What the film is made of. Only when the user named it (\"motion graphics\", \"AI footage\", \"filmed\"); otherwise leave it out and the director decides per scene. Never infer a look from a concept, a static ad or your own taste."
  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. Changed1 schema field changed
    • addedInput schema / properties / from / properties / as_is
      Added value: +{
      +  "description": "true: the video is finished — keep it exactly as uploaded. No automatic captions, music or pause cuts are applied; only what studio_video_message then asks for. Omit for a raw recording, which gets the automatic polish.",
      +  "type": "boolean"
      +}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already say it is a non-destructive write, but the description adds the crucial economics and state model: no credits spent at creation, storyboard edits are free and undoable, nothing is charged until approve_studio_video_plan, and the same film appears in Creative Studio. It also discloses the upload size/storage behavior for video_url and that a joined cut's export is joined as-is.

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 correctly, but the body runs long with em-dash-chained clauses and folds downstream workflow narration (polling, pricing, joining cuts) into a single tool's description. Sections like "THEIR OWN VIDEO" help scanning, yet several sentences repeat schema facts (80 MB limit, enums) and could be trimmed.

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?

With 10 parameters, a nested `from` object, two enums, and no output schema, the description carries its weight: it states what is returned (`project.id`), how to observe progress (poll get_studio_video until ready), and how the two creation paths differ. Nothing needed to call it correctly 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?

Adds real meaning beyond the schema: look values are explained in plain language, mutual exclusion of kind/format/recipe_id is stated ("a recipe carries its own kind, so do not send both"), and the one-of constraint on `from` fields is spelled out. However, aspect_ratio, duration_seconds, and user_goal get no treatment in the description, and their schema descriptions are thin.

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: "Start a film (does not spend credits). Returns `project.id`." It immediately distinguishes itself from the cost-incurring siblings (make_studio_video, approve_studio_video_plan) and from studio_video_message, so an agent can pick it out of a very crowded sibling list.

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/when-not routing: use kind/format/recipe/look for a generated film, use `from` instead for their own video, and don't send both format and recipe_id. It also spells out the post-creation sequence (studio_video_message → get_studio_video → make_studio_video / approve_studio_video_plan), which is exactly the alternative-selection information an agent needs.

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