Skip to main content
Glama

Doseedo Film Score: spot a video, play your score on AI instruments, mix it to picture

Render a whole score

doseedo_render_score

FILM SCORING, orchestral arrangement, background music, a song or an instrumental YOU wrote: a WHOLE ARRANGEMENT in one call (a film cue, a string quartet, a big-band chart): every part played by its doseedo instrument, one stem per part from bar 1 at your tempo, plus a summed mix. Input ONE of: parts[] ({name, instrument, timbre_preset?, lora_id?, players?, notes[]} — doseedo_instruments calls), midi_url (multi-track SMF), or musicxml_url (notation played as marked, at concert pitch; what isn't: prepared.score.warnings). A file's parts are matched by name, then GM program; name any part with instruments {"": {instrument, timbre_preset?, players?}}. A chord on a one-line instrument is split into voices (one stem each). ★ SECTIONS: an instrument is ONE player; give a part players: N (2–8) and its line is played by N different players (each its own performance), summed into ONE section stem — that is how you write an orchestra: violins I / violins II / violas / cellos / basses as five parts with players 6 / 6 / 4 / 4 / 3, horns 2–4 in unison, a woodwind or brass line doubled; leave players out for a solo. The WHOLE orchestra in one call: ≤ 32 lines and ≤ 96 player rows (players: N = N rows), plain, sampled and World / LoRA instruments together (~1 min groups), ≤ 600 s. Synth / electronic parts and drums where every hit must land (drum_engine:"oneshot"): doseedo_render_midi. Timing: bpm and/or tempo_map ([{beat, bpm}]; doseedo_tempo_map lands film hits on downbeats). Result: parts[{name, instrument, url, fit, timbre, lora, players}] — fit.verdict / coverage = did it PLAY its notes (a failed part is re-rolled once; fit.rolls.missed = a roll not played as one), lora.applied = its adapter played — plus mix_url. Next: doseedo_mix {from_job}, then doseedo_session_from_stems {from_job, mix_job}. Async: job_id → doseedo_wait_task (~1–4 min). 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

NameRequiredDescriptionDefault
bpmNoTempo of the parts (10–400). Required with parts[] unless tempo_map is given; on a file it sets the speed and keeps the score's fermatas / rit. / tempo changes.
mixNoAlso bounce a summed mix of the stems (default true).
seedNoRandom seed (reuse to re-render close to the same performance).
tuneNoLight intonation on every winds / brass / strings part (default true): held, clearly pitched notes the model rendered 15–85 cents off are moved toward their written pitch, to a small natural residual — attacks, vibrato and fast notes as played. Receipt: parts[].tune. false = every part as rendered (or parts[].tune false for one).
partsNoThe parts you wrote: [{name?, instrument, timbre_preset?, lora_id?, players?, notes:[{pitch, start_beats, duration_beats, velocity?}], dynamics?}] — beats from bar 1, concert pitch. instrument/timbre_preset = a doseedo_instruments call. players = how many play the line: 1 (default) a soloist, 2–8 a SECTION (e.g. Violins I players 6).
vaefixNoVAE spectral corrector on every winds / brass / strings part (default true): the decoder's low-mid fog under each instrument's register is trimmed, mic hiss removed only where present. Receipt: parts[].vaefix. false = every decode as rendered (or parts[].vaefix false for one).
midi_urlNoAlternative to parts: a multi-track Standard MIDI File (≤ 2 MiB) — a doseedo result link or a public https URL. Channel 10 = drums: the kit, or the one percussion instrument a part is named for (Bass Drum, Cymbals, Bass Drum & Cymbals, Triangle…).
score_urlNoAlternative to parts: a score file URL — MIDI or MusicXML, told apart by its content.
tempo_mapNoTempo changes [{beat, bpm}] (first point at beat 0). Overrides a file's own tempo.
instrumentsNoName the instrument for any part: {"Violin I": {"instrument": "violin", "players": 6}, "2": {"instrument": "acoustic_guitar", "timbre_preset": "koto:preset1"}} — key = the part name or its 0-based index; players makes a MIDI / MusicXML part a section. Wins over the name/program match.
musicxml_urlNoAlternative to parts: a MusicXML score (.musicxml / .xml / .mxl, ≤ 8 MiB) exported from Dorico, Sibelius, Finale, MuseScore, or written by you.
time_signatureNoMeter, e.g. "4/4" (default, or the file's).
idempotency_keyNoOptional. 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_secondsNoRender length (default: the last note + 2 s; ≤ 600).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses async job behavior, expected wait time (1–4 min), cancellation/refund rules, orchestral limits (≤32 lines, ≤96 player rows, ≤600 s), one automatic re-roll for failed parts, and output fields for fit/coverage/tuning. These are operationally important facts not captured by readOnly/openWorld/destructive hints.

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 purpose is front-loaded, but the description is extremely dense, using all-caps phrases, parentheticals, symbols, and repeated references to doseedo_instruments that make it harder to parse. Much of the length is justified for a 14-parameter render tool, but the delivery is not tightly concise.

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 complex, 14-parameter async rendering tool with no output schema, the description is highly complete: it explains input modes, orchestration/section semantics, timing, output fields (url, fit, mix_url), next steps, wait behavior, and cancellation consequences. An agent has enough context to invoke and follow up correctly.

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 already 100%, so the schema carries the basic parameter meanings. The description adds useful semantics beyond the schema: file parts are matched by name then GM program, instruments{} can override by part name/index, and players converts a line into a section stem.

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 description states a specific verb and resource: rendering a WHOLE ARRANGEMENT as stems plus mix from parts[], MIDI, or MusicXML. It distinguishes this from doseedo_render_midi by reserving synth/electronic parts and tightly timed drums for that sibling, so an agent can select it without opening schemas.

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?

It explicitly names the alternative doseedo_render_midi and the condition that selects it: synth/electronic parts and drums where every hit must land. It also states the three valid input modes and gives concrete examples (film cue, string quartet, big-band chart), leaving little to inference.

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