Log inSubmit server
OT AIops — Energy edition logo

OT AIops — Energy edition

Industrial-AIOps energy edition: IEC-104/DNP3/IEC-61850 read-only OT connectors on iaiops.core.

InstallRepositoryWebsite
Full README Compare alternatives Embed widget Claim this listing

Install OT AIops — Energy edition

Pick your client, then add it in one click or paste the config.

STDIOPython
~/Library/Application Support/Claude/claude_desktop_config.json
claude_desktop_config.json
{
  "mcpServers": {
    "ot-aiops-energy-edition": {
      "command": "uvx",
      "args": [
        "--from",
        "iaiops-energy",
        "iaiops-energy-mcp"
      ]
    }
  }
}

Settings → Developer → Edit Config, merge this into mcpServers, then fully quit and reopen Claude Desktop.

Automated check passed— started and listed 81 tools correctly (3d ago).

Overview

Tools81

What OT AIops — Energy edition lets your agent do. Expand a tool for its parameters.

Verified live~31.4k tokens of context

Security & health

What it can reach and how reliably it runs — from our own checks, not the maintainer’s claims.

ActiveLast checked Today

Recent health check succeeded.

9/9 checks healthy over the last 46d

What it can do

From the 81 tools this server returned when we ran it; 81 declare their own safety hints.

Handles credentials · 6Makes network requests · 81Read-only tools · 81
Network at startup2 connections
Files written at startup17

Observed 2026-10-25 in an isolated sandbox. A description of reach, not a security audit.

Supply-chain signal

No high-severity advisories surfaced by our automated scan.

Critical 0High 0Medium 0Low 0

Scanned 2d ago via OSV.dev · iaiops-energy (PyPI)

Adoption & maintenance

Factual signals from GitHub, npm, and our automated checks — not a rating.

GitHub stars1Stargazers on the source repository.
Last commit10d agoMost recent push to the default branch.
Availability100%Our rolling endpoint + install checks that succeeded.
Install checkPassedOur sandbox started it and listed its tools.
Tools exposed81Callable tools this server registers over MCP.
Directory activity1 viewsConfig copies, upvotes, and views on AllMCPs.

From the project README

industrial-aiops-energy — Energy Edition (Substation / Utility)

English · 中文

The energy edition of Industrial-AIOps, split out into its own repo: read-only OT connectors for substation / utility telecontrol protocols, built on top of iaiops.core.

  • IEC 60870-5-104 (c104) — RTU / substation telemetry
  • DNP3 / IEEE 1815 (pydnp3) — outstation monitoring
  • IEC 61850 MMS (pyiec61850, linux-only wheel) — substation IED reads

It reuses the base package's shared governance (audit / budget / risk-tier / undo), cross-protocol brain (data-flow / alarm / OEE / downtime RCA on the normalized ISA-95/18.2 model), and MCP server infrastructure — this repo only adds the three energy connectors + their session builders + MCP tools. Read-first: no control-direction writes are exposed.

