Skip to main content
Glama

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

Prompt-only AI sketch (doseedo does not compose — you write the piece)

doseedo_generate_music

NOT A COMPOSER: doseedo plays music, it does not write it — YOU write the piece. Background music for a video or a brand film, an instrumental, a theme, a song: compose every part yourself as notes ([{pitch, start_beats, duration_beats, velocity}], beats from bar 1 — melody, harmony, bass, in the key and at the tempo you choose), then play them: doseedo_render_score {parts} for several instruments (one stem each, then doseedo_mix) or doseedo_render_midi for one; doseedo_instruments lists the players and their ranges; the steps: doseedo_recipes name="compose-piece" (to picture: "score-a-film"; one part in a session's key: "compose-part"). THIS tool is text to music from a PROMPT alone (optionally lyrics) with NO notes behind it: the instrument model then has nothing to play, and a take is often near-silent, a drone or clicks. Nothing in it is controlled — no key control (a key in the prompt is not honoured), no MIDI input, bpm/time_signature only tag the caption. Use it only when the user explicitly asks for a prompt-only AI sketch, listen before handing a take over, and never deliver one as the music. Async: job_id → doseedo_wait_task (typically 1–3 min) → audio URLs (pre-signed: curl -OJ , no auth header, valid 24 h — see expires_at). 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
bpmNoOptional tempo HINT in BPM, written into the caption (default 120). Not enforced — the output tempo can drift from it.
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>.
seedNoOptional random seed for reproducibility.
lyricsNoOptional lyrics to sing, ≤ 16000 characters. Omit for instrumental.
promptYesStyle/mood/instrumentation prompt, e.g. "warm jazz trio, brushed drums, late-night ballad". ≤ 16000 characters (a longer one is cut at a word boundary, with a warning).
time_signatureNoOptional meter HINT written into the caption, e.g. "4/4", "3/4". Not enforced.
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_secondsNoTarget length in seconds (e.g. 30–120). Omit for the model default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / lyrics / description
      Previous value: -"Optional lyrics to sing. Omit for instrumental."New value: +"Optional lyrics to sing, ≤ 16000 characters. Omit for instrumental."
    • addedInput schema / properties / lyrics / maxLength
      Added value: +16000
    • changedInput schema / properties / prompt / description
      Previous value: -"Style/mood/instrumentation prompt, e.g. \"warm jazz trio, brushed drums, late-night ballad\"."New value: +"Style/mood/instrumentation prompt, e.g. \"warm jazz trio, brushed drums, late-night ballad\". ≤ 16000 characters (a longer one is cut at a word boundary, with a warning)."
    • addedInput schema / properties / prompt / maxLength
      Added value: +16000
  2. Changed1 schema field changed
    • 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"
      +}
  3. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the safety story is partly covered. The description goes well beyond them with the async lifecycle (job_id → wait_task, 1–3 min), pre-signed URL handling and 24 h expiry, credit/refund semantics on cancel, and the honest warning that output can be near-silent, a drone, or clicks — rich behavioral context that the annotations do not 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?

Front-loaded with the decisive 'NOT A COMPOSER' framing, then workflow, then the caveat and async mechanics — a sensible order. It is dense and longer than typical, but nearly every clause carries routing or behavioral information; minor tightening of the instrument/recipe enumeration would help.

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?

No output schema exists, and the description compensates by explaining what comes back (audio URLs, expires_at, file naming driven by `name`) and how to cancel. Combined with 100% schema coverage and annotation-backed safety, an agent has what it needs; only the quality-variance caveat is left qualitative rather than quantified.

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 description coverage is 100%, so all eight parameters are already documented, setting the baseline at 3. The description adds some meaning the schema does not — that a key stated in the prompt is not honoured and that bpm/time_signature only tag the caption — but it does not walk through the remaining parameters (seed, duration_seconds, idempotency_key).

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 — text-to-music generation from a prompt alone, with no note data behind it — and explicitly carves out what it is not (a composer). It names the sibling tools (doseedo_render_score, doseedo_render_midi, doseedo_instruments, doseedo_recipes) it should be chosen over, so an agent can route correctly without opening any 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?

Explicit when-to-use ('only when the user explicitly asks for a prompt-only AI sketch'), explicit alternatives ('YOU write the piece' via score/midi paths, recipes compose-piece / score-a-film / compose-part), plus a hard caution to listen before delivery and never ship a take as the music. Both the positive and negative routing conditions are stated.

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