maliciainc/studiopro8-mcp

An MCP server for Fender Studio Pro 8. It gives an AI assistant — Claude Desktop first, Hermes Desktop as well — the same hands a producer has on a session: transport, tracks, events, notes, the mixer, plug-ins and their parameters, sends and sidechains, automation, buses, bounces; and the same ears: loudness, true peak and spectrum measured from audio the DAW itself rendered.

[!IMPORTANT] Nothing here is claimed without a measurement. A feature counts as verified only when it was done through this server, over stdio, against Studio Pro running a disposable session, and read back a second way; tests with a scripted bridge guard against regressions but never raise what is claimed about the DAW (Engineering contract). What could not be done from a script is listed, with what the server does instead, in Limits.

---

Contents

What it does · Status · A real project, end to end · Install · Clients · Try asking · Safety model · Tools · How it works · Engineering contract · Limits · Configuration · Repository · License

---

What it does

---

Status

Verified on Fender Studio Pro 8.1.2.113407 · Windows 11 x64 · bridge protocol 2.

$ node src/cli.js doctor
✔ Bridge answers             BRIDGE_CONNECTED: protocol 2
· Claude Desktop MCP client  CLIENT_SEEN_ONLY: "local-agent-mode-StudioPro8-MCP"; calls=28; accepted=0; denied=0; DAW replies=0
                             → Call live_song from Claude Desktop while a Session is open
✔ Hermes MCP client          CLIENT_DAW_RESPONSE_VERIFIED: "hermes-desktop"; calls=2; accepted=1; denied=0; DAW replies=1

---

A real project, end to end

A nine-track EDM project of the author’s, opened on a machine without its original plug-ins or samples. Done through the MCP, on the real DAW, with the tools as they were when it was done (the mix step used the earlier live_mix_edm, which rendered the tracks itself; today it measures the stems you export, and that flow has not yet been run on this project):

The mix went through three listening rounds with the musician. The first (levels from peaks, a limiter on the main output) was rejected as a trick that only sounded better; the second, set by loudness alone, missed that an audio track’s render lacks its channel’s plug-ins (the compressors had taken 4–9 dB off the percussion). What each got wrong is built into live_mix_edm: nothing on the main output while mixing, and stems that carry the plug-ins of their channels. The earlier version measured the gain of audio channels’ plug-ins on the meters because its bounces lacked them; the version that reads your exports does not add that estimate, since whether an export carried the plug-ins is a checkbox of the dialog that is not observed.

---

Install

You need Node.js 20+, Fender Studio Pro 8 and loopMIDI with a port named studio-one-mcp (the bridge’s doorbell). The server runs from a checkout, and the client is pointed at that checkout’s src/server.js.

git clone https://github.com/MaliciaInc/StudioPro8-MCP.git
cd StudioPro8-MCP
npm ci
node src/cli.js setup

setup walks through each step and asks before changing anything:

1. Finds your Studio Pro user profile.
2. Installs the MCP Bridge device and the edit-task extension (Extensions/studio-one-mcp.edittasks) into it.
3. Checks the virtual MIDI port.
4. Registers the server with Claude Desktop (names only are shown, never environment values; a copy of the config is kept).
5. Shows the one step you do in Studio Pro: Options → External Devices → Add… → studio-one-mcp → MCP Bridge, Receive From your port, Send To none. Restart Studio Pro first if it was running.
6. Waits for the DAW to answer. On Studio Pro 8.1.2 the bridge answers only while a session is open.

When something does not work:

node src/cli.js doctor        # or: npm run doctor

The doctor checks every link — Node, profile, songs folder, device and extension current, MIDI port, Studio Pro running, bridge answering at protocol 2, the edit tasks loaded, Claude Desktop, Hermes Desktop, whether writing is on and for which song — and says how to fix the first broken one.

---

Clients

Claude Desktop is the primary client. Close it completely (also in the tray), then:

node src/cli.js setup --yes --desktop-config --desktop-closed

setup finds the app’s config (the Microsoft Store build keeps it under %LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude), previews the change, keeps a copy, replaces the file in one step, and refuses if the file changed after the preview. Start the app and ask: “Using StudioPro8-MCP, tell me the name and tempo of the open Session. Don’t change anything.” That calls live_song; once the DAW has answered it, the doctor reports CLIENT_DAW_RESPONSE_VERIFIED (it recognises the chat as claude-ai and the app’s agent mode as local-agent-mode-*). Calls that only arrived are CLIENT_SEEN_ONLY.

Hermes Desktop (Nous Research) is registered on its own, never as part of Claude Desktop’s setup:

node src/cli.js setup --yes --hermes-config

