Skip to main content
Glama
industrial-aiops

OT-AIops

by industrial-aiops
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

plc_program_snapshot

Read-only

Record an exported PLC program's structure as a change baseline, using content hashes and block fingerprints to detect undocumented modifications without storing source code.

Instructions

[READ][risk=low] Record an exported program's structure as a change baseline.

A control program is a controlled document, and the usual way an undocumented
change to one gets noticed is that somebody remembers. This gives the
comparison a number: the file's SHA-256, plus a per-block structural
fingerprint (name/kind/language, declared variables, calls, branch conditions,
timers) that deliberately excludes line numbers, comments and block order — so
adding a comment at the top of a file does not report the whole program as
changed. Stored locally under the iaiops home as block names, hashes and
counts — never a declaration, a source line or a comment — so the store is not
a second copy of the program. Reads the named EXPORTED file only; never a live
PLC upload.

Re-snapshotting a byte-identical file records nothing and says so — a history
padded with identical rows hides the rows that are not.

Args:
    path: Exported program file (.st/.scl/.awl/.l5x/.txt; must exist, ≤5 MB).
    name: Program identity across exports. Defaults to the file's stem, and
        the result says which was used — the export path changes every time
        somebody opens the engineering station, the program does not.
    label: Short label, e.g. "approved v3.2 / MOC-118".
    note: Free note recorded with the snapshot.

Returns dict: {status ('recorded'|'unchanged'), program, name_source,
    snapshot:{snapshot_id, taken_at, source_file, content_sha256, label, note},
    block_count, snapshot_count, previous_snapshot}.

Example: plc_program_snapshot(path="~/exports/Line3.scl", label="approved v3.2").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
noteNo
pathYes
labelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.26.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true and destructiveHint=false; the description adds substantial behavioral context: the fingerprint deliberately excludes line numbers/comments/block order so cosmetic edits don't flag a change, the store keeps only hashes and counts (never source), and re-snapshotting a byte-identical file records nothing and returns status 'unchanged'. This goes well beyond the annotations and matches them — no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but visibly structured: purpose tag, rationale, behavioral notes, labeled Args/Returns sections, and a worked example. It is front-loaded with the core purpose. The controlled-document rationale paragraph is somewhat verbose, and the length is justified by the tool's nuanced baseline semantics, but it could be tightened without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with no output schema, the description is complete: it documents every parameter with constraints, specifies the exact return dict shape including status values, discloses side-effect-free storage behavior, states the idempotency semantics, and gives a call example. There are no schema or annotation gaps left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden — and it succeeds. Each parameter gets real meaning: path gains file extensions, existence and ≤5 MB constraints; name gains cross-export identity, stem default, and the name_source feedback behavior; label gets a concrete example; note gets a purpose. This fully compensates for the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The lead sentence states a specific verb and resource: 'Record an exported program's structure as a change baseline.' The scope is sharply differentiated from siblings like plc_program_drift (compare against a baseline) and plc_program_history (show past snapshots) by making the recording role explicit. The '[READ][risk=low]' tag and 'never a live PLC upload' also pin down what the tool is and is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool — establishing a baseline for a controlled program document — and states exclusions ('Reads the named EXPORTED file only; never a live PLC upload'). However, it never explicitly names sibling alternatives such as plc_program_drift or plc_program_history for the comparison side of the workflow, leaving the agent to infer the full workflow from the baseline semantics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools