Skip to main content
Glama
OT-AIops

OT-AIops

plc_program_snapshot

Read-only

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

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),
        under $IAIOPS_HOME, the config dir or an IAIOPS_AGENT_READ_DIRS dir.
    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="~/.iaiops/plc/Line3.scl", label="approved v3.2").

Input Schema

NameRequiredDescriptionDefault
nameNo
noteNo
pathYes
labelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.26.0

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the readOnly/openWorld hints: exactly what is persisted (block names, hashes, counts — 'never a declaration, a source line or a comment'), what the fingerprint deliberately ignores (line numbers, comments, block order), content size and path constraints, and the idempotency rule that a byte-identical re-snapshot records nothing. The self-label '[READ][risk=low]' is consistent with readOnlyHint=true and destructiveHint=false in spirit — it is read-only with respect to the PLC, mutating only its own local store.

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?

Front-loaded with the read/risk tag and the one-line purpose, then Args, Returns and an Example — easy to scan. The preamble about control programs being controlled documents and 'somebody remembers' is rationale rather than operative instruction and is the one block that could be trimmed without losing callable information.

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

Completeness4/5

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

With no output schema, the description supplies the full return shape (status recorded/unchanged, snapshot fields, block_count, previous_snapshot) and documents every argument, which is enough to call and interpret it. The only missing piece is the follow-on: it does not say which sibling consumes the baseline (plc_program_drift, baseline_check) or how errors such as an out-of-root path surface.

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 must carry all parameter meaning and it does: path gets accepted extensions, existence and ≤5 MB constraints plus the allowed directory set; name explains the default (file stem) and why identity should be stable across exports; label and note are shown with a concrete example value. This is more than the schema conveys and directly resolves the ambiguity in 'name'.

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?

States a specific verb and resource: records an exported program's structure as a change baseline, and immediately qualifies the scope (exported file, never a live PLC upload). That scope line alone separates it from read-oriented siblings such as plc_program_drift, plc_program_history and s7_read_area without opening a schema.

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?

Gives clear invocation context (must be an already-exported file under one of the allowed roots) and an explicit exclusion ('never a live PLC upload'), plus the note that re-snapshotting an identical file is a no-op. It stops short of naming a sibling to use instead for the adjacent jobs — comparing baselines (plc_program_drift / baseline_check) or writing a change record (baseline_record_change) — so routing between the baseline family is left to the agent.

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