OpenSoundBox — AI song generator

Sing a song from finished lyrics

create_song

Queues a song with real vocals to YOUR finished lyrics and immediately returns a link to its page with two versions to choose from. The song itself is usually ready in 15–60 seconds. LANGUAGE: write the lyrics in the language the person speaks to you (or asks for) and pass its ISO code in language. Russian songs live on opensoundbox.ru, all other languages on opensoundbox.com — the server picks the site itself; just give the person the link it returns. 50 languages are supported; checked and sounding good: English, Russian, Spanish, German, French, Italian, Portuguese, Polish, Ukrainian, Chinese, Japanese, Korean, Turkish, Hindi (others may sound less clear). HOW TO WRITE THE LYRICS (the server sings them as is, without edits):

tag sections in square brackets on their own line: [Verse], [Chorus], optionally [Bridge], [Outro];
clear rhythm and rhyme, 6–10 syllables per line, natural conversational language;
put the person's name, the occasion and details in the lyrics; keep the chorus short, catchy and repeated;
length to match the song: up to 45 s — one 4-line verse, a 4-line chorus, then the chorus again; up to 60 s — one 4-line verse, a 4-line chorus, then the chorus again; up to 120 s — two 4-line verses, a 4-line chorus after each verse, an optional short bridge; up to 240 s — three 4-line verses, a 4-line chorus after each verse, a 2–4 line bridge; up to 300 s — four 4-line verses, a 4-line chorus after each verse (write every chorus repeat in full), a 4-line bridge — about 40 lines in total;
one language and one alphabet per song; don't mix alphabets in one line;
ORIGINAL lines only: lyrics quoting well-known songs or poems are rejected, and so are lyrics with profanity. The sound is set by style, voice and an optional description (instruments, tempo, mood).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "lyrics": "<lyrics>",
      "language": "<language>"
    },
    "name": "create_song"
  }
}

Input Schema

Name	Required	Description
`style`	No	music style preset (pop, rock, hiphop, rnb, country, edm, poppunk, indie, lofi, kids, ballad, chanson, lullaby, folk, jazz); custom — your own style from sound_description (no preset is mixed in). Default auto — the server picks a style from the lyrics
`title`	No	optional: the song title for its page
`voice`	No	voice; default auto — picked from the lyrics
`lyrics`	Yes	finished song lyrics with [Verse]/[Chorus] section tags on their own lines
`language`	Yes	ISO code of the lyrics language (ru, en, es, de…): the language you wrote the lyrics in. The server checks it against the lyrics and trusts the lyrics if they disagree. ru — the song lives on opensoundbox.ru, any other — on opensoundbox.com
`duration_seconds`	No	song length in seconds, in steps of 15; default 60
`sound_description`	No	optional (required with style=custom): the sound in your own words, e.g. "doom metal with church organ, slow, heavy"

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations only declare that this tool is not read-only and not destructive. The description adds substantial behavior beyond that: queueing is async (song ready in 15-60s), the server picks the hosting site automatically, lyrics are sung verbatim without edits, and submissions with quoted lyrics or profanity are rejected. That is exactly the kind of behavioral context the agent needs before calling.

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?

Despite its length, it is clearly sectioned with headers (LANGUAGE, HOW TO WRITE THE LYRICS) and front-loads the core action and timing before the details. The length is justified by the need to explain lyric-writing requirements, though a sentence or two of the duration list could be tightened.

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 job-queueing tool with no output schema, the description covers what is returned (a page link with two versions), how long it takes, how language routing works, and what causes rejection. Nothing an agent needs in order to call this correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description still adds real meaning: it explains that `language` is an ISO code checked against the lyrics and that it determines the hosting site (ru -> opensoundbox.ru), and it explains how `duration_seconds` maps to required lyric length and structure. It also clarifies that sound_description is required when style=custom.

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 ('Queues a song with real vocals to YOUR finished lyrics') and describes what it returns ('a link to its page with two versions to choose from') plus timing (15-60 seconds). An agent can distinguish this from a status-check tool like song_status just from the phrase 'immediately returns a link'.

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?

Gives extensive usage guidance: language selection rules, which site hosts which language, how to structure lyrics per target duration, originality and profanity constraints, and what the style/voice/description controls. It does not explicitly name a follow-up like song_status or state when not to use this tool, so it falls just 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.

All OpenSoundBox — AI song generator 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?