zeros-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZEROS_IP | No | Console address. A desk on factory settings is 192.168.1.10. | 127.0.0.1 |
| ZEROS_PORT | No | Match the console's Receive Port Number. | 8830 |
| ZEROS_LOG_LEVEL | No | DEBUG logs every OSC message sent. | INFO |
| ZEROS_TRANSPORT | No | udp or tcp. Must match the console's protocol setting. | udp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fire_macroA | Runs a user macro stored on the console. What the macro does is whatever was recorded into it at the desk; this server cannot see its contents, so ask the user what a macro number does rather than guessing from its number. |
| set_grand_masterA | Sets the grand master level, optionally fading to it. The grand master scales the entire rig, so this is one of the few commands here that can black out a show on its own. Confirm before sending it during a performance. |
| set_blackoutA | Turns the console's blackout on or off. ZerOS accepts several spellings for the argument ("1", "on", "true" and so on); this sends "1" and "0", which are the least ambiguous. |
| fire_cueA | Fires a specific cue. Naming the playback is the clearer call, but the cue-only form is worth knowing about: an FLX S48 user reported the playback-qualified address being ignored where the cue-only one worked. If a cue will not fire, try omitting the playback before concluding the console is not listening. |
| go_cueA | Presses Go, advancing to the next cue. With no playback given this drives whichever playback the console currently considers active, which this server has no way to know. Naming the playback is the safer call whenever you know which one you mean. |
| set_pending_cueA | Sets which cue is next, without firing it. This is ZerOS's "Next" command. Use it to jump the standby cue somewhere
else in the stack, then |
| pause_playbackA | Pauses a running fade. |
| release_playbackA | Releases a playback, returning the channels it holds to the stack below. |
| view_playbackA | Brings a playback into view on the console's screen. Changes what the operator sees and nothing about the lighting output. |
| set_playback_levelA | Sets a playback's fader level, optionally fading to it. Omitting the fade time is not the same as fading in zero seconds: ZerOS then
uses the playback's own raise and lower times, moving rather than snapping.
Pass |
| get_connection_healthA | Reports what can be determined about the link to the console. How much that is depends entirely on the transport. Over TCP a connection either establishes or it does not, which is real evidence. Over UDP there is none to be had: nothing is ever returned, and a successful send only means the packet left this machine. Either way, a healthy link is not evidence that any individual command was understood. ZerOS acknowledges nothing. |
| get_command_journalA | Returns what this server has sent to the console. This is your own history, not the console's state. Every entry means "this message left this machine"; none of them means the desk received it, acted on it, or is still in that state. Someone may have moved a fader by hand a second later and this server would never know. Use it to retrace what you did, never to answer what the rig is doing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| system_instructions | Operating instructions for driving a ZerOS console through this server. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct purposes: set_ commands target different parameters, get_ commands retrieve different information, and playback controls are separated by action (pause, release, view, level). The only potential overlap is between fire_cue and go_cue, but the descriptions clarify that one runs a specific cue while the other advances to the next cue.
Tool names follow a consistent verb_noun pattern with useful prefixes (set_, get_, fire_). Minor deviations exist, such as go_cue versus fire_cue and pause_playback/release_playback/view_playback, but the overall naming is predictable and readable.
With 12 tools, the server is well-scoped for controlling a lighting console. It covers cue firing, playback management, levels, blackout, macros, and diagnostics without unnecessary bloat.
The set covers the essential live-control operations (cues, playbacks, grand master, blackout, macros) plus useful diagnostics. The main gap is the inability to read console state—only command history is available—but this is a documented protocol limitation, so it's an acceptable minor gap.