Live CLI and MOPs

The Live CLI feature gives Claude a real console session to your devices, plus tooling to turn what happens in that session into a documented, repeatable procedure.

Enable it under Features in the dashboard.

device_cli — a real console

device_cli opens a live interactive CLI to a RUCKUS ICX switch or an AP over the same R1 web-UI WebSocket the R1 web console uses. It is the full CLI — any command, real output.

To open a session Claude needs the venue, the device type, and the device’s serial number (not its MAC), plus an ordered batch of commands. Commands run sequentially at the switch enable prompt or the AP rkscli: prompt. On ICX you can interleave config and show commands in one batch, because show works from config mode.

The session is held, so a follow-up batch continues in the same session rather than logging in again.

Reading the output

Each completed command comes back with its real console output. R1-MCP’s rule is that this output is surfaced verbatim in Claude’s reply — in a fenced code block, labeled with its command — and then interpreted. You should always get to see what the device actually said, not only a paraphrase of it.

Occasionally a result carries a marker meaning completion took a fallback path — the device kept talking after the prompt, or the command echo was never recognized. When that happens the attribution of output to command may be imperfect, and it’s worth reading that block yourself rather than trusting the summary.

When it fails

A prompt timeout usually means the device is offline or unreachable, not that the request was malformed. Confirm the device is online before retrying — each first-call retry opens a fresh session, so blind retries against a dead target just pile up.

Other errors are explicit: credentials unavailable, token mint failure, WebSocket upgrade failure, incorrect login, no commands supplied.

MOPs — Method of Procedure

A MOP is a change runbook: ordered steps, each with the command, its intent, where the syntax was verified, the observed output pinned as the expected baseline, a verification gate, and rollback commands.

Tools: mop_save, mop_list, mop_get, mop_edit, mop_delete, mop_export, mop_replay.

Recording a live session

The fast way to author one:

1. Save a draft MOP with just a title — you get back a MOP id.
2. Pass that id to device_cli as the record target.
3. Every command you run is captured as a draft step with its real output pinned as the baseline.
4. Enrich the draft afterwards — intent, gates, rollback, provenance.

Provenance is required

For every switch configuration step, the syntax must first be verified against the FastIron documentation for the device’s firmware train, and the section recorded on the step. Exported MOPs print that citation. A step without provenance exports as “no provenance recorded”, and the sign-off footer states plainly that the commands were not validated against documentation.

This is the difference between a runbook a change board will accept and a transcript.

Test plans

The same artifact with kind: "test_plan" turns the steps into test cases with declared expectations that gate on replay — a case with no gate defaults to requiring a human OK rather than silently passing. Test-plan runs keep 90 days of regression history.

The kind is immutable once saved: decide up front whether you’re writing a change procedure or a test plan.

Steps can be API checks too

A step doesn’t have to be a CLI command. An API step carries an R1 call plus expected-status and comparison gates, authored from a response you actually observed. Useful when the verification is “the controller now reports X” rather than “the console prints Y”.

POC and QA test plans

The POC / QA test plan (author → run → report) prompt runs the whole cycle: writes a plan against an objective, executes it, and reports the results.

Related

• ICX switches and FastIron docs — where step syntax is verified
• Write Guard — confirm-before-write on mutating calls
• Test beds — lab hardware swaps