Skip to main content
Glama

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

Cut cues from public-domain scores

doseedo_supervise_cues

MUSIC SUPERVISION, for a film whose direction is classical or orchestral: instead of writing every note, each cue is CUT FROM A REAL PUBLIC-DOMAIN SCORE (~1,000 orchestral pieces, Baroque to late Romantic, free to use in a film — no rights holds, no ShareAlike). The search fits each cue: its length to the frame (a passage bent ≤ ~17 % in tempo, cut on a bar line where it must), the cue sheet's turns on the score's own section changes, its hits on real accents, its mode and meter, its level over time (a quiet cue thins a tutti's doublings; the loudest moment lands on the source's own rise), and cues of one piece play fresh bars. Input: spot_job (the doseedo_spot_video job id — spotter "model" gives each second its level) or cue_sheet; cues (ids, default every score cue); direction {era: ["Baroque"|"Classical"|"Romantic"…], genre, composer: ["Antonín Dvořák"…], mode: major|minor}; prefer {cue: file} = take that cue from an alternative an earlier answer listed. Async: job_id → doseedo_wait_task (~5–60 s; a bad direction, cue or prefer fails at once), CPU, no credits. Result per cue: source {composer, title, licence, credit — the line a CC BY edition asks for}, edit (bars, stretch, cuts), render {score_url, instruments, name} = the doseedo_render_score call that plays it (pass it as is; change an instrument by editing instruments), mix_lufs_offset_db (master the cue at the delivery loudness plus this: doseedo_mix target_lufs), alternatives [{composer, title, file, cost}]. Cancel: the plane has no stop for a running catalogue search — 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "doseedo_supervise_cues"
  }
}

Input Schema

NameRequiredDescriptionDefault
cuesNoOnly these cue ids (default: every score cue, ≤ 40).
nameNoOptional: 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>.
preferNo{cue id: catalogue file}: cut that cue from this piece (a file an earlier answer listed under alternatives).
spot_jobNoThe doseedo_spot_video job id (job_…): its cue sheet is read for you (MCP tool only; the jobs API takes cue_sheet).
cue_sheetNoAlternative to spot_job: a cue sheet {video: {duration}, cues: [{id, kind?: "score", start_s, end_s, suggested_bpm?, turns?: [{time_s}], hits?: [{time_s}], dynamics?: [{at_s, mark}]}], cue_model?: {level_db_per_s}} — doseedo_spot_video's, or your own cue plan in its shape.
directionNoSteer the choice: era / genre / composer as a name or a list of names (the catalogue's own, e.g. era "Romantic", composer "Pyotr Ilyich Tchaikovsky"), mode "major" | "minor" for every cue.
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. Added

TDQS

A4.1/5.0
Behavior3/5

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

Strong beyond-annotation content: async job_id → doseedo_wait_task with ~5-60 s latency, fails fast on a bad direction/cue/prefer, CPU-only, no credits, and unusually honest cancellation semantics ('no stop for a running catalogue search — it runs to completion (credits spent), the job ends as canceled and its output is discarded', with only queued jobs refunded). One tension worth noting: annotations say idempotentHint=false while idempotency_key makes retries deduplicating — the description never reconciles this, and no rate/credit cost is given for a successful run. These are real disclosures, but the mixed signals keep it at 3.

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?

Content is high-value and front-loaded — what it does, then the fit criteria, then inputs, then async/result/cancel — but the whole body is essentially one paragraph of chained parentheticals ('~1,000 orchestral pieces … no ShareAlike', 'a passage bent ≤ ~17 % in tempo, cut on a bar line where it must'), which is hard to scan under time pressure. It is dense rather than wasteful, but the lack of sentence breaks or ordering costs it.

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?

No output schema exists, and the description compensates fully by enumerating per-cue returns: source {composer, title, licence, credit line}, edit (bars, stretch, cuts), render {score_url, instruments, name} to hand to doseedo_render_score, mix_lufs_offset_db to feed doseedo_mix target_lufs, and alternatives. Combined with the async handoff and failure behavior, an agent has everything needed to call, wait, and act on results.

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 baseline is 3, but the description adds relationship meaning the schema cannot: spot_job is a doseedo_spot_video job whose cue sheet is 'read for you', prefer maps a cue to a catalogue file 'an earlier answer listed under alternatives' (a cross-call dependency), and cues defaults to every score cue. It omits the name and idempotency_key parameters, but those are fully self-documented in the schema.

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 — cues are 'CUT FROM A REAL PUBLIC-DOMAIN SCORE (~1,000 orchestral pieces, Baroque to late Romantic)' rather than composed note by note. That framing makes it unmistakably distinct from composition siblings like doseedo_score_to_picture or doseedo_render_score, and the opening 'MUSIC SUPERVISION, for a film whose direction is classical or orchestral' scopes the domain immediately.

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 a clear positive condition ('for a film whose direction is classical or orchestral: instead of writing every note') and states prerequisites: either a spot_job from doseedo_spot_video or an explicit cue_sheet, plus the direction/prefer levers. It does not, however, explicitly name the sibling to use instead when the film is not classical/orchestral, leaving that routing 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