Skip to main content
Glama

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

by com.doseedo
OverviewDiscussionsAdmin

Stems → a DAW session

doseedo_session_from_stems

Build a native DAW PROJECT from stems: each stem on its own audio track from bar 1, optional MIDI tracks (the written parts) beside them, on your tempo (bpm or tempo_map) — Logic Pro (.logicx) or Ableton Live (.als), zipped. The deliverable after doseedo_render_score (pass from_job: its job_id and the stems, MIDI and tempo come from that job) or after any renders / separations you made (stems: [{name, audio_url}] — result links work as-is). After doseedo_mix add mix_job: each track at that mix's level and pan, the mix as a muted reference track. Async: job_id → doseedo_wait_task (~30–90 s) → file (pre-signed zip, curl -o session.zip , 24 h). Cancel: the plane has no stop for a running session build — it runs to completion (credits spent), the job ends as canceled and its output is discarded. Only a job still queued at the plane is refunded by the plane's own failure refund.

Input Schema

NameRequiredDescriptionDefault
bpmNoProject tempo (default 120).
nameNoProject name.
stemsNo[{name, audio_url | audio_key, gain_db?, pan?, mute?, position_beats?}] — the audio tracks, in order.
targetNoWhich DAW (default logic).
mix_jobNoMCP: a doseedo_mix job_id — every track takes that mix's level and pan, and the mix itself rides along as a muted reference track "Mix (doseedo)".
from_jobNoMCP: a doseedo_render_score job_id — its stems, parts' MIDI and tempo are used (no other input needed).
mixgraphNoA mix document (doseedo_mix → mixgraph): each stem named in it takes its strip's gain_db and pan. The EQ, compression, reverb and rides are not written into the project.
tempo_mapNoTempo changes [{beat, bpm}] for the project.
midi_tracksNoOptional MIDI tracks: [{name, notes:[{pitch, start_beats, duration_beats, velocity?}]}].
time_signatureNoMeter (default 4/4).
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, it discloses async timing (~30–90 s), the pre-signed zip download pattern with curl, 24-hour expiry, cancellation limitations, credit-spend behavior, and refund conditions. It also clarifies that mixgraph EQ, compression, reverb, and rides are not written into the project.

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

Conciseness5/5

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

The description is dense but front-loaded, starting with the core build action and deliverable before moving into input modes, async behavior, and cancellation caveats. Despite its length, every sentence carries operational information relevant to invoking the tool correctly.

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?

Given 11 parameters, nested stem/MIDI objects, no output schema, and asynchronous execution, the description provides the missing operational context: how to use upstream job IDs, what the output is, how to retrieve it, and what cancellation does. Nothing essential for correct invocation appears absent.

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 100%, so the schema already documents all parameters. The description adds useful cross-parameter semantics, especially that from_job supplies stems, MIDI, and tempo without other input, that result links work as-is, and that mix_job causes tracks to inherit level/pan with a muted reference mix.

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 action and deliverable: build a native DAW project from stems, with each stem on its own track, optional MIDI tracks, and target formats Logic Pro or Ableton Live. It distinguishes the tool from sibling creation/import/convert tools by emphasizing stems as the input and a zipped DAW session as the output.

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 upstream alternatives and when to use them: after doseedo_render_score with from_job, after any renders or separations with stems, or after doseedo_mix with mix_job. It also explains the async follow-up flow via doseedo_wait_task, making the intended invocation path clear.

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

All Doseedo Film Score: spot a video, play your score on AI instruments, mix it to picture toolsInspect
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