midifier converts audio songs into multi-track General MIDI files, accessible via three MCP tools:
transcribe_audio: Submit a publicly reachable audio URL to start a transcription job. Returns a job ID for tracking progress.
transcription_status: Poll a job by ID to check its current state, queue position, and estimated wait time.
transcription_settings: View the server's configuration (e.g., model size, max duration, concurrency limits) and current workload/busyness.
All tools support an optional api_key argument for authentication when the server is secured.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@midifier Transcribe the audio file 'song.mp3' to MIDI tracks."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Turns a song into a multi-track General MIDI file. It works out which instruments are playing, transcribes each one, and names and assigns the tracks, so the result can be practised against in kinesthesia.
Available as a REST API and as MCP tools.
uv sync --extra dev
uv run python -m midifier # API on :8000, docs at /docs
uv run python -m midifier mcp # MCP serverNo configuration is needed to start; results are written to ./data.
Related MCP server: Claud-Ear
# start a transcription
curl -F 'file=@song.mp3' http://localhost:8000/v1/jobs
# {"id":"...","state":"queued"}
# poll it
curl http://localhost:8000/v1/jobs/<id>One job runs at a time, and each takes roughly three times the length of the song, so jobs are
polled rather than waited on. While a job waits, GET /v1/jobs/<id> reports queue_ahead and
eta_seconds, and GET /v1/queue reports how busy the service is. The estimate is measured from
completed jobs rather than configured, so it reflects whatever hardware this runs on.
The OpenAPI schema is at /openapi.json.
The service holds only the hash of an API key, so reading the deployed secret does not let anyone call it. Generate a pair:
uv run python -m midifier keygenDeploy the hash as MIDIFIER_API_KEY_HASH, and give the key to callers. With no hash
configured the service is open, which suits local use.
Callers present the key one of three ways, whichever their client makes easiest:
caller | how |
REST |
|
MCP over HTTP |
|
MCP over stdio | the |
The MCP server is served from the same app at /mcp, so one URL and one key cover both
surfaces, and a job started over MCP is visible over REST.
Every setting is an environment variable prefixed MIDIFIER_. See
.env.example for the full list. The ones that matter:
variable | default | |
| unset | when set, callers must present the key |
|
|
|
| — | with the other |
|
|
|
| — | needed to download the transcription weights |
|
| longest song accepted |
|
| transcriptions run at a time |
|
| length of each decoded segment |
|
| tries per segment before a job fails |
uv run pre-commit run --all-files # everything CI runs
uv run pytest --cov # tests, 80% gateConventions and the reasoning behind the pipeline are in AGENTS.md.
MIT. The transcription weights it downloads are licensed separately and are not redistributed here.
Start transcribing a song into a multi-track MIDI file.
Returns a job id to poll with transcription_status. Transcription runs at
roughly three times the length of the song, and one job runs at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Publicly reachable URL of the audio to transcribe. | |
| api_key | No | API key. Not needed when the request already carried it as a header. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool initiates an async job, returns a job ID, and runs with a 3x time multiplier and single-job concurrency. These details go beyond the minimal, though it does not specify what happens when a job is already running (error vs. queue) or authorization requirements beyond the optional API key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: the first states the core function, the second explains the return value and how to use it with a companion tool, and the third provides timing and concurrency constraints. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the tool is relatively simple, the description covers the key aspects: purpose, return type, timing, and concurrency. However, it lacks details on error handling when a job is already running and does not mention any input format restrictions. Still, it is fairly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented in the schema. The tool description does not add additional meaning to the parameters; it merely mentions 'song' while the schema says 'audio'. Hence, the description adds no extra value beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Start transcribing a song into a multi-track MIDI file.' This is a specific verb+resource combination. Although it mentions 'song' while the schema says 'audio', the purpose is unambiguous and no sibling tools exist to confuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool by stating the asynchronous nature ('Returns a job id to poll'), the approximate runtime ('three times the length of the song'), and concurrency limit ('one job runs at a time'). It does not explicitly mention alternatives since no sibling tools exist, but the guidance is clear and useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0transcribe_audioOnly one tool exists, so there is no ambiguity between tools.
With a single tool, naming consistency is trivially maintained.
The server has only one tool, which is insufficient for the stated purpose. It references a polling tool that is not provided, making the interface incomplete.
The tool only starts a transcription job but provides no way to check status or retrieve results, leaving agents with a dead end. The domain requires at least a status-checking tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Producer/Riffusion AI music generation
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
MCP server for Suno AI music generation, lyrics, and covers
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matheusfillipe/midifier'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