The entry’s key is StudioPro8_MCP — with an underscore. Hermes names tools mcp____ after turning every character outside [A-Za-z0-9_] into _; under a hyphenated key a local model built tool names that did not exist. Restart Hermes and ask it for the open session; the doctor reports CLIENT_DAW_RESPONSE_VERIFIED once the DAW has answered a live_song it called. Hermes connects with the Python SDK’s generic client name, so for that name the server reads the process table once (executable paths and parent ids, never command lines) to tell Hermes Desktop from any other Python client.

Hermes runs a small local model, and asked in plain words it searched the web and the disk for what these tools know, or called names that do not exist. A skill page for it (hermes/skills/studio-pro8-mcp/SKILL.md) says which tool answers what, how a track differs from its mixer channel, how to change a plug-in setting (text, never a raw value), how a plan is previewed, applied and put back, how a copy of a song is approved, and how an export is prepared and checked. It is written to Hermes’ skills folder with its own approval, and a page that is already there is kept next to it:

node src/cli.js setup --yes --hermes-skill

The configuration Hermes needs to work this server well — gpt-oss:20b at a 128k context through Ollama, the server’s entry with its timeout and permissions — with the machine it is tuned for (RTX 4080 SUPER, i7-14700F, 64 GB DDR5), the Ollama tuning (context fixed on the server, flash attention, KV cache q8_0 on the GPU, a 512 MB VRAM margin: 113 tok/s at 128k) and how to apply or undo it, is in hermes/README.md.

The page also tells it how to listen to a mix, review it (alone or with subagents through Hermes’ delegate_task), mix, master, take a sidechain out, work on a copy of a song and open it, arrange a loop and write automation. Driven through Hermes Desktop on the real DAW (the musician’s project, 2026-10-13), it found that the bass already had a sidechain and took a wrong one out, diagnosed the drop by listening to the mix and to the kick, bass and clap alone, dispatched three subagents that reviewed the nine tracks and handed back the measured lines, and mixed the song with live_mix_edm (listen). Where it failed, the failure was fixed in the server rather than in the prompt: a track’s channel is now given by its name, a sidechain can be taken out, read tools that take a channel focus the track they need. What a small model still does: it rounds off or invents figures in its own summaries, and sends calls that depend on each other at the same time. Hermes has its own terminal and file tools: once, refused a copy by the server, it copied the song with a shell command. For music sessions, turn those toolsets off in Hermes.

The doctor has a row for it. With the page, a plain request such as “what tempo does it have”, “put the bass a bit to the right and then back to the centre” or “copy the first eight bars of the kick to the next eight and then undo it” reaches the right tool in a few steps. For a request about audio files Hermes may still analyse them with its own code: name the server (“use the StudioPro8_MCP tools to check whether the sidechain works, with these three audios…”) and it uses studio_sidechain_audio_proof. It can also be asked to remember that rule.

The server is a standard stdio MCP server, so any other client that can start a process could use it; only the two above are verified. Only one client at a time owns the bridge, and only while a tool call is using it: the server takes the mailbox when the first request of a call is about to be written and lets go when the call ends. A server that is killed in the middle of a call leaves its claim behind; the next call clears it only when the process that made it is gone (the claim names it, and a live one is never touched), so one dead server cannot lock the DAW out.

---

Try asking

---

Safety model

• Reading is always on. Stop is always allowed.
• Changing a session is off by default. Set STUDIOPRO8_MCP_WRITE_ENABLED=1 and STUDIOPRO8_MCP_ALLOWED_SONG to the absolute path of the one saved .song that is open; any other open song is refused, and the device re-checks the open document when the request runs.
• Risky tools also need confirm: true (record, bounce, undo/redo, delete, arm, applying a mix…), meant to follow the musician’s own request. Every tool has a risk class (READ, UI_TEMP, WRITE, HIGH, FILE) in src/core/tool-policy.js.
• Destructive repairs happen in copies, with your approval. Relinking, stripping inserts, replacing instruments and writing automation lanes produce a new .song; your song is never written, and the copy is created exclusively (never over a file that is there, even one that appeared a moment ago). A preview comes first and returns the SHA-256 of the source and a hash of the exact arguments; apply: true also needs confirm: true, STUDIOPRO8_MCP_COPY_WRITE_ENABLED=1, the one source in STUDIOPRO8_MCP_COPY_ALLOWED_SONG, and those two numbers back. Change the source or any argument and the approval no longer matches.
• Strict inputs. Every tool’s schema rejects unknown arguments. There is no eval.
• Read-back, not trust. A write is sent once and read back from the DAW; the answer is VERIFIED, or DEGRADED with reasons. A write whose outcome is unknown (UNKNOWN_OUTCOME) is never retried. Undo exists only as the tools you ask for, as one attempt with the session read before and after — Studio Pro records plug-in parameter changes in its history late, so a blind retry could undo the wrong thing. Nothing in this server undoes anything to get something else done (the analysis of a mix, for instance, reads exported files and sends no Undo).
• Plans check the world again. The revision hash of a Session does not cover plug-in values, notes, audio or sends, so a plan records what each thing read when it was made and does not run a step for something that changed since. A plan interrupted by a crash is marked for review when the server starts; it is never resumed.
• Files go only to folders you approve (STUDIOPRO8_MCP_MIDI_OUTPUT_DIR, STUDIOPRO8_MCP_MACRO_DIR, STUDIOPRO8_ALLOWED_AUDIO_ROOT), outside this checkout, and never over an existing file.
• song_* by path read .song files only inside the songs folders (STUDIO_ONE_SONGS).
• No screen control. The server never operates the mouse or the keyboard.

