An MCP server that runs inside the station and gives an AI agent discovery-driven control of a live Niagara system: read and query everything, build wiresheet logic, provision histories, generate PX pages, and run a monitor and remediation autopilot. Every write sits behind an explicit gate, runs bound to a real Niagara user, and is audited.
Reaching Every Module Without Writing an Adapter Per Module
A typical install carries several hundred modules, many of them per-vendor driver families. Writing a hand adapter for each is neither possible nor necessary, because Niagara is a uniform component model: a BACnet network, a control loop, an alarm class, a history extension, a PX view, a schedule and a program are all components with typed slots, addressable by ORD and registered in a global type registry.
One generic control layer therefore reaches any type in any module. It creates components, sets slots, invokes actions, links wiresheet slots, and removes them again, with BQL for anything queryable. Typed adapters are added only where ergonomics or a non-slot API justify one.
Discovery First, So the Agent Knows What Exists
An agent cannot plan against a station it cannot see. Read tools expose the live registry and schema before anything is created:
- Module enumeration across the installed registry, with name, vendor and profile.
- Type listing of instantiable specs, scoped by module or by base type, so an agent can ask for every subtype of a control point.
- Slot reflection on a transient, unmounted instance, so the agent learns a type’s properties, defaults and actions before it creates a real one.
- Component tree, search and BQL for reading the station as it currently stands.
That turns the control layer into a self-describing surface: discover a type, read its slots, create it, configure it, link it, invoke it.
The Safety Model
Consequences here are physical, so the guardrails are structural rather than advisory.
- Capability gates default to off and fail closed. BACnet discovery, security writes, module installation, station administration and performance telemetry each have their own gate. Calling a gated tool while its gate is off names the exact property and runs nothing.
- Writes are bound to a real Niagara user and run under that user’s permissions, not an ambient service identity.
- The audit record is a tamper-evident hash chain that can be re-verified on demand, rather than a log file anyone can edit.
- Backups precede saves, revision history is bounded and restorable, and patches roll back atomically if they fail partway.
What Else Ships With It
- BOG editor with a file browser, session locks, backups, a collapsible visual tree, typed slot and component editors, raw XML tools with pre-decode danger scanning, ORD rewrite, structured patch preview and apply, visual diff, revision inspect and restore, compare, reports and exports.
- Autopilot for autonomous monitoring and remediation, and notifications that contact people when something needs a human.
- Utility services: BQL results exported as JSON, an FTP server, an MQTT publish and subscribe client, a JSON-over-HTTP batch API, SSH and SFTP, and zip packaging of station files.
Status
This is our own module, developed in house and demonstrated on a live station. It is not a shrink-wrapped product you can download today. If it is relevant to an estate you run, tell us what you are trying to automate and we will show you the tool surface, the gates and the audit trail in operation, and give you an honest view of what would be involved.