26 MCP Tools
Discovery, routing, channel mapping, monitoring, batch operations, audit and replay — every write tool accepts dry_run.
AURORA — BROADCAST CONTROL PLANE
Aurora
A broadcaster-grade orchestration control plane for mixed-vendor IP media facilities. Aurora composes a vendor-neutral core (compatibility engine, audit journal, lifecycle state machine) with pluggable southbound adapters for NMOS IS-04/05/08/09/11 and Ember+, and exposes those capabilities through the Model Context Protocol — operable directly by engineers, by AI assistants under human direction, or by both.
Vendor-Neutral Core
Calrec, Grass Valley, Lawo, and Studer share one canonical model via IS-04/05 and real Ember+ (TCP + s101 + BER) read.
dry_run on Every Write
Plan before you cut. Audit before acting; audit after acting. Snapshot-based rollback restores prior subscriptions on failure.
What it does
| Capability | Where it lives | Phase |
|---|---|---|
| Vendor-neutral lifecycle: plan → stage → activate → verify with dry_run on every write | src/control/service.ts | 1 |
| Bilingual (en/fr) operator output as a baseline contract | src/tools/response.ts | 1 |
| BCP-004-01 receiver-caps full walker (17 URN evaluators) | src/control/constraint-sets.ts | 3 |
| SDP-aware sender parameter merging (flow + SDP + IS-11 active) | src/control/constraint-sets.ts buildSenderParams | 3 |
| Audit journal (append-only JSONL, dry-run aware, snapshot-aware) | src/journal/audit.ts | 2/3 |
| Snapshot-based rollback for atomic batches + manual replay | src/tools/batch.ts, aurora_replay_snapshot | 3 |
| BCP-002-01 natural grouping surfaced in topology + audit | src/control/grouping.ts | 3 |
| Real NMOS IS-04/05/08 against any compliant registry | src/adapters/nmos-adapter.ts | 1 |
| IS-09 system params (PTP domain, syslog, registries) | src/clients/nmos-system-client.ts | 3 |
| IS-11 stream-compatibility read (active shape overrides flow/SDP) | src/clients/nmos-stream-compat-client.ts | 3 |
| Real Ember+ transport (TCP + s101 + BER) read-only | src/clients/ember-plus-sofie-provider.ts | 3 |
| Per-vendor SemanticHintRules for Lawo / Calrec / Studer / GV | src/clients/ember-plus-semantic-rules.ts | 3 |
| Live-registry CI smoke (digest-pinned rhastie/nmos-cpp) | .github/workflows/ci.yml | 3 |
Why it exists
2110 Went Mainstream
Lawo HOME, Calrec ImPulse, Studer/Evertz, GV AMPP, Grass Valley Densité IPG-39xx and NVIDIA Mellanox all ship IS-04/05 native. The control plane is standardised in a way it never was in SDI.
The Control Plane Stayed Vendor-Locked
Every console, matrix, multiviewer, and gateway still ships its own UI, automation script language, and scheduling model. The plant is interoperable; the orchestration is not.
AI Agents Became Real Operators
Production assistants need a structured surface to act on. MCP is the protocol that lets them speak to infrastructure without bespoke per-tool plumbing.
Three failure modes Aurora rejects
The "vendor super-panel" approach (GV Orbit, Lawo VSM, Evertz Magnum-SDVN): excellent within their vendor pack, structurally incentivised to push *their* vendor as the default; bolted-on NMOS support that doesn't reason about compatibility deeply. The "MCP wrapper" approach (early NMOS MCP servers): forward a few REST calls to an LLM, no compatibility engine, no audit journal, no lifecycle state machine. Useful demo. Cannot run a show. The "autonomous AI operator" approach. Aurora is built for assist, not autonomy. Every write is gated by a human-triggered activate; agents prepare and explain plans, humans commit them. The audit journal records actor and source_interface for every state change — legal, compliance, and labour-relations review surfaces are first-class.
Architecture
Rendering diagram…
Press a to expand, Esc to collapse, \ to cycle themes, 1/2/3 for tabs. Five more diagrams on the Diagrams tab.
The 26 tools
| Discovery (8) | |
|---|---|
| nmos_list_nodes | List NMOS nodes |
| nmos_list_devices | List NMOS devices |
| nmos_list_senders | List NMOS senders |
| nmos_list_receivers | List NMOS receivers |
| nmos_list_flows | List NMOS flows |
| nmos_list_sources | List NMOS sources |
| nmos_get_resource | Get one NMOS resource by type and ID |
| nmos_search | Search across NMOS resources |
| Connection (6) | |
|---|---|
| nmos_connect | Plan or execute a sender-to-receiver route |
| nmos_disconnect | Plan or execute a disconnect |
| nmos_stage_connection | Stage a route without activating it |
| nmos_activate_staged | Activate a staged route |
| nmos_get_connection_status | Get receiver connection status |
| nmos_get_sender_status | Get sender status |
| Channel Mapping (3) | |
|---|---|
| nmos_get_channel_map | Get an IS-08 channel map |
| nmos_set_channel_map | Set an IS-08 channel map |
| nmos_get_io_map | Get an IS-08 I/O map |
| Monitoring (4) | |
|---|---|
| nmos_health_check | Get health information |
| nmos_get_clocks | Get clock information |
| nmos_get_transport_params | Get transport parameters |
| nmos_audit_connections | Audit receiver connections |
| Batch (2) | |
|---|---|
| nmos_batch_connect | Plan or execute batch routing |
| nmos_export_topology | Export Aurora facility topology |
| Aurora Phase 3 (3) | |
|---|---|
| aurora_audit_recent | Recent audit-journal entries |
| aurora_system_status | IS-09 system parameters (PTP domain, syslog, registries) |
| aurora_replay_snapshot | Replay a batch_snapshot from the audit journal to restore prior subscriptions |
Vendor strategy
Lawo
IS-04/05Ember+
HOME 10.6+ routes 2110 flows through IS-04/05. Ember+ via scoreMaster and mc² numeric leaves drives console parameters and legacy bridges.
Console arbitration can silently override Ember+ writes — write loop requires re-read verification, deferred to Phase 4.
Calrec
IS-04/05Ember+Hydra2
ImPulse routes 2110 through IS-04/05. Hydra2 BoxID/Device/Port triplets surface via Ember+; H2O label overlays carry operator naming.
H2O label overlays make identifier strings unstable across consoles — atomic alias writes are the Phase 4 target.
Studer / Evertz
IS-04/05Ember+
Vista exposes per-channel-flat Ember+ trees; Route 3000/6000 expose proper matrices. 2110 flow routing through standard IS-04/05.
Per-channel-flat tree projection differs from matrix-shaped peers — SemanticHintRules carry vendor-specific path rewrites.
Grass Valley
IS-04/05Ember+NP0017
AMPP / Orbit ship native 2110 via IS-04/05. Ember+ tree exposes frame/slot/card paths; NP0017 governs writes.
NP0017 requires User-ID Lock/Protect/Release acquisition before any write — protocol-aware acquisition is Phase 4.
Phase 4 preview
First Vendor Write
Pick Lawo or Calrec. Ship the full plan → stage → activate → verify loop with adapter-specific verification: re-read after write for Lawo; H2O atomic alias write for Calrec.
In-House s101/BER Stack
Replace emberplus-connection with ~1500–2000 LOC in-house transport. Removes the only git-URL transitive dependency we ship; substrate for GV NP0017 Lock/Protect/Release.
IS-12 / MS-05-02 Adapter
NMOS Control Protocol — the AMWA-blessed peer to Ember+ for device-level parameter control. Aurora is well-positioned to be the first orchestrator with both adapters behind one canonical model.
Principles
- Equal-first vendor modeling. No vendor is privileged in the canonical model. Per-vendor specifics live in adapters and SemanticHintRules, not in the core types.
- Honest failure-mode surfacing. The compatibility engine emits typed issue codes (constraint_set_no_match, transport_mismatch, clock_domain_mismatch, restore_failed_compat) so operators and agents both see why a route was rejected.
- dry_run is a first-class citizen. Every write tool accepts it. The audit journal does not store dry-run records. Plan-mode is how an agent asks “what would happen if I did this?”
- Audit before acting, audit after acting. Every state-changing operation appends to the journal with actor and source_interface. Snapshot records exist precisely so you can unwind without inventing your own log.
- Bilingual output as a baseline. Every tool returns {en, fr} LocalizedText. Not for two markets — for the discipline of writing both human-readable text and structured data on every call.
- Pin everything pinnable. GitHub Actions are SHA-pinned (dep-guard pre-commit hook enforces this). Docker images in CI are digest-pinned. npm dependencies use exact versions where supply-chain risk warrants.
- Tests prove the seam. The same tests run against the in-process Ember+ tree provider, the real Sofie provider against an in-process EmberServer, and (in CI) the real rhastie/nmos-cpp registry. Swap the adapter, run the same tests, ship.