Skip to main content
Glama
unifically-dev

UnificAlly MCP Server

Official
by unifically-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Generate music

generate_music
Destructive

Create a song from a description or lyrics; make covers, extend tracks, add vocals or instrumental, split stems, write lyrics, or make sound effects with Suno.

Instructions

Full Suno suite. mode 'music' (default) makes a new song from a description (or lyrics with custom:true). Transform an existing track (pass audio_url): 'cover' (new style), 'extend' (longer, +continue_at), 'add-vocals' / 'add-instrumental' (layer on). Split a prior clip (pass clip_id): 'stems' / 'stems-all', or 'wav' to export it. 'lyrics' writes lyrics; 'sound' makes a sound effect from a prompt. Set instrumental for no vocals. Returns the audio URL(s).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mvNoSuno model version for songs — default 'chirp-bluejay'; others 'chirp-v3-5', 'chirp-v4', 'chirp-auk', 'chirp-crow', 'chirp-fenix'. ('sound' defaults to 'chirp-fenix' and 'lyrics' to 'default' — both still honor an explicit mv if you pass one.)
modeNoSuno operation. 'music' (default) makes a new song. 'cover' re-sings a track; 'extend' lengthens it (needs continue_at); 'add-vocals'/'add-instrumental' layer onto it; 'stems'/'stems-all' split a track (need clip_id); 'lyrics' writes lyrics; 'sound' makes a sound effect from a prompt; 'wav' exports a clip as WAV (needs clip_id). cover/extend/add-vocals/add-instrumental need audio_url.
tagsNoMusic style tags, e.g. 'pop, electronic, upbeat'.
waitNoDefault true: wait for the job and return the finished result. Set false to get the task_id back immediately and poll with get_task — use for long jobs (high-quality video, full songs) or when the connection might time out.
titleNoSong title.
customNomusic/cover/extend only. false (default): prompt is a description. true: prompt is the full lyrics; style goes in tags.
promptNoFor mode 'music' (default): the song description (simple) or full lyrics (custom:true). For 'cover'/'extend'/'add-vocals'/'add-instrumental': optional style/lyrics guidance. For 'sound': describe the sound effect (required). For 'lyrics': the lyric idea. Not used by stems/stems-all/wav.
clip_idNoClip id of a completed Suno music task — required by 'stems'/'stems-all' (split into stems) and 'wav' (export as WAV).
audio_urlNoSource track (public https URL) for cover/extend/add-vocals/add-instrumental. For local files, upload_file first.
continue_atNoFor extend: the time in seconds of the source track to continue from (required for 'extend').
callback_urlNoOptional webhook URL. When set, the tool returns immediately with the task_id and UnificAlly POSTs the result to this URL when the task finishes. Webhook body: { task_id, status: 'completed'|'failed', data: { video_url | image_url | audio_url | ... }, error_message? } — note the media arrives under 'data', not 'output'. Use for long jobs instead of waiting.
confirm_costNoOnly relevant if the operator enabled a spend guard. When a call exceeds the configured confirm threshold it returns a quote; retry with confirm_cost: true to proceed. Safe to ignore otherwise.
instrumentalNotrue for instrumental-only (no vocals).
negative_tagsNoStyles to avoid, e.g. 'metal, jazz'.
provider_optionsNoEscape hatch for model-specific fields not exposed as named parameters (e.g. Kling multi_shots, Flux steps). Merged into the API 'input' payload. Rejected: fields the tool already manages (prompt, media URLs, task_id, ...) and reserved routing/billing/auth keys (model, callback_url, dry_run, api_key, authorization) — switch models with the 'model' parameter, not here. See https://docs.unifically.com for per-model fields.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotency, so the safety profile is covered. The description adds the useful output fact ("Returns the audio URL(s)") and describes what each mode does to the source audio (re-sing, lengthen, layer). It does not reconcile the destructiveHint=true annotation with a generation tool (credit spend), nor discuss async/callback semantics, so it adds only moderate context.

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 key discriminator ("full Suno suite", default mode) is front-loaded, then modes are grouped by what they operate on. It is dense and somewhat run-on for a single paragraph, but every clause carries distinct operational information for a 10-mode, 15-parameter tool.

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?

With no output schema, the description must say what comes back, and it does ("Returns the audio URL(s)"), plus instrumental/negative_tags behavior. Cost confirmation, wait/polling, and webhook behavior live only in the schema, so those aspects are not reinforced in prose — acceptable for a tool of this complexity but not exhaustive.

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 description coverage is 100%, so the schema already documents all 15 parameters and the baseline would be 3. The description earns an extra point by synthesizing the mode-to-input dependency graph in one place (audio_url for cover/extend/add-vocals/add-instrumental, clip_id for stems/wav, continue_at for extend), which is faster to act on than reading ten separate property descriptions.

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 verb and resource ("makes a new song", "Full Suno suite") and enumerates all ten modes with their effects, so the scope is unambiguous. It never names a sibling tool, though — an agent must infer on its own why this differs from generate_audio (speech/TTS) or generate_video, which is the only thing keeping it from a 5.

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?

Usage is conditioned per mode: transform an existing track by passing audio_url, split a prior clip by passing clip_id, 'stems'/'stems-all' and 'wav' require clip_id, 'extend' needs continue_at. That is strong when-to-use guidance. What is missing is explicit when-NOT or alternative routing (e.g. use generate_audio for voice work), so it stops short of a 5.

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

Deploy Server

Other Tools