Current release: 0.2.0 (requires iaiops>=0.29.0,<1.0; tested against iaiops 0.31.0). On the wire: 80 tools, 75 read-only, 0 destructive (the energy connectors plus the base brain tools mounted on this server). New in 0.2.0 — every MCP call on this server is audited with which front-end and which client made it (origin=mcp, the client's self-reported name, one id per connection); before this, calls here reached the trail as origin unknown. Upgrade note: iaiops 0.29 hashes those fields into the audit chain, and an older base verifying a trail 0.29 has written to reports row_hash mismatch — so upgrade every process sharing one IAIOPS_HOME (this server, iaiops-mcp, the CLI, enterprise) together. The base's new HTTP bearer-token requirement does not apply here: this server speaks stdio only. See CHANGELOG.md. Previously in 0.1.12 — the package reports its own version: __version__ had been hard-coded at 0.1.3 for eight releases, and the MCP handshake reported the SDK's version as this server's; both now come from the installed package metadata. Previously in 0.1.11 — all three monitor paths are CI-gated for the first time, and a skipped live test now fails the build instead of passing it. DNP3 was the holdout: pip install pydnp3 fails on any current Linux, so this repo inherited the ecosystem's "unbuildable on hosted runners" and tests/test_dnp3_live.py skipped on every build. It is not unbuildable — opendnp3 compiles clean, and the 2019 binding layer needed three mechanical fixes, now scripted in scripts/build_pydnp3.sh and running on real GitHub runners. Also inherits two governance fixes from iaiops 0.20.3 (pin raised): a call that failed is no longer audited as a success (which also mis-informed the pattern circuit breaker on every failure), and the runaway guard can now see a caller retrying a denial forever. Previously in 0.1.10 — a security fix inherited from the base package: three egress tools this edition mirrors (stream_publish, stream_publish_event, historian_push) wrote their credential — a NATS auth token, a TSDB password — into the audit log in the clear, and audit_forward shipped that row to the configured SIEM. They are defined in iaiops, so this edition could not fix it alone; the pin moves to iaiops>=0.20.2, and a contract test now fails the build if the whole registered surface ever again carries an undeclared credential parameter. If you have passed a token or historian password to these tools, rotate it and check existing audit rows. The energy connectors themselves take no credential parameters. Previously in 0.1.9 — every tool ships the MCP ToolAnnotations hints (readOnlyHint / destructiveHint / openWorldHint), derived from the @governed_tool harness rather than hand-written, so a client can tell a monitor read from a tool that acts without parsing the [READ]/[WRITE] docstring tag. On the wire that was (in 0.1.9) 59 tools, 55 read-only and 0 destructive — this edition exposes no control direction, and that is now enforced by a test rather than only documented. They are hints, not a gate: the MCP spec forbids relying on annotations for security decisions, and enforcement stays in @governed_tool. The base pin moved to iaiops>=0.20.1 so the hint derivation is imported from mcp_server.hints instead of duplicated here.

Previously in 0.1.8 — the base IAIOPS_READ_ONLY gate was removed in iaiops 0.19.0 (read/write authorisation is the caller's decision — agent judgement / account management — not the tap's; every tool is governed and audited via the base @governed_tool harness), so this edition drops it too. It keeps the IAIOPS_NO_EGRESS=1 gate — a data-exfiltration / airgap axis that withholds data-shipping tools from list_tools() at registration time. This edition runs its own FastMCP instance, so the gate is wired into its own main(); without it IAIOPS_NO_EGRESS=1 would still expose historian_push, rca_narrate and the stream_publish* pair mirrored in from the base brain. The energy connectors themselves are monitor-only and survive the gate intact. See CHANGELOG.md.

Previously in 0.1.6 — an audit-hardening pass over the three read-only connectors: DNP3 no longer reports an offline outstation as online or returns a partial integrity-poll database; IEC-61850 gained a bounded connect/request timeout and stopped fabricating 0.0/empty-success on failure; the substation analyzer no longer calls a lone breaker-open a "selective trip"; tests isolate IAIOPS_HOME; and the base pin was raised to iaiops>=0.14 so the governance endpoint-scoping fix applies. See CHANGELOG.md §0.1.6. (0.1.5 verified the IEC-104 monitor path — a real c104 client↔server round-trip in a Linux container, tests/test_iec104_live.py.) Physical RTU / IED remains unverified. Since 0.1.3 the server has its own MCP identity — iaiops-energy-mcp runs a dedicated FastMCP("iaiops-energy") instance with energy-specific instructions (IEC-104 / DNP3 / IEC-61850, read-first, no control/operate), with the base cross-protocol brain tools mirrored onto it — plus an edition skill (skills/iaiops-energy/SKILL.md, anti-drift-tested against the registered tool surface) and protocol-consistency contract tests (every tool must carry the governance marker, a [READ]-style risk tag, an Args: section, and the canonical {error, hint} error shape; the server refuses to start if any registered tool lacks the governance marker).

🧪 Beta testing & co-creation

Live substation RTU / IED / IEC-104 field testing is what this package needs most. The IEC-104, DNP3 and IEC-61850 monitor paths are library-loopback-verified, and all three now run on every CI build — a skip fails the build rather than passing it. (Since 2026-08-01: DNP3's evidence used to be a single manual run on 2026-07-02, because pydnp3 was believed unbuildable on hosted runners. That belief was wrong — see scripts/build_pydnp3.sh.) Real RTU / IED hardware remains unverified. If you can run iaiops doctor against real substation gear in an authorised test environment, we would very much like to hear the result — verified devices are credited by name in the support matrix. Report results (protocol + device model + iaiops doctor output) via the base repo's pinned issue: 👉 industrial-aiops#28 — Call for field-testing partners (v0.10.0)

Why a separate repo

Energy targets a distinct buyer (utilities / substations), has heavier platform-specific deps (pyiec61850 is a linux-only SWIG wheel; pydnp3 builds a native ext), and its own compliance surface (China's Security Protection of Power Monitoring Systems regime). Splitting keeps the base install light. See the base repo's docs/ENERGY-SPINOUT.md for the plan.

Install

Terminal
pip install iaiops-energy[energy]      # all three energy protocols
pip install iaiops-energy[iec104]      # just IEC-104

iaiops-energy pulls in iaiops (the shared core) automatically.

Use (MCP)

bash
iaiops-energy-mcp                       # brain + energy tools over stdio

Point a target at your substation gear in ~/.iaiops/config.yaml (protocol: iec104|dnp3|iec61850, host, port, common_address / unit_id).

Edge deployment & ecosystem (edge-native / Margo)

Like the base package, the energy edition rides on a hardened, centrally-managed edge host as a portable, governed edge application — mapping onto the Margo edge-interoperability roles (immutable host · compliant orchestrator · iaiops-energy = the OT-domain app), deployable as an OCI Managed Container (outbound-only to substation RTUs/IEDs, no inbound). A container + margo.org/v1-alpha1 application-description skeleton is in deploy/margo/; the full alignment + honest gap analysis lives in the base repo's docs/MARGO-ALIGNMENT.md. The descriptor is validated against Margo's published margo.org/v1-alpha1 LinkML schema on every PR (CI job margo-descriptor) and passes clean — structural validity only, see deploy/margo/schema/PROVENANCE.md.

Honest status: a natural Margo edge application, but NOT Margo-compliant yet — image build, hosted+signed package, and a published conformance result are roadmap ⏳. No claim of compliance until that result exists, and the schema pass above is not a step toward it: the compliance test suite cannot be run today because it does not exist yet (no conformance repo in the margo org; a first PR1 vertical slice was still being scoped as of 2026-01-15).

Validation status (honest)

Read the full README View source on GitHub

Reviews

No reviews yet — be the first to share how it worked for you.

Frequently Asked Questions about OT AIops — Energy edition

OT AIops — Energy edition is an MCP server that provides read-only monitoring connectors for IEC 60870-5-104, DNP3/IEEE 1815, and IEC 61850 MMS in substation and utility environments. Built on iaiops.core, it also exposes shared governance and normalized cross-protocol analysis tools. It communicates over stdio and exposes no control-direction writes.

The server supports IEC 60870-5-104 for RTU and substation telemetry, DNP3/IEEE 1815 for outstation monitoring, and IEC 61850 MMS for substation IED reads. The IEC 61850 connector uses a Linux-only pyiec61850 wheel.

Yes, the energy connectors are read-only and expose no control-direction writes. The 0.2.0 release reports 80 tools, including 75 read-only tools and 0 destructive tools; the remaining tools are part of the shared base infrastructure.

The current release is 0.2.0 and requires iaiops>=0.29.0,<1.0; it was tested against iaiops 0.31.0. The server communicates over stdio, and IEC 61850 support requires its Linux-only pyiec61850 wheel.

Every MCP call is audited with origin=mcp, the front-end's client-reported name, and one identifier per connection. Because iaiops 0.29 hashes these fields into the audit chain, processes sharing one IAIOPS_HOME should be upgraded together.

Related MCP servers

All in Industrial & IoT All alternatives
Add a badge to your READMEShow it’s listed — live SVG, Markdown or HTML.

AllMCPs Directory Badge

Full Badge Customizer

Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.

Badge Style:
Live Dynamic SVG PreviewOT AIops — Energy edition AllMCPs Directory Badge
Markdown (GitHub README)
[![AllMCPs](https://allmcps.com/api/badge/ot-aiops-energy-edition?style=directory)](https://allmcps.com/mcp/ot-aiops-energy-edition)
HTML Embed
<a href="https://allmcps.com/mcp/ot-aiops-energy-edition"><img src="https://allmcps.com/api/badge/ot-aiops-energy-edition?style=directory" alt="OT AIops — Energy edition on AllMCPs" /></a>