rytm-agent-bridge

What you can ask for

The vocabulary is musical intent, not SysEx addresses. Each example below names the tools that actually run — all of them exist today and are certified against hardware.

The tool surface

Thirty-two tools, MCP-shaped: the adapter exposes listTools() and callTool() so it mounts into an MCP host or any agent runtime you already run.

Wiring it up

A standard MCP stdio server. Two adapters sit behind the same 32 tools — start with mock, which answers everything in-process with no hardware and no daemon.

$ git clone https://github.com/chronick/analog-rytm-agent-bridge
$ cd analog-rytm-agent-bridge && npm install

$ claude mcp add rytm -- npm run mcp
$ claude mcp add rytm-hw -- npm run mcp:hardware

{
  "mcpServers": {
    "rytm": {
      "command": "node",
      "args": [
        "--experimental-transform-types",
        "/path/to/analog-rytm-agent-bridge/src/bin/mcp-server.ts",
        "--adapter", "hardware",
        "--clock-source", "observed"
      ],
      "cwd": "/path/to/analog-rytm-agent-bridge"
    }
  }
}

A refused or failed Rytm operation comes back as a normal tool result with isError and a readable reason, not a protocol fault — the agent sees why and adapts instead of losing the connection.

Or describe a whole project at once

Patterns, machines, sounds, scenes, performance macros, and samples in one JSON declaration — useful when you want a repeatable starting point rather than a conversation.

$ npm run build:project -- declaration.json --execute --auto-slots

{
  "project": "layered-kick-demo",
  "sounds": {
    "BD": {
      "machine": "bdplastic",
      "machineParams": { "tun": -14, "swt": 54, "dec": 45, "lev": 110 },
      "filter": { "filter_type": "Pk", "resonance": 40 },
      "amp": { "overdrive": 8 }
    },
    "BT": {
      "machine": "btclassic",
      "lfo": { "destination": "SampleFineTune", "waveform": "Tri", "depth": 32 }
    }
  }
}

Patterns take a step-grid shorthand too — "X... X... X... X...", where X is an accent, x a normal hit, o a ghost note, and . is silence — so a rhythm can be written the way you'd sketch it on paper.

A declaration with samples is preflighted against the device's RAM inventory before anything is applied. Each declared slot must be free or already hold that sample's own content; otherwise you get a conflict report and a non-zero exit having changed nothing. --auto-slots remaps conflicts, rewrites the p-locks and kit fields that pointed at them, and stays idempotent across repeat runs. Slots the declaration does not own are never touched.

It can hear what it made

Capture is part of the loop rather than an afterthought, which is what makes an actual iteration possible: program a pattern, play it, record it, analyze the take, adjust, go again.

audition:project plays every pattern in a declaration from generated clock and captures a verified take per slot, so the output of a build is audio you can listen to. audition:solo does the same per track, with an RMS and peak table, when you need to know which voice is actually causing a problem.

Reversible by construction

That is the whole reason an agent gets to touch the instrument at all. It is hardware-certified against an injected failure, not just unit tested. It does not, however, back up your entire device: save to +Drive and take an external backup before first use. Full detail in the README and HARDWARE_SETUP.md.

Honest scope

"Certified" means run against a connected Analog Rytm MKII on OS 1.72, verified by readback, with the device restored to its exact pre-test state. The dated validation certificates in the repo are those runs.

macOS only — the daemon depends on CoreMIDI and CoreAudio. The codecs target firmware 1.70 and the certificates are from a 1.72 device; neither is a blanket guarantee for other firmware, so unknown-capability operations are gated rather than guessed at.