Doseedo: Film Scoring, AI Instruments, Sound Effects & Stems

Cover a stem on another instrument

doseedo_cover_stem

TIMBRE TRANSFER (an instrument swap) from a recording: hum or whistle a melody, play it on a kazoo, take a guitar line — and get it back played by a cello, a trumpet, a koto (any doseedo_instruments call). Re-play ONE recorded part — a separated stem, a solo, a region of the user's session — on another instrument, straight from the audio: the recording's FSQ codes carry its structure into a take generated from noise, and the sound is the instrument's (caption + timbre_preset) — the FSQ + timbre combination the cond5 model was trained on (served on its turbo graft). No MIDI by default (midi:true adds the server's own pitch roll of the recording); fidelity > 0 also keeps that much of the recording's own latents (closer, but its sound leaks back in). For the exact notes, transcribe and doseedo_render_midi; a whole mix → doseedo_cover_song. result.recipe says what reached the model (fsq, timbre, cns). Async: job_id → doseedo_wait_task (~30–90 s) → takes[{url}] (pre-signed: curl -OJ, no auth header, 24 h). Cancel: a render that has not reached the GPU yet is stopped and its credits refunded; one already rendering finishes on the GPU (its credits are spent), the job ends as canceled and the output is discarded.

Input Schema

Name	Required	Description
`bpm`	No	The recording's tempo (a hint; default 120).
`fsq`	No	false = leave the recording's FSQ codes out: the take follows the server's note roll (needs midi: true) on the instrument's sound, with none of the source's phrasing or articulation carried over — for a line whose phrasing doesn't suit the new instrument (a sung vocal on a sax). Default true. recipe.fsq says which ran.
`midi`	No	true = the server also transcribes the recording's notes into a roll that drives the MIDI hooks beside the FSQ codes — closer notes, a little slower (LatentPitch on audio; vaescriptor on a latent_key; a drum part — either route — gets its hits from vaescriptor_drums). recipe.midi_source names it. Default false: the codes alone.
`name`	No	Optional: a name for this job's files, e.g. "rainy-loop-3". Every file it returns downloads as <name>_<part>.<ext> (rainy-loop-3_Celesta.wav, rainy-loop-3_rough-mix.wav; one take: rainy-loop-3.wav), so the user can find them. Give each job its own name (a second take: "rainy-loop-3b"). Default: doseedo-<last 6 characters of the job id>.
`seed`	No	Optional random seed for reproducibility.
`takes`	No	How many takes, 1–4 (default: the server's best-of-N).
`lyrics`	No	A SINGER's cover (instrument "voice" or "choir" — doseedo_instruments rows with sings:true): the words to sing, a line per phrase, in the order the recording sings them — e.g. the recording's own words transcribed. The take sings them in the recording's phrasing (its FSQ codes). ≤2000 chars. Without it a singer sings no words. Any other instrument: an error.
`fidelity`	No	How much of the recording's own latents the take keeps, 0–0.6 (cover noise strength over the source). Default 0: structure from its FSQ codes only, the sound all the instrument's.
`audio_key`	No	R2 ingest key of an uploaded audio file (from doseedo_get_upload_url / POST /api/upload/r2/ingest-url; starts with "ingest/"). Provide this, audio_url, or latent_key.
`audio_url`	No	https URL of the audio, as an alternative to audio_key: a doseedo result URL exactly as a job returned it (a stem, a take, a bounce), or any public URL. The gateway fetches it (≤256 MB) into your account's ingest storage before the job starts. Pass audio_key OR audio_url.
`instrument`	Yes	REQUIRED. The instrument that plays it — call.instrument from doseedo_instruments (with its call.timbre_preset where it has one).
`latent_key`	No	Instead of the audio: the recording already VAE-encoded (ACE-Step 1.5 VAE, 48 kHz stereo → [T, 64] at 25 Hz, the latent mean) as a 64-channel 25 Hz float WAV `*.latent.wav`, uploaded like audio (POST /api/jobs/uploads). The server skips its encode. Dø Desktop sends this when encoding on the Mac lands sooner than uploading the audio.
`timbre_preset`	No	A named timbre preset (the catalog's preset ids, e.g. "cello:preset1"). Omit for the instrument default.
`idempotency_key`	No	Optional. Any unique string for THIS request (e.g. a UUID). Re-sending the same call with the same key after a timeout returns the same job instead of starting a second one.
`duration_seconds`	Yes	REQUIRED. The recording's length in seconds (0.5–600): the take is this long.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / lyrics

Added value: +{
+  "description": "A SINGER's cover (instrument \"voice\" or \"choir\" — doseedo_instruments rows with sings:true): the words to sing, a line per phrase, in the order the recording sings them — e.g. the recording's own words transcribed. The take sings them in the recording's phrasing (its FSQ codes). ≤2000 chars. Without it a singer sings no words. Any other instrument: an error.",
+  "type": "string"
+}

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / name

Added value: +{
+  "description": "Optional: a name for this job's files, e.g. \"rainy-loop-3\". Every file it returns downloads as <name>_<part>.<ext> (rainy-loop-3_Celesta.wav, rainy-loop-3_rough-mix.wav; one take: rainy-loop-3.wav), so the user can find them. Give each job its own name (a second take: \"rainy-loop-3b\"). Default: doseedo-<last 6 characters of the job id>.",
+  "maxLength": 80,
+  "type": "string"
+}

First observedNov 2, 2026

TDQS

A4/5.0

Behavior3/5

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

Goes well beyond the annotations: ~30–90 s async latency, pre-signed 24 h output URLs requiring no auth header, GPU-reached jobs still spending credits on cancel, and what result.recipe reports. However the description stresses a reusable idempotency_key returning the same job, which sits in tension with idempotentHint=false (the annotation describes default behaviour, the description describes an opt-in override) – a mild inconsistency an agent must resolve rather than a reversal of the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose well, but the paragraph is dense with model plumbing (cond5, turbo graft, LatentPitch, vaescriptor, recipe keys) that most callers cannot act on, and the cancel/refund sentence is very long. The information is accurate but not pruned to what an agent needs before invoking.

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 15-parameter async generation tool with no output schema, the description covers the return path (takes[{url}], pre-signed download), the recipe provenance fields, and cancel semantics, which is close to sufficient. It does not mention cost/credit pricing per take, though the sibling doseedo_quote exists for that.

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

Parameters3/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 in detail. The description mostly restates the schema's own points (midi:true adds a pitch roll, fidelity>0 leaks source sound) with only marginal added tradeoff nuance ("closer, but its sound leaks back in") and the cond5 FSQ+timbre training rationale. Baseline 3 is the right ceiling when the schema does the heavy lifting.

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?

Opens with a specific verb+resource framing ("TIMBRE TRANSFER ... re-play ONE recorded part ... on another instrument") and immediately scopes it against siblings: a whole mix goes to doseedo_cover_song, exact notes go to transcribe + doseedo_render_midi. An agent can distinguish this from every neighbouring tool without opening a 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 explicit routing rules with named alternatives (doseedo_cover_song for a mix, doseedo_render_midi for exact notes, doseedo_instruments to source the instrument) plus the async follow-up chain (job_id → doseedo_wait_task → takes). It also states the cancellation/refund boundary, which tells an agent when cancelling is useful and when it is pointless.

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

All Doseedo: Film Scoring, AI Instruments, Sound Effects & Stems 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?