Skip to main content
Glama

var2_create_audio

Create, EXTEND, or edit MUSIC / a song / a track (Suno). type ∈ create-music (default) | extend-music | replace-music-section. "extend that track by N seconds" / "make the song longer" / "continue past 1:00" → type=extend-music, track id in audioRecordId. "That track" without a re-pasted id = the track from earlier in this conversation — use its placeholder_id from context; never answer null / ask for a link. "replace / swap seconds X-Y of the track" → type=replace-music-section. ANY make/extend/lengthen/replace-section on a song / track / music = THIS tool — never a video or image tool, never an invented tool. "A song AND cover art" → START HERE (art = follow-up var2_create_image, not an upload). customMode=false: prompt = song description ≤2800 chars on V6/V6_WILD (≤500 on V5_5 and older). customMode=true: prompt = full lyrics; style + title required. Never name real artists or songs (copyright filter).

Input Schema

NameRequiredDescriptionDefault
typeNoDefault create-music.
modelNoDefault suno.
styleNoRequired when customMode=true. Max 200 chars.
titleNoRequired when customMode=true.
promptNocustomMode=false: song description ≤2800 chars on V6/V6_WILD, ≤500 on older (Suno writes lyrics). customMode=true: full lyrics.
continueAtNoRequired for extend-music. Seconds offset to extend from.
customModeNoDefault false. Set true when the user provides exact lyrics. Requires style + title.
infillEndSNoRequired for replace-music-section. Window end in seconds (> infillStartS; ~6-60s window).
webhook_urlNoOptional. https:// URL var2 POSTs a signed delivery to when the asset is ready (or fails). Signature header: X-VAR2-Signature: t=<unix>, v1=<hex(hmac_sha256(webhook_secret, t + "." + body))>. Retried with exponential backoff (8 attempts over ~4 days).
infillStartSNoRequired for replace-music-section. Window start in seconds.
instrumentalNo
audioRecordIdNoRequired for extend-music / replace-music-section. placeholder_id from the source var2_create_audio call (var2-hosted tracks only). "That track" = the most recent track in this conversation — take its placeholder_id from context rather than declining.
model_versionNoDefault V6 (latest). V6_WILD for bolder, more experimental takes. Older only for a specific sound.V6

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / model_version / default
      Previous value: -"V5_5"New value: +"V6"
    • changedInput schema / properties / model_version / description
      Previous value: -"Default V5_5 (latest). Older only for a specific sound."New value: +"Default V6 (latest). V6_WILD for bolder, more experimental takes. Older only for a specific sound."
    • changedInput schema / properties / model_version / enum
      Previous value: -[
      -  "V4",
      -  "V4_5",
      -  "V4_5PLUS",
      -  "V4_5ALL",
      -  "V5",
      -  "V5_5"
      -]New value: +[
      +  "V4",
      +  "V4_5",
      +  "V4_5PLUS",
      +  "V4_5ALL",
      +  "V5",
      +  "V5_5",
      +  "V6",
      +  "V6_WILD"
      +]
    • changedInput schema / properties / prompt / description
      Previous value: -"customMode=false: song description ≤500 chars (Suno writes lyrics). customMode=true: full lyrics."New value: +"customMode=false: song description ≤2800 chars on V6/V6_WILD, ≤500 on older (Suno writes lyrics). customMode=true: full lyrics."
  2. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations supply only a title, so the description carries the full behavioral burden. It does disclose real constraints: the copyright filter (never name real artists or songs), the customMode-dependent prompt semantics, and per-type required fields. However, it never states that generation is asynchronous, that the call yields a job/placeholder id, or how the finished asset is retrieved (var2_get_audio_result / webhook) — the central behavioral trait of an asset-creation tool is left implicit.

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?

The core purpose is front-loaded in the first clause, and the dense routing rules that follow each map to a real disambiguation need. It is long and mixes caps-lock emphasis with quoted user phrases, which hurts scanability slightly, but there is little filler.

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 13-parameter creation tool with no annotations and no output schema, the description covers input-side behavior well: type routing, per-type required fields, prompt constraints, and the placeholder_id convention for follow-up calls. The missing piece is the output lifecycle — the description never tells the agent that a result must later be fetched or that a webhook fires.

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 92%, so the baseline is 3, and the description genuinely adds value on top: it maps user phrasing to the 'type' enum, clarifies that extend targets 'audioRecordId' with the source track's placeholder_id, and spells out the customMode=false vs customMode=true prompt contract (description vs full lyrics). Some of this duplicates the schema, which keeps it out of 5 territory.

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?

The opening states a specific verb set and resource (create / extend / edit music, song, or track) and names the underlying provider (Suno). It actively differentiates from siblings ('never a video or image tool') and routes cover-art requests to var2_create_image. An agent can place this tool without opening any other 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?

Usage is mapped from natural-language user utterances to each type value ('make the song longer' → extend-music, 'replace seconds X-Y' → replace-music-section), with explicit exclusions ('never an invented tool'), a follow-up path for cover art, and a rule for resolving 'that track' from conversation context. This is about as explicit as routing guidance gets.

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