The interesting part is the mismatch.
Blokkily is an experimental pattern-first digital audio workstation. Its repository describes one event model behind a tracker, piano roll, step grid, arrangement, mixer, plugin hosts, audio clips, MIDI, and microtonal controls. Revision f2e8f95 also contains two ways for a model to change a song.[1]
The built-in composition assistant sends the current musical context to a selected model. The reply becomes a proposal. The producer must click Apply before the song changes, and one accepted generation becomes one undo step. The assistant runs outside the audio thread.[1]
The MCP route is different. Purpose-built tools can read the session, write notes, control playback, choose instruments, and set parameters. The server also exposes describe and call. Together they can discover and invoke public application methods used by the interface.[1]
A preview gate and a direct-control port are not two skins on the same feature.
Undo is useful. It is not approval.
The repository's MCP feature says an agent edit reaches the canonical song, appears in every editor, and can be taken back through undo. Its verification scenario writes notes, changes a fader, reads rendered state, and then calls undo. The implementation validates every requested note before it checkpoints and writes the batch.[1]
That is solid transaction design. It does not answer whether the producer approved the edit before it happened. It also does not make every callable method reversible. The MCP instructions list save and audio export as examples for the generic call tool. A file write or export has a different recovery path from an in-memory note edit.[1]
The MCP tools specification says tool calls are model-controlled, while applications should keep a person able to deny calls, show which tools are exposed, indicate invocations, and present confirmation prompts. The protocol does not force one interaction pattern.[2]
Split authority by effect.
A creative application needs more than read versus write. A practical split has separate grants for inspection, reversible session edits, project-file writes, and exports. The client can then approve a note proposal without also approving a bounce to an arbitrary path.
READ_SESSION=ALLOW
EDIT_LIVE_DOCUMENT=ASK
WRITE_PROJECT_FILE=DENY
EXPORT_AUDIO=DENY
GENERIC_METHOD_CALL=DENY
UNDO_TRANSACTION=REQUIRED
VISIBLE_INVOCATION=REQUIREDBlokkily's generic method bridge is technically expressive. It also collapses many effects into one tool name. The current tool definitions do not include annotations that distinguish read-only, destructive, or idempotent behavior. A client can still add confirmation policy, but it must understand the method inside call, not only the outer tool name.[1][2]
Local does not mean low authority.
The bridge speaks MCP over standard input and forwards tool calls to the running window through a local socket. It can start the application if no window is listening. The MCP security guidance recommends standard input for local servers because it limits access to the client process. The same guidance warns that local servers run with the client's privileges and calls for explicit consent, restricted access, and narrow scopes.[1][3]
The useful design move is not to remove model control. It is to keep the authority visible at the point where the effect changes. Proposal, edit, save, and export need separate labels and separate gates.
The launch also exposed a communication gap.
Readers in the Hacker News thread asked for a short video with sound and a clearer explanation of the front end. Those comments do not test the application. They do show that a long implementation inventory did not answer the first product question for those readers: what happens when a person opens it and makes music?[4]
That gap matches the authority problem. A tool list says what software can do. A good control surface says what will happen now, who commits it, and how to reverse it.