FilmLab

Generate Music

lab_generate_music

Generate a MUSIC track for a project — the first step of the rhythm chain, and the only one that costs credits. Default engine: ElevenLabs Music v2.5 (produced, contemporary instrumental beds, 3-300 s, priced per second). Stable Audio stays selectable with tool 'stable_audio' (flat per run, up to 190 s, noticeably dated sound). ElevenLabs refuses prompts that name artists, bands or song lyrics; the failed row then carries its suggested rewording in metadata.error. ASYNCHRONOUS: the call returns immediately with a row whose audio_url is null and metadata.status is 'pending'. Nothing is playable and nothing can be bound yet. Poll lab_list_audio (audio_type 'music') until that row's status is 'completed' and audio_url is set — usually under a minute, and the backend gives up after five (status turns 'failed', metadata.error carries the reason, and the credits are refunded). PUT THE TEMPO IN THE PROMPT if you intend to cut on the beat. This is measured, not assumed: a soft swing track measured at confidence 0.164 (unusable), an ordered hard pulse ('techno, 128 bpm, four-on-the-floor') at 0.621. The tempo detector is autocorrelation over an onset envelope — it finds a hard pulse and shrugs at drone, ambient and rubato. Then: lab_bind_audio, lab_beatgrid, lab_apply_rhythm.

Input Schema

Name	Required	Description
`tool`	No	Music engine. Default 'elevenlabs_music' (ElevenLabs Music v2.5, per second, 3-300 s). 'stable_audio' is the older flat-priced engine (1-190 s)
`prompt`	Yes	What the music should be. Name genre, instrumentation, mood AND the tempo in bpm if the cut is supposed to sit on the beat — e.g. 'driving techno, four-on-the-floor kick, 128 bpm, no vocals'. A prompt without a stated pulse is the usual reason lab_beatgrid comes back unreliable
`get_cost`	No	`true` preflights the credit price and your balance WITHOUT generating anything and without spending quota.
`scene_ref`	No	Optional scene label, stored on the row. Useful to tell several tracks of one project apart
`project_id`	Yes	Project id (from lab_list_projects) — positive integer as string
`duration_seconds`	No	Track length in seconds (default 30). ElevenLabs takes 3-300 s (shorter is raised to 3), Stable Audio up to 190 s. Make it at least as long as the sequence you want to cut — lab_apply_rhythm computes durations for the clips that exist and neither adds nor deletes any, so a short track under a long timeline stays a short track

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 19, 2026

changedInput schema / properties / duration_seconds / description

Previous value: -"Track length in seconds (default 30, Stable Audio's ceiling is 190). Make it at least as long as the sequence you want to cut — lab_apply_rhythm computes durations for the clips that exist and neither adds nor deletes any, so a short track under a long timeline stays a short track"New value: +"Track length in seconds (default 30). ElevenLabs takes 3-300 s (shorter is raised to 3), Stable Audio up to 190 s. Make it at least as long as the sequence you want to cut — lab_apply_rhythm computes durations for the clips that exist and neither adds nor deletes any, so a short track under a long timeline stays a short track"

changedInput schema / properties / duration_seconds / maximum
```
Previous value: -190New value: +300
```

addedInput schema / properties / tool

Added value: +{
+  "description": "Music engine. Default 'elevenlabs_music' (ElevenLabs Music v2.5, per second, 3-300 s). 'stable_audio' is the older flat-priced engine (1-190 s)",
+  "enum": [
+    "elevenlabs_music",
+    "stable_audio"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 11, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedOct 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare only readOnlyHint=false and destructiveHint=false; the description adds substantial context beyond that: credit costs and per-second pricing, asynchronous call behavior (immediate row with null audio_url and status 'pending'), the polling contract, the five-minute backend timeout with failure reason and credit refund, and content refusal rules (no artist/band/lyric names, suggested rewording in metadata.error). This is a genuine behavioral disclosure of exactly the traits an agent cannot infer from the annotations.

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?

Front-loaded with the purpose and chain position, and every section (engine choice, refusal behavior, async/polling, tempo) earns its place. It is nonetheless long and the tempo discussion is carried across several sentences that could be tighter, which keeps it short of a 5.

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 6-parameter mutation tool with no output schema, the description supplies everything an agent needs: the async return shape (audio_url null, metadata.status 'pending'), how and how long to poll, the failure/refund path, and the prerequisites (project_id from lab_list_projects). No gap remains that would cause an incorrect invocation.

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 already 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the engine tradeoff (produced contemporary beds vs. noticeably dated sound, per-second vs. flat pricing, differing duration caps) and a nuanced warning that duration_seconds must cover the target sequence because lab_apply_rhythm neither adds nor deletes clips. The tempo guidance is also reinforced with measured evidence rather than just restated.

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 and resource ('Generate a MUSIC track for a project') and immediately positions it within the rhythm chain, explicitly contrasting it with the sibling engine tool 'stable_audio'. An agent can distinguish it from lab_bind_audio, lab_beatgrid and lab_apply_rhythm 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?

Explicitly says this is the first step of the rhythm chain and the only one that costs credits, names the downstream tools (lab_bind_audio, lab_beatgrid, lab_apply_rhythm), states the polling alternative lab_list_audio with the audio_type filter, and gives the when-to-use conditions for switching to stable_audio. Nothing is left to inference.

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

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