---

Tools

The server’s own tools/list carries the most detailed description of each tool; npm run check compares that list with the risk policy in src/core/tool-policy.js.

---

How it works

Studio Pro has no public API, no OSC and no network scripting. This server combines what it does have:

Studio Pro scripts can read and write files but cannot open sockets, so the bridge is a folder, woken by a MIDI note on a virtual port:

flowchart LR
  client["MCP client(Claude Desktop, Hermes)"] |stdio| server["StudioPro8-MCPserver (Node)"]
  server -->|"1 write request.json"| mailbox[("mailbox folder")]
  server -->|"2 note 119"| midi["virtual MIDI port(loopMIDI)"]
  subgraph daw ["Fender Studio Pro 8"]
    device["MCP Bridge device"]
    session["session, mixer,transport, commands"]
    tasks["edit tasksMCP Edit · MCP Track Edit"]
  end
  midi -->|"3 wakes the script"| device
  mailbox -->|"4 read request"| device
  device |"5 run the op"| session
  device -.->|"notes, routing,plug-ins"| tasks
  device -->|"6 write response.json"| mailbox
  mailbox -->|"7 read response"| server

Two rules for anything that runs inside the DAW, learned the hard way: never throw (an exception while Studio Pro calls a script becomes a modal Scripting Error dialog, even when caught) and never call a member of a host object without checking it exists. The device returns errors as values.

A few facts about Studio Pro 8.1.2 that shape the design:

• The bridge answers only while a session is open, and the device and edit tasks load only at startup.
• A parameter is addressed as group.name; a VST3’s as vstp; the DAW lists neither, so the server tries names and ids and reads back what answers.
• The undo history records plug-in parameter changes late, so an undo right after parameter writes can undo the wrong step. Every undo is one attempt, checked against a read of the session before and after.
• live_bounce renders a track before its fader and pan, and an audio track’s render lacks its channel’s plug-ins. The mix engine therefore does not bounce: it reads the stems you export with the Export Stems dialog.
• Automation lanes cannot be added to the open session from a script; they are written into a copy of the .song, with the plug-in’s own automation mode set to Read, and the DAW plays them.

Every copy of a saved song is written by one session compiler. A preview reads the song once, indexes it, runs the changes on it in memory (so two that contradict each other are refused there) and stores one plan bound to the song’s SHA-256. The apply takes that plan once, under a claim no second process can take, writes a journal entry before each step, builds the copy in a private stage, verifies it (only the declared entries changed, the song still reads), and publishes it with an exclusive hardlink next to the source: a file that exists is never replaced, and an interrupted compilation is classified at the next start, never continued. An arrangement is written the same way, natively (the loop’s own events repeated, one-shots packed into an AudioPart at their offsets, the sections in the Arranger track, the End marker moved when the arrangement runs past it), through codecs written from A/B pairs Studio Pro itself saved for its exact build (19 pairs for 8.1.2.113407, compared with scripts/diff-native-loop-song.mjs); a song saved by another build answers BLOCKED_HOST_EVIDENCE until that build has its own, and nothing is written.

---

Engineering contract

What the project holds itself to, short enough to check.

Safety

• No automatic Undo is used to compensate a bounce or an uncertain write. A write that may have happened is never retried.
• A transformed copy of a .song needs approval bound to the source’s SHA-256, the destination and the exact arguments; the destination is created exclusively and never overwritten.
• A partial revision hash cannot prove that nothing changed in MIDI, plug-ins, automation or routing: plans record and re-check what they depend on.
• A compiled copy is checked in the DAW only while it holds the bytes it was published with; once saved again it must first be shown to differ only as Studio Pro is seen to save (a comparison with the bytes kept at publication), or it is OUTPUT_CHANGED_SINCE_PUBLISH. The lineage of a copy follows its bytes, never its name.
• An export may land only inside the approved audio folder, and a link or a junction on the way is refused; the guarantee is of the moment of the check.

