Skip to main content
Glama
industrial-aiops

OT-AIops Energy

Related Servers

Alternatives to OT-AIops Energy

  • A
    license
    B
    quality
    A
    maintenance
    Provides AI agents with safe, governed read access to industrial control systems (OPC-UA, Modbus, S7, Mitsubishi, MTConnect, MQTT/Sparkplug) plus cross-protocol diagnostics for troubleshooting data breaks, alarm floods, and unhealthy tags.
    2
    153
    2
    MIT

Related Servers

  • A
    license
    B
    quality
    A
    maintenance
    Exposes a deterministic IoT edge runtime — Modbus/CAN/J1939 acquisition, local rules, alarms, and history — to AI assistants as typed, governed MCP tools. Reads are safe by default; device control stays deny-by-default, explicitly confirmed, and audited.
    23
    3
    Apache 2.0
  • A
    license
    Not graded
    quality
    C
    maintenance
    The first and only MCP server for PLC (Programmable Logic Controller) intelligence. Give any AI agent direct access to industrial automation data — ladder logic, tag databases, cross-references, fault root cause analysis, and sequence blockers
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    Connects AI agents to energy infrastructure with 30+ tools for managing sites, assets, dispatch, settlements, compliance, and carbon tracking.
    34
    23 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    87+ specialized tools for German and European energy data. Direct AI access to Marktstammdatenregister (MaStR), ENTSO-E, Redispatch 2.0, and Grid Operations for utilities and datacenters.
    2
    GPL 3.0
  • F
    license
    A
    quality
    C
    maintenance
    A secure, read-only MCP server for AI-powered system monitoring. It provides real-time OS metrics, config discovery, and safe log tailing to enable autonomous infrastructure audits without shell access risks.
    4
    1
    -

TDQS

A3.8/5.0

Scored across 59 tools

Disambiguation2/5

Many tools analyze alarm/health data with overlapping inputs (e.g., alarm_bad_actors, alarm_flood_analysis, alarm_cascade, alarm_rationalization_worksheet; health_summary, tag_health, historian_health, data_quality_scorecard). Deprecated tools like health_summary and anomaly_scan redirect to non-existent replacements, increasing ambiguity. While many tools are distinct, the boundaries between several analytics tools are unclear.

Naming Consistency4/5

Tool names are predominantly snake_case with a consistent verb_noun pattern (diagnose_dataflow, monitor_changes, oee_compute, compliance_report). Protocol-specific prefixes (iec61850_, iec104_, dnp3_) and domain prefixes (plc_program_, compliance_) are used consistently. Minor deviations like protocols_supported, health_summary, and rca_corpus_from_maintenance do not break the overall pattern.

Tool Count2/5

59 tools is well above the 25+ threshold for 'too many'. While the domain is broad (multiple industrial protocols, analytics, compliance, PLC analysis), the count is excessive and many tools are deprecated or overlapping. A more focused set of 15-20 tools would be more coherent.

Completeness3/5

The set covers a wide range of operations: protocol reads, diagnostics, analytics, compliance, historian, fleet, PLC program analysis. However, several tools reference missing components (e.g., opcua_discover_tags, modbus_apply_template, opcua_health_summary) and deprecated tools point to non-existent replacements, creating dead ends. Core workflows exist but gaps in referenced helpers prevent full coverage.

Maintenance

ActivitySlowing
ResponsivenessNo issues