Kinetune

Design a music video lookbook

design_music_video_shoot

The director designs the outfits, places and props the brief leaves to it as pictures, before the shot list Optional, before the shot list (plan_music_video). Free to design (a limited number an hour), about a minute: returns a lookbook whose pieces are the brief's own kit pieces (yours, used as they are) and the director's designs (an outfit drawn on the artist, a place drawn empty, a prop alone), not drawn yet. price.draw.credits is what drawing them costs: tell the user, then render_music_video_lookbook after their go. Same brief as plan_music_video. Needs an active plan (402 plan_required without one; get_account: plan.active) and room in its storage (402 storage_full when it would not fit; get_account: storage).

Input Schema

Name	Required	Description	Default
`cast`	No	The 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
`trim`	No	Only this section of the song (15 seconds to 10 minutes); omitted, the whole song (15 seconds to 10 minutes long). Best: a part from get_song_analysis (parts[]: its start and end never cut a word)
`model`	No	The music video model: one-take (default; MiniMax H3 Max, the artist lip-synced in shots cut between the song's lines). get_options lists the models with the categories, styles, formats, takes and length each makes	one-take
`style`	No	Optional look: natural, film, golden-hour, neon-night, noir, vintage or dreamy; omitted, the director picks one from the cover
`takes`	No	How the shots meet: "cuts" (default: shots meet between the song's lines like an edit, with a cut or the transition the director picks at each join: dissolve, dip to black, flash or whip; ask for them, or for none, in direction) or "continuous" (the director may carry a shot on into the next through a picture drawn of the moment they meet, priced per picture; the quote before a plan counts every join, the plan's quote only the ones it draws)	cuts
`scenes`	No	Where 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_id`	Yes	The song; its artist performs the video and needs photos (add_artist_photos)
`category`	No	performance (default), intercut, cinematic, story or surreal	performance
`direction`	No	Optional 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
`aspect_ratio`	No	"9:16" (default), "16:9" or "1:1"	9:16

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

changedInput schema / properties / model / description

Previous value: -"The 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 makes"New value: +"The music video model: one-take (default; MiniMax H3 Max, the artist lip-synced in shots cut between the song's lines). get_options lists the models with the categories, styles, formats, takes and length each makes"

addedInput schema / properties / takes

Added value: +{
+  "default": "cuts",
+  "description": "How the shots meet: \"cuts\" (default: shots meet between the song's lines like an edit, with a cut or the transition the director picks at each join: dissolve, dip to black, flash or whip; ask for them, or for none, in direction) or \"continuous\" (the director may carry a shot on into the next through a picture drawn of the moment they meet, priced per picture; the quote before a plan counts every join, the plan's quote only the ones it draws)",
+  "enum": [
+    "cuts",
+    "continuous"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 28, 2026

changedInput schema / properties / trim / description

Previous value: -"Only this section of the song (15 seconds to 10 minutes); omitted, the whole song (15 seconds to 10 minutes long)"New value: +"Only this section of the song (15 seconds to 10 minutes); omitted, the whole song (15 seconds to 10 minutes long). Best: a part from get_song_analysis (parts[]: its start and end never cut a word)"

AddedOct 28, 2026

TDQS

A4/5.0

Behavior5/5

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

Well beyond annotations: discloses rate limiting ('a limited number an hour'), latency ('about a minute'), the credit field to quote to the user, and the two gating conditions with their error codes and where to check them (get_account: plan.active, storage). It also clarifies the return is a not-yet-rendered lookbook, which annotations alone would never convey.

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?

Information-dense and mostly front-loaded, but the opening contains a duplicated, unparseable clause ('before the shot list Optional, before the shot list (plan_music_video)') and the colon-heavy phrasing makes the pricing/next-step sentence hard to parse on a first read.

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 creation tool with no output schema, it covers cost, latency, prerequisites, error codes, the returned artifact and the follow-up call. Only gaps are the missing differentiation from lookbook siblings and a slightly unclear statement of what happens when the hourly limit is hit.

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 coverage is 100%, so every parameter including the nested cast, trim, scenes and direction objects is already documented. The description only adds 'Same brief as plan_music_video', which helps frame the inputs but gives no per-parameter semantics beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (the director designs outfits, places and props as pictures) and a concrete artifact (a lookbook whose pieces are kit pieces plus new designs, not drawn yet). It distinguishes itself from plan_music_video and render_music_video_lookbook. The garbled 'before the shot list Optional, before the shot list' phrase muddies an otherwise clear opening.

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 explicit sequencing ('before the shot list (plan_music_video)') and a next step ('tell the user, then render_music_video_lookbook after their go'), plus prerequisites with the exact 402 codes. It doesn't contrast against siblings like redesign_music_video_lookbook or update_music_video_lookbook, so alternatives are only partially covered.

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

All Kinetune 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?