Evidence vocabulary

Verification

• npm run check (tools, schemas, policy over stdio), npm test (security, regression, persistence, failure injection) and npm run verify for both.
• Real Fender Studio Pro checks are made only on a disposable Session, on Windows, through the MCP. No test with a scripted bridge may raise a capability to DAW_VERIFIED or AUDIO_VERIFIED.
• test/VERIFICATION_MATRIX.md says, for each safeguard, how it is tested, what was run and what has not been.

Scope

• A Session (.song) and mastering on its main output are implemented. A native Mastering Project (.project) is a different document that is not implemented, by decision: nothing here stands in for it.
• Export Mixdown and Export Stems stay GUI_ASSISTED until their source and processing can be observed.

---

Limits

What a script cannot do in Studio Pro 8.1.2 — and what the server does instead:

Fifty stems. An offline Export Stems of 50 tracks of a 6-minute song was cancelled for its length; nothing here edits the .song to make it faster or lowers its quality. The way through, in the tools: studio_render_preview of the stems answers a strategy (nothing started): the stems in batches of tracks, which the dialog lets the musician choose (a first batch of 4 when no stems export of this song was verified yet, so that it measures), and a budget measured on the verified stems exports of the same song (from the first stem the dialog created to the last it wrote: Studio Pro 8.1.2 creates each stem when it starts it and writes all of them again when the export ends, so their write times alone say nothing), never a fixed figure; one job per batch, so that studio_render_verify says per file what was written; studio_render_status says OVERDUE past twice the budget and stops nothing; cancelled_in_daw writes down a cancel the musician saw; and studio_render_start with retry_of starts a job again only when none of its files was written. A file found is AUDIO_FILE_VERIFIED at most, never DAW_RENDER_ORIGIN_VERIFIED. Run on Neon Horizon EDM (50 tracks, 6 minutes, offline): a first batch of 4 stems in 101 s, then the 46 others in one job in 1104 s against a measured budget of 1162 s; all 50 verified.

And in the mix itself: the faders and cuts come from measurements and conventions of club music (RELATIVE_LU, the master chains’ numbers). The loudness of each role against the kick was calibrated on 2026-10-13 on the mix the musician had accepted by ear, heard from the DAW’s own output (bass +3 LU against the kick, clap +2.5, lead −4, pad −8, hats −2.5, shakers −3.5); the earlier figures were 5 to 9 LU lower, set on renders that lacked the channels’ plug-ins; they are starting points, not a verdict on how a mix sounds. Peaks read from the meters of the same stretch move by about 1 dB from run to run. Loudness conventions weigh a 48 Hz kick as audible as a 1 kHz synth, which it is not — one reason the first mix was rejected by ear.

---

Configuration

Each output folder must already exist and be outside this checkout. The checked-in .mcp.json registers the server for this folder with writing off.

---

Repository

src/            the server: tools, policy, bridge, mixing, plug-ins, song editing, audio
  core/         tool policy, mailbox ownership, history guard, client record
  mixing/       live_mix_edm: engineer.js (rules), stems.js (measurement), edm.js, native-chains.js
  song-edit/    the offline repairs and automation lanes, as changes to a .song archive in memory
  compiler/     the session compiler: intents, plans, claims, journal, publication, native codecs and their evidence
  arrangement/  the sources of a loop, roles, sections bound to tracks, loop regions, the design store
  music/        genre profiles, roles, the arrangement plan, MIDI patterns
  plugins/      parameters, capabilities, VST3 ids
  audio/        loudness (BS.1770), true peak, A/B, worker bridge
  capabilities/ the catalogue behind studio_capabilities_query
  setup/        the setup wizard and the doctor
device/         the bridge device and the two edit tasks installed into Studio Pro
scripts/        install-device.js, check-mcp.js, run-tests.js, call-tool.js, diff-native-loop-song.mjs (compares an A/B pair of saved songs)
test/           the tests (node:test), their helpers, and VERIFICATION_MATRIX.md
.github/        the CI workflow: npm run verify on Linux and Windows, Node 20 and 22

npm run verify runs the policy check and the tests; npm run doctor checks the whole chain on your machine; node scripts/call-tool.js '{"json":"args"}' calls one tool on the local server.

---

An independent project, not affiliated with or endorsed by PreSonus or Fender. Studio One is a trademark of PreSonus Audio Electronics; Fender Studio Pro is a trademark of Fender.

License

MIT