Scored across 155 tools
The ~12 protocol families (modbus_*, s7_*, opcua_*, etc.) are cleanly separated by prefix, but the analytics layer has several overlapping clusters: four alarm tools (bad_actors, flood_analysis, cascade, event_clusters) differ in subtle ways, deprecated twins health_summary/anomaly_scan duplicate their opcua_* successors, and uns_schema_drift vs uns_live_drift vs sparkplug_live_schema have fuzzy boundaries. An agent would frequently need the description text to pick correctly between these.
Some families are exemplary (modbus_read_holding/input/coils/discrete, opcua_read_node/read_many), but the overall convention is mixed: verb-first (diagnose_dataflow, export_data, adopt_alias_map) coexists with noun-first (baseline_learn, mechanism_library_check, uns_topic_audit). The same 'device identity' operation is also named inconsistently across protocols: cpu_info, cpu_status, controller_info, master_info, server_info.
155 tools is far beyond what an agent can hold in context, well past the 50+ threshold for an excessive count. The number is only somewhat defensible because much of it is near-identical read/write patterns repeated across ~12 protocols — a surface that would be far more usable split into per-protocol sub-servers or parameterized behind a single protocol argument.
Coverage is unusually deep: PLC programs get outline/section/xref/visibility/snapshot/drift/history, baselines get learn/check/status/contextual variants, and UNS gets browse/audit/drift/live-capture tools. Real gaps exist — there is no way to add to the mounted mechanism library (only list/check), and OPC-UA/Modbus have no write tools (likely deliberate) — but agents can work around these.