Skip to main content
Glama

Plan a music video

plan_music_video

The director's treatment and shots for a music video, before anything is charged. Free (a limited number an hour). Takes about a minute. Returns a plan: the concept, the face and outfit photos, and one shot per 15-second clip with its lyrics. Show it to the user, rewrite it with revise until they like it, then quote_music_video and create_music_video with its plan_id.

Input Schema

NameRequiredDescriptionDefault
castNoThe two photos the artist is kept from: face_photo_id (a sharp face, mouth visible) and outfit_photo_id (the outfit and body worn throughout); either left out, the director picks it. One photo can be both; hidden photos (add_artist_photos hidden) work too
trimNoOnly this section of the song (15 seconds to 10 minutes); omitted, the whole song (15 seconds to 10 minutes long)
modelNoThe music video model: one-take (default; one continuous, lip-synced take of the artist). get_options lists the models with the categories, styles, formats and length each makesone-take
styleNoOptional look: natural, film, golden-hour, neon-night, noir, vintage or dreamy; omitted, the director picks one from the cover
reviseNoRewrite an earlier plan of this song: {"plan_id":"plan_…","note":"what to change"} (the next draft)
scenesNoWhere it is set besides the places the direction mentions from the kit: {"mode":"invent"} (default: the director imagines the others) or {"mode":"stock"} (it finds a real stock photo of each place it writes, empty of people, and the artist is put into it), up to the model's kit.places in all
song_idYesThe song; its artist performs the video and needs photos (add_artist_photos)
categoryNoperformance (default), intercut, cinematic, story or surrealperformance
directionNoOptional notes for the director (a place, an era, a story idea, a mood). Mention kit pieces by @handle (list_kit): "@nina-kazora in the @blue-set on the @rooftop, the @chrome-mic in hand"; a mentioned piece is used exactly as it is and the director designs the rest. An unknown handle answers 400
lookbook_idNoA lookbook (design_music_video_shoot) whose kept, drawn pieces the video uses like the kit pieces the direction mentions; its idea leads the director
aspect_ratioNo"9:16" (default), "16:9" or "1:1"9:16

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: it is free, rate-limited to a limited number per hour, takes about a minute, and produces no charge. The annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) don't convey cost, latency, or throughput limits, so this is real added value. It stops short of describing failure modes or what happens to earlier plans after a revise.

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?

Four sentences, front-loaded with what the tool is and its cost, then the return shape, then the workflow. No filler and no restatement of the title.

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 an 11-parameter nested-schema tool with no output schema, the description covers cost, latency, and the structure of the returned plan, plus the full downstream workflow. Minor gaps remain around retrieving a plan later (get_music_video_plan) and revise history handling, but an agent can call it correctly from what is here.

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 100%, so the schema already documents every parameter including cast, trim, direction handles, and revise. The description only reinforces the plan_id linkage to downstream tools and the one-shot-per-15-second structure, which is marginal beyond the schema. Baseline 3 is appropriate.

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+resource: it produces the director's treatment and shot list for a music video, explicitly framed as the pre-charge planning stage. That framing alone separates it from create_music_video and quote_music_video without opening their schemas.

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 an explicit sequence: generate the plan, show the user, iterate with `revise` until satisfied, then call quote_music_video and create_music_video with the plan_id. It also names the alternative stage (charging) and tells the agent not to skip ahead.

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