# Assistants

> Connecting Claude, Cursor, VS Code or Claude Code to RDMBench's MCP server, which runs on the bench computer, and what it can and cannot do.

- **Server:** rdmbench-mcp, inside RDMBench.app
- **Transport:** stdio, started by the assistant
- **Runs on:** macOS 15 Sequoia or later, Apple silicon
- **Needs:** An Enttec DMX USB Pro with its DMX/RDM firmware (major version 2)
- **Price:** Free

RDMBench carries an MCP server, so an AI assistant can scan the bench,
read the reports and compare visits for you. It runs on the bench
computer. There is no hosted RDMBench server, no account, and no API
key: you bring the assistant and the model.

## Connecting

In RDMBench, open **Settings → AI Assistant** and click **Connect** next
to the assistant. Each one is a single click:

- **Claude Desktop** opens the extension that comes with the app, and
  Claude Desktop asks you to install it.
- **Claude Code**, **Cursor** and **VS Code** get the server added to
  their own configuration.
- **Other** gives you the configuration to paste.

### By hand

The server is a program inside the app. Every assistant starts it the
same way:

```
/Applications/RDMBench.app/Contents/MacOS/rdmbench-mcp
```

Claude Code:

```
claude mcp add --scope user rdmbench -- /Applications/RDMBench.app/Contents/MacOS/rdmbench-mcp
```

Cursor (`~/.cursor/mcp.json`) and most other clients:

```json
{
  "mcpServers": {
    "rdmbench": {
      "command": "/Applications/RDMBench.app/Contents/MacOS/rdmbench-mcp",
      "args": []
    }
  }
}
```

VS Code (`~/Library/Application Support/Code/User/mcp.json`) uses
`servers` instead of `mcpServers`, with the same entry.

## What it can do

The assistant gets twelve tools. All but `load` read; `load` drives a
fixture only to measure it.

| Tool | What it does |
|---|---|
| `scan` | Reads fixtures now and returns full reports, which are saved |
| `monitor` | Watches one fixture for up to ten minutes: per-sensor minimum, maximum and average, and timestamped events |
| `monitor_line` | Watches every fixture on the line, to find the one that drops out |
| `load` | Holds the fixture's channels up for up to ten minutes and reads its sensors before and after, for faults that only show while it works |
| `list_snapshots` | Every report on disk, newest first, with its rating |
| `list_sessions` | Every monitoring session on disk |
| `read_snapshot` | One full report |
| `session_summary` | What a saved monitoring session saw |
| `compare` | What changed between two reports, or a unit's two latest |
| `history` | One unit across every visit, with repair notes and recurring issues |
| `templates` | The settings standards filed for a model, to read |
| `desk_mode` | What a lighting desk calls the fixture's current mode, from its GDTF file |

The server also offers the assistant the JSON schemas the reports
follow, and the app's help.

## What it cannot do

- **Change a fixture.** No address, personality or label changes, and it
  does not apply templates. Those are done in RDMBench, by you.
- **Run a load test over you.** It refuses while you are sending DMX or
  monitoring from the app.
- **Drive a fixture that reports no sensors.** `load` refuses it rather
  than drive something it cannot measure.
- **See light.** `load` reads sensors; it cannot see colour or position.

## Where it runs

The assistant starts the server, and they talk over stdio. While
RDMBench is connected to a widget, the server asks the app to do the
reading, over a loopback address on the same computer. With RDMBench
closed, the assistant can still read every saved report; a scan says
that RDMBench needs to be open.

Connecting sends nothing anywhere. What the assistant reads goes to its
provider as part of your conversation, like anything else you show it.

An assistant on another computer can connect only if you turn on
**Settings → AI Assistant → Advanced → Also let assistants on other
computers connect**. Anyone on that network can then use the bench,
load tests included, with no password, so leave it off unless the
network is the shop's own.