Every time we checked an effect an AI had written for us, we copied the monitor log and pasted it into the conversation.
So we gave MIDIFabric a way for a connected AI tool to read the monitor records and the routing setup over MCP. Both are off by default and are allowed separately in Settings > AI. Even when allowed, the AI only reads: it cannot change routing or send MIDI.
Why it was needed
When you ask an AI for an effect, it writes the code, runs MIDIFabric’s Check and submits it. Check compiles and initializes the effect. Verifying its behavior requires playing it and inspecting the resulting MIDI.
Until now, we pasted the monitor log and the AI counted from it. Choosing what to paste and telling the AI the settings were our job. If the AI can read the records and the routing itself, saying “played it” is enough. How that went in practice is in An effect written by AI, checked by the AI itself.
What can and cannot be read
We added two MCP tools:
- Monitor records (
get_monitor_records). Reads the records the monitor is currently holding, oldest first, in pages. They include the MIDI messages, retained SysEx, device and port names, the links between an effect’s processing and its output, the number of dropped records, whether the monitor is paused, the capture filter settings, and a mark on records that were cut short. This is independent of the on-screen search, and records the monitor no longer holds cannot be read. - Routing setup (
get_routing_snapshot). Reads the applied routes and connections, bypass states, and the names and current parameter values of placed effects. Edits that have not been applied are not included.
The tools cannot read records saved in the MIDI Debugger, the app’s logs and any other files. MIDIFabric does not record audio, so all the AI can read is MIDI records and settings. Reading never pauses, clears or filters the monitor, and never sends MIDI or starts or changes routing.
How the permissions are decided
Separate permissions for monitor and routing
Monitor records can contain SysEx data and the device and port names users have given. The routing contains route and effect names and settings. What the AI reads goes through the AI tool to the AI company, so users choose separately whether to share each type of data.
Settings > AI therefore has an “AI data access” section with two separate checkboxes, “Allow reading retained Monitor records” and “Allow reading Routing settings”. Both are off by default. With both off, creating and submitting effects works as before.
Requests without permission return an error
Both tools remain listed when their permissions are off. Each read request checks the relevant permission and returns permission_denied if access is disabled. This lets the AI explain which setting the user needs to change.
Off takes effect at once, on after saving
Turning a permission off stops reads on the current connection before the setting is saved. If saving fails, reads stay stopped. Turning a permission on takes effect only after the setting has been saved successfully.
A request that was in progress when the permission was turned off is rejected as an old request, even if the permission is turned back on. That way, no answer to a request made before the switch can come back after it. Neither change requires restarting the AI tool. However, for an AI tool to discover the two new tools for the first time, its MCP connection may need to be reconnected on the AI tool’s side. We had to reconnect Claude Code.
Data already shared with the AI
Turning a permission off does not recall records the AI has already received. The settings description and our privacy policy say so.
The connection itself is still accepted only from inside the Mac, and requests without the access token are rejected (see Connecting MIDIFabric to AI through MCP). MIDIFabric returns the data to the connected AI client; it does not send it directly to an external service.
Reporting missing records to the AI
Monitor records have limits. The monitor holds a limited number of records, nothing is recorded while it is paused, and messages excluded by the capture filter are not kept.
So along with the records we return the number of dropped records, the pause state, the filter settings and the marks on records that were cut short, and we instruct the AI to cite them as the basis for its conclusions. If the playing in question is not in the records, or records were dropped, the AI should not declare everything fine but ask the user to play again. The routing setup and the monitor records are snapshots taken at different times, so the AI matches the effect’s definition revision before comparing them.
Even a complete set of MIDI records does not establish that an effect sounds as intended. Responses include behavior_verified: false; the user still needs to play and listen.
Large numbers such as record sequence numbers and times are returned as decimal strings. If the reading side treated them as JSON floating-point numbers, digits would be rounded off and the records could no longer be matched.
What we checked
In a prototype that copies the product code, we checked 22 items, both in a normal run and in the App Sandbox. They include rejecting requests without the token, both permissions being off by default, one permission never opening the other, rejecting a request when the permission was turned off during it, reading in pages, reporting drops and pauses, routing staying unchanged by reads, and handling a late response after the connection stopped.
In real use, Claude Code used both tools to check a repeat effect, reading several hundred records and counting repeats and checking Note Off timing. We have not yet measured how fast reading is when there are very many records.
About MIDIFabric
MIDIFabric works with AI tools you run yourself, over MCP. You decide in the settings what the AI may read.