Industrial-AIOps MCP server

<!-- mcp-name: io.github.industrial-aiops/iaiops -->

Industrial-AIOps

English · 中文

Ask an AI agent why the line stopped — and get an answer that cites its evidence.

A vendor-neutral, read-first data tap for the factory floor. It speaks 14 field protocols, correlates what it reads across them, and hands your agent an evidence-cited verdict instead of a guess. Every call is audited, and no reading ever phones home.

pip install "iaiops[opcua]"      # pick your protocol — or [all]
iaiops init                      # write ~/.iaiops/config.yaml
iaiops doctor                    # check the setup before you trust it

Prefer a container? The published image is cosign-signed and runs non-root. It speaks MCP over stdio, so keep stdin open and mount a volume for the audit store:

cosign verify --key deploy/margo/cosign.pub ghcr.io/industrial-aiops/iaiops:0.28.0-factory
docker run -i --rm -v iaiops-state:/home/iaiops/.iaiops \
  ghcr.io/industrial-aiops/iaiops:0.28.0-factory

For a hardened or air-gapped deployment (read-only rootfs, capdrop: ALL, no-new-privileges, optional on-box LLM) use deploy/margo/compose.yaml and deploy/airgap/. The analysis engine needs no GPU and no model API — it is deterministic; an LLM is optional and only phrases* the verdict.

What you get

Ten per-industry editions ship in this package — fab · factory · process · building · water · warehouse · clinical · pharma · renewables · plcnext — each adding its own read-only advisory checks. Substation / utility telecontrol (IEC-104 · DNP3 · IEC-61850) ships separately as iaiops-energy.

Your first five minutes

Four commands. Only one of them touches a device, and it prints what it will send before it sends anything.

pip install "iaiops[modbus]"     # pick the protocol you actually have, or [all]
iaiops onboard status            # ← run this first. Contacts NOTHING.
iaiops doctor                    # config, secrets, reachability — and the version
iaiops readiness                 # every scenario, and what each gap needs

onboard status answers the smaller questions you have first: which journey is this site on — reading its devices directly, or subscribing to a UNS broker its data already flows through — which step of it are you on, and what is the one command that advances it? It is derived from your store and config.yaml every time. The one thing it keeps is a namespace audit verdict, and that counts only for the broker and topic filter it was taken on and always shows its age — so edit config.yaml by hand and the answer stays true.

readiness reads your config and local store and answers one question: which scenarios can this site run today, and what does each gap need? Every gap comes with the command that closes it, ranked by how much it unlocks. No agent, no cloud, no account, and nothing on the wire.

Shortened. The full README is on GitHub.