rcontrol/mcp: are there plans for an official MCP / scripting surface? (built one on top of it)

Hi — I wanted to introduce myself and what I've been working on, in case it's useful or overlaps with where you're taking this.

I maintain an MCP server for Audacity 3 (Audacity-MCP), which works through mod-script-pipe. When Audacity 4 dropped that with nothing in its place, I asked in audacity/audacity#10533 whether extensions would be able to trigger actions in v4, and then went looking for how it might be done.

That's when I found framework/rcontrol/mcp. It gave me exactly the piece I'd have struggled to write well myself — the transport and the JSON-RPC framing — so I built a command surface on top of it: a module registering commands through ICommandsRegister against Audacity's own interfaces (ITrackeditProject, ISelectionController, IEffectsProvider, IRealtimeEffectService, IEffectParametersProvider). It's at 84 commands now, which a Python MCP server composes into 159 tools — editing, selection, effects, realtime VST3 chains with live parameter control, labels, transcription, and some higher-level cleanup and mastering workflows.

It works well enough that I've been using it daily on real projects. Everything is tested against a running instance rather than mocks, which is how I ended up finding a few things in Audacity itself along the way — including a VST3 host bug where plug-in messages arriving from non-UI threads were dropped, which meant no VST3 meter or analyser had ever animated. That one's up as audacity/audacity#11992.

• Server: https://github.com/xDarkzx/Audacity4-MCP
• Fork it runs against: https://github.com/xDarkzx/Audacity4-Dev-MCP — the command module is src/mcp/ if you want to see the shape of it

What I'd really like to know is whether an official scripting or MCP surface is on the roadmap for Audacity 4.

I'm maintaining a fork at the moment, which I'd rather not do indefinitely if this is somewhere the project is already heading. If it is, I'd be glad to contribute what I have rather than keep it separate. If it isn't planned, that's a completely fair answer — it would just be genuinely useful to know either way.

I've also picked up a fair amount about the sharp edges of driving Audacity programmatically, and I have fixes for a few things I ran into in rcontrol/mcp while building on it. Happy to send those as PRs, or to write up what I've learned, if either would be useful — and equally happy to leave it if the module's direction is still moving.

Thanks for building it in the first place — it saved me a lot of work.

Start by reading framework/rcontrol/mcp to understand the existing transport and JSON-RPC framing, then review the linked Audacity issue and the external Audacity4-Dev-MCP fork's src/mcp/ module. The issue is asking for roadmap direction rather than naming a scoped change; it is done when maintainers clarify whether an official scripting or MCP surface is planned and what contribution path is appropriate.