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. The user decides what the AI may read, and the decision takes effect right away.
Why it was needed
When you ask an AI for an effect, it writes the code, runs MIDIFabric’s Check and submits it. But Check only tells you that the effect compiles and starts, not that it does what you wanted. To find that out, you have to see what came out when you played.
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.
We were also clear about what cannot be 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
Off by default, allowed separately
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 we felt users should choose what to hand over.
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.
The tools are not hidden
Even when a permission is off, the two tools still appear in the list. Calling one returns “not allowed” (permission_denied). If the tools were hidden, the AI would not know why it cannot read anything, and could not tell the user what to change. We do not use hiding as a form of protection.
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.
What was returned cannot be taken back
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 Letting AI work with a MIDI app without leaving the Mac). MIDIFabric itself sends what is read nowhere.
The records are not automatically the whole truth
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.
And even when the records are correct, they only show that the MIDI sent was correct, not that it sounded as intended. Answers keep “behavior not verified” (behavior_verified: false). How it sounds can only be checked by the ears of whoever played.
A small detail: 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 stops. 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. The AI writes the tool; you play it.