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

Split a film's soundtrack (dialogue / music / effects)

doseedo_split_soundtrack

SPLIT A FILM'S SOUNDTRACK (dialogue / music / effects — "DME" — separation): the film's own audio into three stems that sum back to it, plus a report of what it holds: whether there is music already, where it plays (spans in seconds) and how much of the film it covers, where the dialogue is (cleaner than VAD on the full mix: a song's singer stays in the music stem), each part's level, and how far the music sits under the lines. Use it before scoring a film that already has music (soundtrack.stems.music.present): to REPLACE that music, lay the dialogue and effects stems under your score with doseedo_score_to_picture (production_audio:"drop", tracks role "dialogue" / "effects"); to REMIX or RE-ORCHESTRATE it, the music stem goes to doseedo_separate_stems / doseedo_transcribe / doseedo_analyze_song; to KEEP it, score where the report shows no music. Input: video_key (the upload doseedo_spot_video read) or video_url; audio_key / audio_url for a soundtrack already on its own. One reel per call (≤ 30 min). The split is good, not perfect: the dialogue comes out clean, while some of the old music (its percussion most) reads as effects — about −10 dB of it stays in the dialogue + effects bed, which the new score masks. Async: job_id → doseedo_wait_task (about a third of the soundtrack's length: a 3-min scene ≈ 1 min, a 20-min reel ≈ 6 min). Cancel: the plane has no stop for a running split — 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

Name	Required	Description
`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>.
`audio_key`	No	An ingest key of the soundtrack on its own (WAV/FLAC/MP3/M4A), instead of the film.
`audio_url`	No	https URL of the soundtrack on its own, instead of the film.
`video_key`	No	R2 ingest key of the film (the same upload doseedo_spot_video read; starts with "ingest/").
`video_url`	No	https URL of the film, as an alternative to video_key (fetched through the URL up to 256 MB; upload a bigger film).
`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.

Schema Changelog

Changes observed during successful MCP inspections.

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.1/5.0

Behavior3/5

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

Annotations only declare the generic profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds substantially beyond that: async job_id → doseedo_wait_task, a runtime estimate of roughly one third of soundtrack length, and the cancel/refund rule that a running split cannot be stopped and its credits are spent. The one real gap is that it never says the call spends credits up front or what happens to the returned job when the run fails — but the cancellation and refund semantics it does disclose are the kind of operational detail annotations cannot carry.

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 purpose is front-loaded in the first clause and every subsequent block carries load-bearing content: routing branches, quality caveat, async timing, cancel policy. It is dense and parenthesis-heavy (nested quotes, em-dashes, colon chains) enough that a reader has to work, but nothing is filler and no sentence could be dropped without losing a real decision input.

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 carries the return-value burden and does it well: it enumerates the report contents (music present, spans in seconds, coverage, dialogue locations, per-part levels, music-under-dialogue depth). The quality caveat (dialogue clean, some percussion bleeding into effects at about −10 dB) is exactly the kind of expectation-setting a caller needs. It stops short of describing the job object fields a caller must poll, which keeps it off a 5.

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 coverage is 100%, so all six parameters are already documented, and the description mostly restates them (video_key from doseedo_spot_video, key-or-URL alternatives). It does add one constraint absent from the schema — one reel per call, ≤ 30 min — which justifies staying at the baseline rather than falling below it.

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 ("split a film's soundtrack") plus the exact output shape: three DME stems that sum back to the source, plus a report. It distinguishes itself from the sibling doseedo_separate_stems by scope (whole film soundtrack vs. music-only separation), so an agent can pick between them 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 an explicit trigger ("use it before scoring a film that already has music") and then three named branches — REPLACE via doseedo_score_to_picture with production_audio:"drop", REMIX/RE-ORCHESTRATE via doseedo_separate_stems / doseedo_transcribe / doseedo_analyze_song, KEEP by scoring where the report shows no music. It also routes the async handoff to doseedo_wait_task and the cancel question to the absence of a stop call, which is exactly the when/when-not guidance the dimension asks for.

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?