Skip to main content
Glama
Sign In

switch

by ai.switchapp
OverviewDiscussionsAdmin

Generate Music

generate_music

Make a music track with ElevenLabs Music: a song, a score, a background bed. Either describe the whole track in prompt (genre, mood, instruments, tempo, era, how it builds) or pass a plan you got from plan_music, edited however you like. seconds sets the length, 3 to 600 (default 30). For music under a video pass project_id (or video_seconds): the track is asked at the video's length, and if it comes back shorter the answer says how to loop it on a musical boundary; tell the creator and never leave the end silent. One take per ask: a second track minutes after the first needs another_take_reason with the creator's own words. instrumental true keeps every voice out. HOUSE RULE: only put music on a job when the customer actually asked for music; never add a bed because it feels empty, and when music is asked for keep it to what they named. This tool is NOT for sound effects: whooshes, impacts, chimes, risers, foley and ambiences are generate_sound_effect. Billed per 10 seconds (a token quote applies) and the file is saved to your library. Returns audio_url, duration_seconds and generation_id.

Input Schema

NameRequiredDescriptionDefault
planNoOptional. The composition plan object plan_music returned, edited however you like. When this is sent the plan decides the structure and the length.
promptNoThe whole track in plain words, for example "driving hard rock instrumental, live drums, dirty guitars, 140 bpm, builds to a big last chorus". Leave out when you are passing an edited plan.
secondsNoOptional length in seconds, 3 to 600. Default 30. Ignored when a plan is sent, because the plan carries its own section lengths.
part_onlyNoOptional. true only when the creator asked for music on part of the video, so a shorter track is right.
project_idNoOptional. The Editor project this music is for; its video length sets the track length.
instrumentalNoOptional. true makes a track with no singing and no voices at all.
video_secondsNoOptional. The length of the video this music sits under, when there is no project.
another_take_reasonNoOnly for a second track minutes after the first: the creator's own words asking for another or a different one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / plan / description
      Previous value: -"Optional. The composition plan object plan_music returned, with its sections edited however you like. When this is sent the plan decides the structure and the length."New value: +"Optional. The composition plan object plan_music returned, edited however you like. When this is sent the plan decides the structure and the length."
  2. Changed4 schema fields changed
    • addedInput schema / properties / another_take_reason
      Added value: +{
+  "description": "Only for a second track minutes after the first: the creator's own words asking for another or a different one.",
+  "type": "string"
+}
    • addedInput schema / properties / part_only
      Added value: +{
+  "description": "Optional. true only when the creator asked for music on part of the video, so a shorter track is right.",
+  "type": "boolean"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "description": "Optional. The Editor project this music is for; its video length sets the track length.",
+  "type": "string"
+}
    • addedInput schema / properties / video_seconds
      Added value: +{
+  "description": "Optional. The length of the video this music sits under, when there is no project.",
+  "type": "number"
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (not read-only, not destructive, closed-world); the description adds substantive behavior beyond that: billing per 10 seconds, a token quote, persistence to the library, the one-take-per-ask rule with its required justification, and how the length is derived from project_id/video_seconds plus what happens when the result comes back short. That is unusual, actionable disclosure for a paid generative mutation.

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 verb and the two input modes before any policy talk, and each paragraph covers a distinct decision (mode, length, retakes, material type, billing/return). It is dense and slightly longer than needed — the sound-effect exclusion and the length discussion each get more words than required — but nothing is genuinely wasted.

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 eight optional parameters, a nested plan object, and no output schema, the description still covers input modes, length resolution, retake policy, billing, and the exact return fields (audio_url, duration_seconds, generation_id). An agent has everything needed to call it correctly and interpret the result.

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 would be 3, but the description adds semantics the schema does not: a passed plan overrides both prompt and seconds, project_id makes the track follow the video's length, and the shortened-result/loop guidance for video scoring. It does not materially deepen instrumental or part_only beyond their schema text, so it stops short of the top band.

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 ("Make a music track with ElevenLabs Music") and enumerates the concrete outputs (song, score, background bed). It also names the sibling it is explicitly not for (generate_sound_effect) with the exact categories that route elsewhere, so an agent can separate it from that tool 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 the two mutually exclusive authoring paths (free-text prompt vs. an edited plan from plan_music), the condition for each, and the precedence rule (plan wins, seconds is ignored). It also states the exclusion (sound effects → generate_sound_effect) and a policy constraint on when music may be added at all, which is exactly the when/when-not coverage the top band requires.

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

All switch toolsInspect
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