Skip to main content
Glama

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

Audio to MIDI (transcribe notes)

doseedo_transcribe

AUDIO TO MIDI transcription: a melody, a bass line or a part as notes (pitch, onset/offset seconds, velocity, confidence as JSON — not a MIDI file; for .mid files per stem use doseedo_separate_stems with transcription or doseedo_audio_to_session). Works from an uploaded audio_key or an audio_url — any public https URL, including a result URL from another doseedo job (a generate take, a stem) as it was returned. Async: returns a job_id — poll with doseedo_wait_task (usually ~15–60s). For the KEY / tempo / chords of a whole mix use doseedo_analyze_song instead. Cancel: the plane has no stop for a running transcription — 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
wantNoWhat to return: "notes" (default), "f0" (the continuous pitch contour — frame-rate Hz values, for glides/vibrato/intonation), or both.
chairsNopolyphony="section": register codes per chair, as an alternative to roster.
familyNoOptional instrument family (e.g. "brass", "reeds", "strings") when the exact instrument is unknown.
rosterNopolyphony="section": the chairs on the stem, e.g. "trumpet,trumpet,trombone,tenor_sax". Omit for the family default.
backendNoAdvanced: force a transcription backend. Omit — the server routes by instrument.
strikesNoWith tempo_bpm: also return the harmony_strikes attack grid.
registerNoOptional register hint for the instrument (e.g. "soprano", "tenor", "bass").
audio_keyNoR2 ingest key of an uploaded audio file (from doseedo_get_upload_url / POST /api/upload/r2/ingest-url; starts with "ingest/"). Provide this or audio_url.
audio_urlNohttps URL of the audio to transcribe (alternative to audio_key): any public URL, or a doseedo result URL exactly as a job returned it — no key needed.
polyphonyNoOptional: "solo" (monophonic line), "poly", or "section" (a horn section — see roster/chairs).
tempo_bpmNoOptional known tempo — enables beat-aligned note times.
instrumentNoOptional instrument hint, e.g. "piano", "sax", "vocals", "bass".
beats_per_barNoWith tempo_bpm: beats per bar for the beat-domain times (default 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.8/5.0
Behavior5/5

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

Goes well past the annotations by disclosing the async job_id contract, the polling tool (doseedo_wait_task) and expected ~15–60s duration, plus the cancellation reality: no stop for a running job, credits spent, output discarded, refund only if still queued. That cost/cancellation disclosure is exactly the kind of context 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?

Front-loaded with the core purpose and output shape, then labeled segments ("Async:", "Cancel:") for scanning. The cancellation/refund sentences are a bit verbose and repeat the verb "runs"/"plane" phrasing, but each carries non-obvious operational information.

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?

For a 14-parameter async transcription tool with no output schema, the description still covers what is returned (pitch, onset/offset seconds, velocity, confidence), how to obtain it (poll job_id), how to source audio, and what happens on failure/cancel. Nothing an agent needs to invoke it correctly 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?

With 100% schema coverage the baseline is 3, but the description adds workflow-level meaning the schema only hints at: audio_url may be any public https URL or a doseedo result URL exactly as returned, enabling chaining of generate/stem outputs. The remaining 13 params are left entirely to 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 ("AUDIO TO MIDI transcription") and immediately bounds the output (notes as JSON, not a .mid file). It names the sibling tools that handle the excluded cases (doseedo_separate_stems, doseedo_audio_to_session), so an agent can distinguish it 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?

Explicit routing: melody/bass/part → this tool; per-stem .mid files → doseedo_separate_stems or doseedo_audio_to_session; whole-mix key/tempo/chords → doseedo_analyze_song. It also spells out the two accepted input sources, so the when-to-use decision is fully determined.

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