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

Spot a video → cue sheet

doseedo_spot_video

SPOT A FILM: a video in, the music editor's cue sheet out — the first step of scoring to picture. Scene detection on EVERY frame, and it listens to the soundtrack (CPU, no credits): hard cuts frame-exact (dark, low-contrast footage included), fades, flashes and visual impacts; each shot's brightness, colour, warmth, contrast, motion and mood, with a keyframe JPEG per shot so you can SEE what it shows; SCENES — where the picture moves to a new place, at a cut or with none (a camera move, a dissolve) — each with its start, how it arrives, how fast the camera travels (pace) and a 640-px frame; and a storyboard: the whole film on one JPEG, a frame every few seconds; where dialogue is (Silero VAD) and loud audio hits; INTENSITY — the picture's energy (motion, cutting, camera, the sound) as sections [{start_s, end_s, level, rel: low | medium | high | peak}], and each scene's own: where the music steps up, settles and peaks; then cues placed where the picture wants music and the dialogue lets it (1M1, 1M2 …: start/end SMPTE timecode, emotion, energy, tension arc, hit points ranked by strength, a suggested bpm that lands them, and tempo_map_input — pass it to doseedo_tempo_map as is). It sees light, movement and editing, not meaning: read the scene frames and the storyboard for what each scene is about. Input: video_key (doseedo_get_upload_url accepts mp4/mov/m4v/webm/mkv) or video_url (public https), ≤ 2 GB and ≤ 3 h. Optional start_timecode (the first frame's, e.g. 01:00:00:00; default the file's own), coverage (0.05–0.98, default 0.55: how much of the film gets music), reel (cue ids M), keyframes (0–60), spotter. Async: job_id → doseedo_wait_task (~1 min for a 10-min 1080p reel). Next: doseedo_tempo_map per cue → write the notes → doseedo_render_score → doseedo_mix → doseedo_score_to_picture. Cancel: the plane has no stop for a running spotting pass — 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>.
`reel`	No	Reel number for the cue ids (default 1 → 1M1, 1M2 …).
`spotter`	No	Who places the cues. "rules" (default): light, motion and editing, weighted by hand, at coverage. "model": a cue model trained on 200 human-scored films. It places the cues where a composer would, and gives each cue its tempo (suggested_bpm), dynamics marks (dynamics: pp–ff every 8 s), turns (where it comes in full or steps up or down) and hits. Its tempo_map_input lands the hits on a beat and the turns on a bar line. Without coverage it decides how much of the film gets music; cue_sheet.cue_model says what it decided.
`coverage`	No	How much of the film gets music (default 0.55). Raise it for wall-to-wall scoring (a trailer, an animation), lower it for a dialogue drama.
`keyframes`	No	How many shots get a keyframe JPEG (default 24; the longest shots first). 0 = no images at all (no scene frames, no storyboard).
`video_key`	No	R2 ingest key of the uploaded video (doseedo_get_upload_url with the file name, e.g. reel1.mp4; starts with "ingest/").
`video_url`	No	https URL of the video, as an alternative to video_key (a public file URL, fetched directly; ≤ 2 GB).
`cut_threshold`	No	Scene-change threshold at full contrast (default 0.3). Lower finds softer cuts, higher only the hardest.
`start_timecode`	No	SMPTE timecode of the first frame, HH:MM:SS:FF (";" before the frames = drop-frame at 29.97/59.94). Default: the file's embedded timecode, else 00:00:00:00.
`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 6, 2026

addedInput schema / properties / spotter

Added value: +{
+  "description": "Who places the cues. \"rules\" (default): light, motion and editing, weighted by hand, at coverage. \"model\": a cue model trained on 200 human-scored films. It places the cues where a composer would, and gives each cue its tempo (suggested_bpm), dynamics marks (dynamics: pp–ff every 8 s), turns (where it comes in full or steps up or down) and hits. Its tempo_map_input lands the hits on a beat and the turns on a bar line. Without coverage it decides how much of the film gets music; cue_sheet.cue_model says what it decided.",
+  "enum": [
+    "rules",
+    "model"
+  ],
+  "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/5.0

Behavior5/5

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

Annotations only declare readOnly=false, openWorld=true, non-idempotent and non-destructive; the description goes far beyond that with the operational facts an agent needs: it is async (job_id → doseedo_wait_task), ~1 min for a 10-min 1080p reel, CPU-based with no credits for the analysis itself, hard input limits (≤ 2 GB, ≤ 3 h), and the credit consequences. The cancellation clause is unusually candid — a running spotting pass cannot be stopped, credits are spent, output is discarded, and only jobs still queued are refunded — which directly warns against a destructive-cost mistake. It even discloses a limitation ('sees light, movement and editing, not meaning') that shapes how the caller must interpret results.

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?

Front-loaded correctly — the film-in/cue-sheet-out framing and 'first step of scoring to picture' land in the first clause — but the body is one very long, semi-colon-chained paragraph with no headings or line breaks. Output enumeration, input constraints and the cancel/refund policy are all run together, so an agent scanning for the cost warning must read past dense shot-detection detail. Nearly every clause carries information, but the lack of structure makes it harder to use than its content warrants.

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?

There is no output schema and no annotations covering cost, so the description must define the return payload itself — and it does, in detail: per-shot brightness/colour/motion/mood with keyframe JPEGs, scenes with arrival and pace, a storyboard, Silero VAD dialogue positions, intensity sections with rel levels, and cues with SMPTE timecodes, emotion, energy, tension arc, ranked hit points, suggested bpm and tempo_map_input. For a 10-parameter, credit-spending async tool it also states inputs, limits, the handoff chain, and the failure/refund semantics. Nothing an agent needs to call it correctly or interpret its result is missing.

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 baseline; the description nonetheless adds meaning beyond it, notably that video_key comes from doseedo_get_upload_url and accepts mp4/mov/m4v/webm/mkv (not stated in the schema), that tempo_map_input should be passed to doseedo_tempo_map 'as is', and that keyframes=0 disables scene frames and the storyboard as well. The prose restates defaults for coverage, reel and start_timecode that the schema already documents, which caps it below 5.

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 concrete verb+resource+artifact: 'a video in, the music editor's cue sheet out', and immediately positions it as 'the first step of scoring to picture'. It explicitly distinguishes itself from downstream siblings by naming doseedo_tempo_map, doseedo_render_score, doseedo_mix and doseedo_score_to_picture, and it states the scope boundary ('sees light, movement and editing, not meaning'), which no other sibling claims.

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 clear usage context and an explicit pipeline: spot → doseedo_tempo_map per cue → write notes → render_score → mix → score_to_picture, plus the async handoff to doseedo_wait_task. It also says what 'spotter: model' is for versus 'rules' and when to raise/lower coverage. It never names a condition under which an agent should NOT use this tool (e.g. audio-only material belongs to doseedo_analyze_song or doseedo_split_soundtrack), so it stops short of full when/when-not routing.

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?