rodey-mcp
Unofficial MCP server for RØDECaster Pro II, providing tools to read and write audio processing parameters like noise gate, compressor, and routing, enabling AI agents to control the mixer.
README
rodey
Like a roadie who runs the gear — but for your RØDECaster.
Unofficial Python library, CLI and MCP server for the RØDECaster Pro II. Control the board from code — mutes, routing, per-channel processing, full state reads — over its USB HID interface. RØDE publishes no host API; this protocol was reverse-engineered by observing RØDE's own app and the device's own notifications, then verified against hardware. See docs/PROTOCOL.md.
⚠️ Unofficial and not affiliated with RØDE. Developed against firmware 1.7.3. A firmware update may change the protocol. Read the safety notes below before writing.
Install
curl -fsSL https://raw.githubusercontent.com/seanheiney/rodey/main/install.sh | bash
macOS or Linux. One paste, no other setup. The installer handles every dependency:
- finds a suitable Python (3.9+); it does not install Python — if none is found it tells you and stops
- installs the hidapi native library via your package manager (Homebrew / apt / dnf /
pacman) and the Python
hidapibinding - creates an isolated venv under
~/.local/share/rodey(nothing touches system Python) - adds
rodeyto your PATH and, on Linux, installs a udev rule for non-root HID access - installs the MCP server too when Python is 3.10+ (the
mcppackage requires it); on 3.9 the CLI still installs and MCP is skipped
No git required — it installs from a source tarball. Re-runnable; upgrades in place.
rodey channels # what's patched to each strip
rodey get noiseGateOn # a value across all channels
rodey set 0x1c noiseGateOn on # write, then auto-verify
What you can do
| Area | Status | Notes |
|---|---|---|
| Read all device state | ✅ | 139 KB snapshot, 49 groups, 533 properties, in ~1 s |
| Channel mutes | ✅ | per strip; inverted polarity handled for you |
| Mix-bus routing matrix | ✅ | mute any source on any of 13 buses — this is mix-minus scoping |
| Per-channel processing | ✅ | noise gate, HPF, compressor, de-esser, Aphex, EQ, pan |
| Master channel | ✅ | Compellor, delay |
| Outputs / monitor / headphones | ✅ | levels and mutes |
| Enable MIDI control | ✅ | flips the board's documented MIDI surface on over HID |
| Verified writes | ✅ | every write is confirmed by a state-dump diff |
| MCP server | ✅ | drive the board from an AI agent |
What we figured out (the protocol)
All of this is documented in docs/PROTOCOL.md and encoded in the library:
- Handshake —
'N'on report 1 + a session-open on report 3. Nothing works without it; it also triggers the full state dump. - Frame format — a length-prefixed, name-addressed record with five value types (bool, uint32, float64, string), shared by reads and writes.
- Reads — the dump must be drained immediately after subscribing; any pause drops the head of the tree (this cost hours and produced several wrong theories).
- Channel addressing —
objID = 0x1C + strip. One object is a whole channel's processing block. Verified on 7 of 10 strips, then predicted and confirmed. - Mix-bus matrix —
objID = 0x4C + 13·source + bus, keyed by input source, not strip position. 106 objects mapped. - Two value conventions — faders/pots are
uint320–127 (and publish their own bounds); everything else isfloat640–1. - Inverted mute polarity —
channelOutputMute = Falsemeans muted. The library wraps this so you never have to remember it.
What is not possible
Documented so nobody re-derives them the hard way:
- Writing fader levels. The faders are physical and not motorised — a written value would disagree with the slider position, so the device refuses it. RØDE's own app can't do it either, and MIDI CC doesn't reach them. Faders are read-only; drive gain through channel processing instead.
- Live metering over our subscription. Real-time meters only stream when RØDE's app drives the board; our session-open yields the state dump but not the meter feed. Meter values are still readable from the dump.
- Float parameters in real units.
noiseGateThreshold = 0.5writes and reads back reliably, but the 0–1 → dB/Hz/ms mapping is unknown — these properties publish no bounds. Values are settable; their engineering meaning is not yet decoded. - SSH without flashing firmware. The board runs Linux with SSH enabled, but only the vendor's public keys ship in the firmware. Getting a shell requires building and flashing custom firmware (high brick risk); not something this tool does.
Safety
The library refuses dangerous writes rather than trusting the caller:
- Firmware mode bytes. Report 1 accepts only
0x4E('N').0x4D('M') enters firmware update mode and0x55('U') triggers a flash — both have blanked a board. Anything but0x4Eis refused. (A popular third-party project probes0x55as a "ping" — it is not.) - Destructive properties — device reset, SD erase, firmware flash, show delete — are
refused by
encode_write. - Never sweep object IDs. Writing an unknown property to a guessed ID permanently adds that property to the object. IDs are harvested from observed traffic, never probed; there is deliberately no scanner.
- Don't verify writes by ear. A condenser's noise floor drifts several dB; verify with the state dump instead (the library does this for you).
Library
from rodey import Rodecaster
with Rodecaster() as rc:
print(rc.strip_sources()) # [0, 1, 10, 7, 8, ...] channelInputSource codes
print(rc.muted()) # [False, True, ...] per strip, polarity handled
rc.set_muted(3, True) # mute strip 3
rc.set_channel(0, "noiseGateOn", True) # objID resolved from strip index
if rc.set_verified(0x1C, "hpfOn", True): # write, confirmed by dump diff
print("high-pass on")
snap = rc.snapshot() # {GROUP: {property: [per-strip values]}}
MCP server
rodey-mcp
{ "mcpServers": { "rodey": { "command": "rodey-mcp" } } }
Tools: get_property, set_property (verified), list_properties, list_known_objects,
watch_changes. No tool can reach the firmware-mode channel; there is no objID scanner.
Extending the object map
docs/PROTOCOL.md explains the capture procedure. tools/harvest_objids.py parses
writes made by RØDE's app; tools/capture_board.py listens while you operate physical
controls. Both are pure observation — contributions of harvested IDs are welcome.
Development
git clone https://github.com/seanheiney/rodey && cd rodey
python3 -m venv .venv && . .venv/bin/activate
pip install -e '.[dev]'
pytest # 56 tests, no hardware required
License
MIT
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
E2B
Using MCP to run code via e2b.
Neon Database
MCP server for interacting with Neon Management API and databases
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.