Skip to main content
Glama

twincat-mcp

One MCP server, one Python process, full reach into a Beckhoff TwinCAT 3 setup:

Layer

What the agent can do

Backend

Runtime (target IPC)

PLC/system state, symbol browse, typed read/write (structs, arrays, TIME/DATE decoded), raw index-group access, polling trace, wait-until, run/stop/reset, RUN↔CONFIG mode, EtherCAT master state, routes

pyads (ADS)

IPC file system / OS

read/write/list/delete files on the target over ADS (TcUnit results, logs, boot dir), start a process, reboot

ADS System Service (port 10000)

Engineering (XAE)

attach to the running XAE shell, open/build with file:line errors, PLC login/start/stop, set target, activate configuration, restart TwinCAT, one-shot deploy, System Manager tree read/write (XML), create/edit POUs in place, PLCopen import/export, boot project

TE1000 Automation Interface over COM (pywin32)

Real-time recorder

continuous capture of online variables while the program runs — PLC-timestamped ADS notifications (cycle or on-change) or polling, hours long, file-backed; live snapshot/stats while recording; scope-style start/stop triggers with pre-trigger; CSV export; pulse/dwell and edge-to-edge latency analysis

pyads notifications

Test bench

scripted scenarios (writes + expectations + parallel recording), assertions with wait, settle checks, stimulus→response latency, RPC method calls, task timing/load, snapshots for regression

ADS

Project files (offline)

index .TcPOU/.TcDUT/.TcGVL/.TcIO, code with line numbers, ADS symbol → file:line resolution, regex search, references, call graph, FB interface summary, lint, write-back with LineIds hygiene, TcUnit suite scaffold

XML + regex, no XAE needed

TcUnit

build → boot → activate → restart → fetch xUnit XML from the target → pass/fail summary

all three

Experiments

spec (factors × levels, runs, preconditions, stimulus, done condition, measures, metrics, criteria, allowed writes) → background runner with snapshot + capture profile per run, factor restore, abort → metrics with 95 % CIs (t / χ²), Cpk → pass / fail / inconclusive with the n that would settle it → Markdown + HTML report with identity, charts, audit trail and a separately-labelled interpretation; compare two experiments with error bars

recorder + bench + SQLite-free JSONL

Reference (Infosys)

TwinCAT 3 documentation lookup that cannot be incomplete: books and pages from infosys.beckhoff.com's own sitemap, per-library local index (FTS5), symbol search, FB/struct/enum declarations as data with the page's descriptions, code-example search, any page as Markdown; web fallback verified against the sitemap

urllib + SQLite, no index to ship

Runs on the engineering PC (Windows, TwinCAT XAE installed) and talks to the IPC through the TwinCAT router. No C# helper, no daemon, no PowerShell, no vector DB.


Why another one

Existing servers each cover a slice; this one was built after reading all of them:

Server

Gap this project closes

malcolm-mill/beckhoff_mcp (pyads, read-only)

writes, structs/arrays, TIME/DATE decoding, watch/trace, XAE, files on target

Edge-JB/TwinCAT-XAE-MCP (Node + .NET daemon, XAE only)

needs an MSBuild step and the 64-bit shell; no runtime reads, no TcUnit. Confirmation-token and safety-project ideas kept.

idomp/twincat-mcp-public (Python + C# TcAutomation.exe)

needs MSBuild + Windows PowerShell 5.1 to build the helper. Arm/confirm + persistent-shell + TcUnit flow kept, in pure Python.

Auda29/twincat-mcp-mono (TypeScript ADS)

three-gate write model kept (mode + runtime + allowlist); XAE/files added.

agenticcontrolio/twincat-validator-mcp

evaluated 2026-10 and not adopted: its LineIds model (one entry per block, Ids from 1), an invented OVERRIDE marker, "base FB must be nearby" and "undeclared target" for FB members inside methods all fire as errors on real XAE files, and its default autofix re-indents every tab-indented line. The ideas that hold (interface contract, __NEW/__DELETE pairing, unsigned-loop wrap, abstract instantiation) are proj_lint rules here, resolved against the project index so library bases produce info, not false errors.

idomp/twincat-index-mcp

semantic search needs Qdrant + embeddings. Here: deterministic symbol-to-source resolution instead.

Infosys documentation servers (infosys_search / infosys_get_page style, pre-built index)

the shipped index is whatever the author crawled: tested one has no Tc2_System at all (ADSREAD → nothing, get_page → "not found" for a live page), duplicate ?id= URLs, BA2 functions ranked above TON. Here the page list comes from the site's sitemap and pages are fetched live, so an existing page can never be "not found"; TwinCAT 2 books are filtered out.

Extra: human-in-the-loop via MCP elicitation — when the client supports it (Claude Code does) the destructive tools ask you in the client UI; the token flow is only the fallback.


Related MCP server: te1000-mcp

Requirements

  • Windows 10/11 engineering PC with TwinCAT XAE 3.1.4024+ (XAE Shell, 32-bit TcXaeShell.DTE.15.0, or 64-bit 4026 TcXaeShell.DTE.17.0, or VS 2019/2022/2026 with TwinCAT).

  • Python 3.12 64-bit (the one version the project targets and tests; 3.12 or newer is accepted, older ones are refused with a message). pywin32 and pyads are installed by pip.

  • An ADS route from this PC to the target (XAE → Choose Target → Add Route). ads_routes lists what exists.

  • Open the solution in XAE before using xae_* tools; the server attaches to the running instance (it can launch one, but attaching is faster and visible).

Linux/macOS: only proj_*, tcunit_results(local_path/xml_text) and the safety tools work. Everything else needs the router/COM.

Install

Three ways. All need a 64-bit Python 3.12 on the engineering PC; nothing else is installed by hand — the launcher (scripts/launch.py) creates a private venv on first start and reinstalls only when the shipped sources change.

The repo is its own plugin marketplace (.claude-plugin/). Inside Claude Code:

/plugin marketplace add Disectron/twincat-mcp-server        :: GitHub; or a local clone: /plugin marketplace add C:\tools\twincat-mcp
/plugin install twincat-mcp@twincat-mcp

One step on Claude Code ≥ 2.1.275: /plugin install twincat-mcp --marketplace Disectron/twincat-mcp-server. The plugin brings the MCP server (named twincat, tools appear as mcp__plugin_twincat-mcp_twincat__<tool>), two skills — twincat-mcp (tool chains) and twincat-docs (offline Beckhoff documentation, below) — and the 5 prompts. /plugin configure twincat-mcp@twincat-mcp sets the Python executable (default python), default AmsNetId, start/ceiling safety mode and an optional config TOML; everything project-specific (solution path, allow/deny lists, HMI root) comes from twincat_mcp.toml in the folder you start claude in. First start takes about a minute (venv + pip); if that first session reports the server as failed, the venv is already there — start a new session. The venv lives in ~/.claude/plugins/data/twincat-mcp-twincat-mcp/venv and survives plugin updates.

B. Claude Desktop bundle

scripts\build-mcpb.cmd produces dist\twincat-mcp-<version>.mcpb (or take the one from a release). Claude Desktop → Settings → Extensions → drag the file in. The install dialog asks for the solution, AmsNetId and safety modes. Windows only (the bundle runs cmd /d /c server\launch.cmd, which finds py -3, python or %LOCALAPPDATA%\Programs\Python). Logs: %APPDATA%\Claude\logs\mcp-server-twincat-mcp.log.

C. By hand (any MCP client, development)

git clone <this repo> C:\tools\twincat-mcp
cd C:\tools\twincat-mcp
scripts\install.cmd            :: venv + pip install -e .[dev] + prints effective config
.venv\Scripts\python -m pytest :: 159 tests, all mocked, run anywhere
cd C:\Projects\DrumFilling
claude mcp add twincat -e TCMCP_SOLUTION=%CD%\DrumFilling.sln -e TCMCP_AMS_NET_ID=5.12.34.56.1.1 -e TCMCP_MODE=guarded -e TCMCP_MAX_MODE=full -- C:\tools\twincat-mcp\.venv\Scripts\python.exe -m twincat_mcp

or copy .mcp.json.example → .mcp.json in the solution folder. Cursor / Windsurf / Claude Desktop's claude_desktop_config.json use the same JSON shape.

First prompt in any client: "run tc_doctor". It reports router, local NetId, target state, registered ProgIDs, running shells, project root and the safety mode. Fix what it flags before anything else.

Configuration

Env vars override twincat_mcp.toml (./, ~/.twincat_mcp/config.toml, or TCMCP_CONFIG). See twincat_mcp.toml.example.

Env

Meaning

Default

TCMCP_MODE

start mode readonly / guarded / full

guarded

TCMCP_MAX_MODE

ceiling for tc_set_mode

= mode

TCMCP_CONFIRM

0 → destructive ops in full mode need no confirmation

1

TCMCP_WRITE_ALLOW / TCMCP_WRITE_DENY

;-separated fnmatch patterns (deny always wins)

empty

TCMCP_AMS_NET_ID, TCMCP_AMS_PORT

target

local, 851

TCMCP_SOLUTION

.sln to attach to; also sets project root

—

TCMCP_PROJECT_ROOT

folder for proj_*

solution folder

TCMCP_PROGIDS

;-separated DTE ProgIDs to try, in order

17.0, 15.0, VS 18/17/16

TCMCP_XAE_ATTACH_ONLY

0 → xae_attach may launch a shell

1

TCMCP_TCUNIT_RESULT

result path on the target

C:\TwinCAT\3.1\Boot\TcUnit_xUnit_testresults.xml

TCMCP_AUDIT_LOG, TCMCP_AUDIT_READS

JSONL audit file; also log reads

~/.twincat_mcp/audit.jsonl, 0

TCMCP_DOCS, TCMCP_DOCS_SOURCE, TCMCP_DOCS_MSHC, TCMCP_DOCS_BOOKS, TCMCP_DOCS_EXCLUDE, TCMCP_DOCS_WEB_FALLBACK, TCMCP_DOCS_CACHE

Infosys lookup on/off; local (Help Viewer package) or web; the .mshc; ;-separated books indexed first; exclude regexes; web fallback (web only); cache dir

1, local, newest found, 8 core PLC libraries, —, 1, ~/.twincat_mcp/infosys

Safety model

op class

examples

readonly

guarded

full

read

any ads_read*, proj_*, xae_status, ipc_read_file

ok

ok

ok

edit

proj_set_code, xae_pou_set, xae_tree_consume_xml, xae_build, xae_plcopen_import/export, rec_start, snap_save, tcunit_scaffold

—

ok

ok

write

ads_write, ads_write_raw (PLC ports only, overlapping symbols checked), test_scenario/test_response writes, ads_call_method

—

allowlist ∧ ¬denylist

¬denylist

control

ads_plc_state run/stop, ads_connect to a new NetId, xae_plc login/start/stop, xae_target set, xae_command, ipc_write_file, ads_add_route_to_plc

—

confirm

ok

destructive

xae_activate_configuration, xae_restart_twincat, xae_deploy, ads_system_mode, ads_plc_state reset, xae_plc download/reset_*, xae_command with download/reset/activate/…, xae_tree_delete, ipc_delete_file, ipc_start_process, ipc_reboot, tcunit_run

—

confirm

confirm*

* unless TCMCP_CONFIRM=0.

"Confirm" = elicitation prompt in the client when supported (on MCP 2026-07-28 the question is returned to the client as an input_required result and the client calls the tool again with the answer; on earlier revisions it is an elicitation request during the call; tc_doctor → elicitation says which applies and whether the client declared the capability), otherwise tc_request_confirmation(action, target) → single-use token, 180 s TTL, bound to that action, target and the machine the server was connected to when it was issued (re-targeting with ads_connect invalidates it). xae_deploy / tcunit_run refuse when the XAE target and the ADS target differ. The agent can escalate its own mode only up to TCMCP_MAX_MODE, which it cannot change. Every mutating call lands in the audit log (tc_audit_tail).

"Absolute control" setting: TCMCP_MODE=full TCMCP_MAX_MODE=full TCMCP_CONFIRM=0. In that configuration a single mis-aimed tool call can stop the PLC, activate a half-built configuration or reboot the IPC. The server will do exactly what it is told; the only remaining gate is the MCP client's own tool-permission prompt. Keep a denylist for E-stop/safety symbols regardless.

Tools (151) + 5 prompts

Workflows (one call = a whole chain) wf_debug_symbol · wf_fb_profile · wf_release_check · wf_project_overview

Prompts (recipes the agent follows) debug_symbol · fb_validation · deploy_safely · performance_audit · onboard_project

Meta tc_doctor · tc_safety_status · tc_set_mode · tc_request_confirmation · tc_audit_tail

Runtime (ADS) ads_discover · ads_connect · ads_status[port] · ads_list_symbols[flag] · ads_symbol_info · ads_read · ads_read_many · ads_leaves · ads_dump · ads_types · ads_io_read · ads_write · ads_write_many · ads_read_raw · ads_write_raw · ads_watch · ads_wait_until · ads_plc_state · ads_system_mode · ads_ethercat · ads_routes · ads_add_route_to_plc · ads_app_info · ads_task_stats · ads_ping · ads_call_method · ads_export (C#/TS/JSON from the datatype table)

Recorder rec_start · rec_capture · rec_list · rec_status · rec_snapshot · rec_stats · rec_read · rec_stop · rec_verify · rec_export · rec_delete · rec_pulses · rec_latency · rec_compare

Test bench test_expect · test_stable · test_response · test_scenario · snap_save · snap_compare · snap_apply · snap_list

Target OS (System Service) ipc_read_file · ipc_list_dir · ipc_write_file · ipc_delete_file · ipc_start_process · ipc_reboot · ipc_eventlog (Windows targets)

XAE xae_attach · xae_status · xae_open_solution · xae_build · xae_diagnostics · xae_list_commands · xae_command · xae_plc · xae_target · xae_activate_configuration · xae_restart_twincat · xae_deploy · xae_tree_get · xae_tree_consume_xml · xae_tree_set_values · xae_tree_create_child · xae_tree_delete · xae_plc_projects · xae_pou_get · xae_pou_set · xae_pou_create · xae_plcopen_import · xae_plcopen_export · xae_boot_project · xae_dialogs · xae_dialog_resolve · xae_io_disable · xae_links

Project files proj_scan · proj_list · proj_get_code · proj_resolve_symbol · proj_search · proj_references · proj_read_file · proj_set_code · proj_interface · proj_lint · proj_call_graph · proj_variables · proj_vs_runtime · proj_changed · proj_validate_xml

HMI (TE2000 / TcVIS) hmi_scan · hmi_bindings · hmi_vs_runtime

TcUnit tcunit_results · tcunit_run[disable_io] · tcunit_scaffold

Experiments exp_template · exp_validate · exp_save · exp_list · exp_get · exp_runs · exp_run[dry_run] · exp_status · exp_abort · exp_evaluate · exp_report · exp_compare

Knowledge base kb_set_location · kb_status · kb_rebuild · kb_add_project · kb_remove_project · kb_reindex · kb_search · hw_lookup · hw_search · hw_object · hw_diag · hw_module · proj_libraries — the database lives in a folder you name; only project folders you add are indexed; the hw_* tools read the ESI index (every ESI file in the knowledge folder's manuals\ and TwinCAT's ESI folders)

Offline documentation — skill twincat-docs (no MCP tools; a read-only script the skill runs). The knowledge folder has one fixed layout (0.8.11; the rules are docs/KNOWLEDGE_BASE.md):

in the knowledge folder

content

built by

index\infosys-1033.db

the TwinCAT 3 books of the Help Viewer package — the one Infosys index, read by the infosys_* tools and the skill

the plugin, the first time by itself; later tools\infosys_local.py index or kb_rebuild(index='infosys')

index\manuals.db

the PDF manuals in manuals\ — page text, chapters, product codes

the plugin, the first time by itself; later tools\manuals_db.py update or kb_rebuild(index='manuals') (Python 3.12+ with pypdf or PyMuPDF)

index\esi.db

every EtherCAT device description on the PC: the ESI files you put in manuals\ (e.g. Beckhoff's whole ESI folder) and TwinCAT's Config\Io\EtherCAT — devices, PDOs, PDO assignments, CoE dictionaries with defaults, diagnosis messages, modules

the plugin, the first time by itself; later kb_rebuild(index='esi') (the builder esi_db.py, minutes)

index\knowledge.db

projects for kb_search

the kb_* tools

manuals\, sop\

your PDFs and SOPs (Markdown)

you — the plugin never writes there

tools\

builder stubs that run the plugin's builders

the plugin (only files it shipped are replaced)

skills/twincat-docs/kb_docs.py answers docs_search, docs_declaration, docs_page, docs_books, manual_search, manual_product, manual_toc, manual_page, manual_docs, hw_lookup, hw_search, hw_object, hw_diag, hw_module, status as one JSON object each (standard library, opens the indexes read-only). A name that exists in several libraries (MC_MoveAbsolute in Tc2_MC2 and Tc3_DriveMotionControl) is never resolved silently: the answer is ambiguous with the candidates. kb_status → docs shows both indexes, the PDFs not indexed yet and the exact command for this folder; hw_lookup lists the manuals that mention a product code. Every index is complete, rebuild_needed (another format) or outdated (the source changed) — the last two are used as they are until you approve the rebuild — or missing, plus a build running, interrupted or waiting to replace it; the server reports it at every connection, in tc_doctor (offline_docs), in kb_status and in each answer's source. Links are stored as page addresses: docs_page and docs_declaration return them as links, which docs_page opens.

Capture profiles rec_scan · rec_profile_save · rec_profile_list · rec_profile_get · rec_profile_delete · rec_profile_start · rec_profile_stop

Infosys reference (TwinCAT 3) infosys_books · infosys_index · infosys_search_symbols · infosys_declaration · infosys_search · infosys_search_code · infosys_get_page

Meta also tc_session_report (markdown handover of everything this session changed/produced)

Resources: twincat://config, twincat://safety, twincat://audit/recent. Full one-line-per-tool reference with safety classes: TOOLS.md (generated from the server).

Claude Code loads MCP tool schemas lazily when a server exposes many tools, so the count costs little context until a tool is used. Performance: quick reads and long operations (watch, scenarios, dumps) run on separate ADS workers, so a 60 s watch never stalls an ads_read; recorder queries touch memory/files only; the datatype table and symbol table are cached (TTL 300 s, refresh=true to force).

Connecting Claude Code

Claude Code starts the server itself over stdio — no port, nothing on the network, runs as your Windows user next to the TwinCAT router and the open XAE shell. Plugin install (section A above) is the short path; the manual claude mcp add route, scopes, permissions and troubleshooting are in integrations/claude-code/README.md.

Tool results reach Claude Code as the SDK's indented JSON text plus structured content; Claude Code shows them as collapsible tool-result blocks and the model summarises. For a human-readable handover use tc_session_report (markdown).

Also in the repo: skills/twincat-mcp/SKILL.md and skills/twincat-docs/ (loaded by the plugin; or drop into .claude/skills/), integrations/claude-code/CLAUDE.md.snippet (conventions for every session), integrations/claude-code/.mcp.json template, scripts\register-claude-code.cmd.

What 0.5.0 closes from the gap list

gap

tool

status

modal dialogs stall COM

xae_dialogs, xae_dialog_resolve, watchdog with xae.dialog_rules (never auto-answers activate/run/download/login/delete/safety prompts); scoped to the XAE process — with no known shell pid nothing is listed or clicked

window enumeration verified on Windows CI (it found a real system dialog); button clicks untested on hardware

TwinSAFE guard

every XAE edit refuses TISC/^Safety paths unless TCMCP_ALLOW_SAFETY=1

done

XML structure + LineIds

proj_validate_xml (GUID format/uniqueness, property VAR blocks, LineIds counts, EOF); fix=true, regenerate_lineids; proj_set_code regenerate_lineids=true

done

HMI files

hmi_scan / hmi_bindings / hmi_vs_runtime for TE2000 %s%PLC1.X%/s% bindings and TcVIS — broken bindings vs the live PLC and vs source

done

TcUnit without hardware

xae_io_disable, tcunit_run disable_io=true

ITcSmTreeItem.Disabled, untested

PLC discovery

ads_discover (UDP 48899 broadcast)

protocol per XAE broadcast search, untested

variable links

xae_links — link targets per AT %I*/%Q* variable, unlinked variables and array elements

instance XML (DataAreas) + ProduceMappingInfo; checked against a 3.1.4026 project's XML and mapping table

event log

ipc_eventlog via wevtutil on Windows targets; CE7/TC-BSD: use the XAE error list

partial

MES glue

ads_export csharp — explicit-offset structs/enums from the datatype table, csharp_symbols constants, TypeScript, JSON

done

recipes

snap_apply — write a snapshot back, gated per symbol, dry-run first

done

handover

tc_session_report

done

Still deliberately absent: Scope/TE13xx, NC, non-EtherCAT fieldbuses, library binary introspection, semantic search, ESI-based box creation.

Reading every variable

The symbol upload alone does not enumerate elements of ARRAY OF STRUCT, nested arrays or deep FB internals. The server also uploads the datatype table (ADSIGRP_SYM_DT_UPLOAD) and uses it everywhere:

> ads_read MAIN.fbFill          → the whole FB instance as one nested tree (one ADS read): structs,
                                  arrays of structs, enums by name, TIME/DATE decoded
> ads_leaves MAIN               → every scalar under the program with type and byte offset
> ads_leaves MAIN.arrSteps with_values=true
> ads_dump                      → every variable on the PLC → dump-<ts>.json (tree) + .csv (path,type,value)
> ads_dump pattern=GVL_*        → only the GVLs
> ads_types ST_Recipe           → members, offsets, sizes; ads_types pattern=E_* → enums
> proj_variables                → what the source declares, flattened to the same instance paths
> proj_vs_runtime               → declared-but-not-online / online-but-not-declared: proves the target
                                  runs this source after a deploy
> rec_start prefix=MAIN         → records every leaf under MAIN, array elements included

If the datatype upload fails on a target, every tool falls back to the member symbols the runtime publishes (what the other servers rely on) and says so in decoder / datatype_table.

Real-time recording while the program runs

> rec_start prefix=MAIN.fbFill mode=change cycle_ms=1 name=fill-cycle
    → every scalar under MAIN.fbFill, PLC-timestamped on every change
> …run the machine, deploy, whatever…
> rec_status <id>          → samples, missing_samples, completeness, drops, backlog, last values
> rec_snapshot <id>        → the live tail
> rec_stats <id>           → per symbol: count, min/max/mean, change count, BOOL edges,
                              state runs with dwell times
> rec_stop <id>
> rec_pulses <id> MAIN.fbFill.fbFine.bOpen   → pulse count, width, period, duty
> rec_latency <id> MAIN.fbFill.fbValve.bOpen == TRUE  MAIN.fbFill.rFlow > 0.5
> rec_read <id> t_from_ms=800 t_to_ms=1200 wide=true  → what else was true around the event
> rec_export <id> csv_wide  → spreadsheet (with the PLC's FILETIME per row)
> rec_verify <id> counter=MAIN.nCycleCount → PASS/FAIL: unmodified, no gaps, every cycle present

Modes: cycle = one sample per cycle_ms (set it to the task cycle for a complete trace), change = only when the value changes (cheap, exact edge times), poll = sum-read from the PC (any port, no notifications; timestamps are this PC's, labelled time_source: pc). Triggers: start_when='MAIN.bStart == TRUE' pre_trigger_ms=500 keeps the half second before the trigger; stop_when, duration_s (PLC time), post_trigger_s, max_events end it. Recordings from earlier sessions stay readable (rec_list, rec_read, rec_pulses, rec_export).

Accuracy (0.7). Neighbouring variables share one ADS notification per contiguous memory block (an FB, a struct, an array): the runtime sends the whole block per sample and the leaves are decoded on the PC. On a 1 ms task, 300 counters as one block were lossless; as 300 separate notifications ~5 % complete — so select whole FBs/structs/arrays rather than hundreds of scattered globals. Every loss is counted: missing_samples / completeness per block from the PLC timestamps (cycle mode), dropped (backlog full), dropped_on_stop. A notification that cannot be registered fails the start (allow_partial=true records the rest and lists unsubscribed_symbols).

Provenance. The file (~/.twincat_mcp/recordings/<id>.jsonl) stores the raw bytes the runtime sent and the runtime's own sample timestamps: _t0.filetime is the PLC FILETIME of the first sample and t_ms has 0.1 µs resolution, so filetime + t_ms·10⁴ is each sample's exact PLC time (rec_export adds it as plc_filetime). The footer carries a SHA-256 over every line, signed with a per-install key. rec_verify <id> counter=MAIN.nCycleCount proves (1) the file is unmodified, (2) no holes in the PLC timeline, (3) the per-cycle counter steps by exactly 1 — the ground truth for "no sample lost". The acceptance run does this with TwinCAT_SystemInfoVarList._TaskInfo[1].CycleCount at the task cycle.

Native capture engine (0.8). Cycle-mode recordings run in tcmcp-capture.exe (twincat_mcp/bin/), a C++ service built on Beckhoff's AdsLib (AdsDevice / AdsNotification) over Beckhoff's TcAdsDll — the TwinCAT router. The ADS callback copies each sample into a lock-free ring and returns; a writer thread merges the blocks by PLC timestamp and writes the same format-2 file, signed the same way. Python is no longer on the data path, so the 300-leaf/1 ms loss of the Python recorder does not apply (the simulator test writes 60 s of a 1200-byte block + counter at 40× real time without a loss). The footer adds missing_head (pre-trigger buffer not full), missing_gaps, missing_tail (PLC stopped before the window end), overflow_samples (ring full on this PC — reported, never silent), requested_s, plc_span_s, window_start_ms/window_end_ms and verdict_hint. One process per recording; nothing is subscribed unless every block is. engine='python' (or [recorder] engine = "python") keeps the in-process recorder; without a matching exe, auto falls back to Python and says why (engine_note). change/poll modes and allow_partial stay on the Python recorder. tc_doctor → recorder shows which engine cycle recordings use. Build and protocol: native/capture/README.md.

Choosing what to record: capture profiles

rec_start decides the symbol set per call. For batch-after-batch work the set should be decided once, from a scan of what exists, and replayed. Three ways to choose, all ending in a named profile:

  1. Checklist. rec_scan prefix=MAIN.fbDispense checklist=batch (or source=project offline) lists every scalar leaf with type, size, a suggested mode (BOOL/INT/enum → change, REAL/TIME → cycle, strings/arrays → poll) and the bytes/s it would cost, grouped by program.instance, and writes ~/.twincat_mcp/profiles/batch.checklist.csv. Put an x in select, optionally override mode / cycle_ms per row, then rec_profile_save name=batch from_checklist=batch. preselect=["*.bDone"] pre-marks patterns.

  2. In the source. {attribute 'tcmcp.record' := 'cycle'} above a declaration selects it; on an FB/STRUCT instance it selects the whole subtree, an inner 'off' carves holes, {attribute 'tcmcp.cycle_ms' := '1'} pins the rate. rec_profile_save name=batch from_attributes=true collects them through the project index — the selection is versioned with the code and survives renames the way nothing in a chat does. TwinCAT ignores unknown attributes.

  3. Explicit. rec_profile_save name=x symbols=[...] mode=auto — auto reads the runtime type.

rec_profile_start batch starts one recording per (mode, cycle) group, named batch/cycle@1, batch/change@10…, with the profile's start_when / stop_when / pre_trigger_ms (trigger symbols are added to every group automatically); rec_profile_stop batch ends them together; rec_stats, rec_export, rec_compare work per recording as before. Sources combine and later ones override earlier ones, so a checklist can narrow what the attributes selected.

"By standard" there is no default selection: nothing is recorded that was not chosen, and the suggested modes are heuristics shown next to the choice, not applied behind it.

Testing an FB on the live machine

> test_scenario {
    "name": "bulk-then-fine",
    "record": {"prefix": "MAIN.fbFill", "mode": "change", "cycle_ms": 1},
    "steps": [
      {"at_ms": 0,    "write": {"MAIN.stRecipe.rTargetKg": 25.0, "MAIN.bStart": true}},
      {"wait_until": {"symbol": "MAIN.fbFill.eState", "op": "==", "value": 2, "timeout_ms": 3000}},
      {"expect": [{"symbol": "MAIN.fbFill.fbValve.bOpen", "op": "==", "value": true}]},
      {"wait_until": {"symbol": "MAIN.fbFill.bDone", "op": "==", "value": true, "timeout_ms": 60000}},
      {"stable": {"symbol": "MAIN.rNetWeight", "duration_ms": 2000, "tolerance": 0.02}}
    ],
    "final_expect": [{"symbol": "MAIN.rNetWeight", "op": "~=", "value": 25.0, "tolerance": 0.05},
                     {"symbol": "MAIN.fbFill.bError", "op": "==", "value": false}]
  }
    → per-step pass/fail with times, written values restored, recording id for rec_* analysis
> test_response {"MAIN.fbFill.fbValve.bOpenCmd": true} "MAIN.fbFill.rFlow > 0.5"
    → PLC-timestamped latency from the write to the response
> ads_task_stats samples=100 → exec time min/max/mean, load %, cycle overruns while the FB runs
> snap_save before prefix=GVL_Params … change code … snap_compare before live tolerance=0.001
> proj_interface FB_Fill · proj_lint FB_Fill · proj_call_graph MAIN
> tcunit_scaffold FB_Fill → FB_Fill_Tests.TcPOU registered in the .plcproj; then tcunit_run

Writes in scenarios go through the same allow/deny lists as ads_write; nothing is written until every symbol in the script has been permitted. Writing to an AT %I* input does nothing useful (the I/O task overwrites it each cycle) — stimulate through unmapped inputs or a simulation GVL.

Experiments: from runs to a report someone can sign

rec_* captures and test_* stimulates; exp_* turns repeated runs into conclusions. The spec is YAML (or JSON) in <project>/experiments/<name>/spec.yaml — versioned with the code:

name: preact-fill-validation
hypothesis: With lambda=0.95 the preact controller holds |bias| <= 2 g and sigma <= 3 g at 1000 g.
profile: preact-fill                      # capture profile started for every run
preconditions: [{symbol: MAIN.fbScale.bStable, op: "==", value: true, timeout_ms: 30000}]
factors:
  - {name: target_g, symbol: GVL_Recipe.rTarget_g, levels: [500, 1000]}
  - {name: lambda,   symbol: MAIN.fbDispense.fbPreact.rLambda, levels: [0.95]}
runs_per_level: 5
run:
  start:     {symbol: MAIN.bStartFill, value: true, reset_value: false, reset_after_ms: 200}
  done_when: {symbol: MAIN.fbDispense.ePhase, op: "==", value: IDLE, timeout_ms: 180000}
  settle_ms: 2000
measures:
  final_weight_g: {kind: last, symbol: MAIN.fbScale.rNet_g}
  final_error_g:  {kind: expr, expr: final_weight_g - target_g}
  cut_latency_ms: {kind: latency, from: {symbol: MAIN.fbDispense.bCut, op: "==", value: true},
                                  to:   {symbol: MAIN.fbFlow.rFlow_gps, op: "<", value: 5.0}}
  fine_pulses:    {kind: pulses, symbol: MAIN.fbFine.bPulse}
metrics:
  bias_g:  {measure: final_error_g, stat: mean}
  sigma_g: {measure: final_error_g, stat: std}
  cpk:     {measure: final_error_g, stat: cpk, tolerance: 5.0}
criteria:
  - {metric: bias_g,  op: abs_le, value: 2.0}
  - {metric: sigma_g, op: le,     value: 3.0}
  - {metric: cpk,     op: ge,     value: 1.33}
writes_allowed: [GVL_Recipe.rTarget_g, MAIN.fbDispense.fbPreact.rLambda, MAIN.bStartFill]

exp_template returns a complete one for a dosing machine; exp_validate checks structure, resolves every symbol on the connected PLC, and asks the server guard whether each write would be allowed; exp_run dry_run=true prints the plan and writes nothing. exp_run then executes in the background — per run: preconditions (wait_until) → factor values written → snap_save → capture profile started → stimulus → done_when → settle → stop → measures from the PLC-timestamped recording → append to runs.jsonl. Factor symbols are read first and restored at the end or on exp_abort; two consecutive failed runs stop the experiment. Resume continues where runs.jsonl stopped.

exp_evaluate is deterministic from runs.jsonl: per level the metrics with 95 % CIs (t for the mean, χ² for σ, propagated for Cpk) and each criterion as pass / fail / inconclusive — inconclusive when the limit lies inside the CI, with the run count that would (roughly) settle it. Five fills give σ a ±40 % standard error; the report says so instead of rounding it away. exp_report writes report.md + report.html: machine serial, device/TwinCAT version, project + git state, safety mode, criteria table, metrics per level, charts (primary measure per run with limit lines; per-level mean/CI), run table with recording ids, the spec as run, the audit log of every write during the experiment, and an Interpretation section stored separately and labelled "not computed". exp_compare a b puts two experiments side by side with "separated" where the CIs do not overlap.

Safety: every written symbol must be in writes_allowed and pass the guard — checked before anything moves and again before every single write, so tc_set_mode readonly is a working kill switch; each write is pinned to the machine the experiment started on (an ads_connect elsewhere makes the next write fatal) and audited with symbol, value and run. Writes are scalars only (a struct write would bypass the member deny-list). A run counts as started only when the machine leaves the done state within start_timeout_ms; a rejected start is a failed run, not an instant pass. Factor originals are read and checked for writability before the first run, restored and read back afterwards (or on abort, after any run.on_abort safe-state writes); an abort interrupts a wait within a second; a timed-out write ends the experiment because the PLC state is unknown. One experiment per target at a time; starting is control-class (confirmation in guarded mode). The physical safeguards stay yours.

Looking up Beckhoff documentation

The infosys_* tools exist because the documentation MCP servers available for TwinCAT ship a pre-built index, and an index is only as complete as the crawl that made it. Against the one tested here, infosys_search_symbols("ADSREAD") returned nothing, infosys_get_page reported a live Tc2_System page as not found, and TON ranked BA2 helper functions first. This server does not ship an index:

  • Source (0.8.3+): the Help Viewer package on this PC, by default. TwinCAT XAE installs the complete Information System as BKINFOSYS3_VS_100_EN-US.<n>.mshc under %ProgramData%\Microsoft\HelpLibrary2\Catalogs\<catalog>\ContentStore\EN-US\ (≈ 1 GB, ≈ 50k pages, ≈ 280 books). It is a zip of <book>/1033/<pageid>.html with the same page ids as the website, so every page is stored under its real https://infosys.beckhoff.com/content/1033/<book>/<id>.html URL. docs.source = "local" (default): no network call at all, no web fallback; the newest package is found automatically ([docs] mshc to pin one). One index (0.8.11, rules in docs/KNOWLEDGE_BASE.md): every TwinCAT 3 book of the package, built as a whole in its own process into <knowledge folder>\index\infosys-1033.db (without a knowledge folder: <cache_dir>\helpviewer-1033\index.sqlite) — the same file the infosys_* tools and the twincat-docs skill read. The first build starts by itself; after that a new package or a plugin update that changes the stored format is reported (tc_doctor, kb_status, every answer) and the index is used as it is until you approve kb_rebuild(index='infosys') or run tools\infosys_local.py index; the rebuild replaces the index only when it is complete. Results carry the page's doc version (Microsoft.Help.DisplayVersion) and source.modified — the package is as old as the last Help Viewer update on this PC; check that date before trusting a page about a new build or library version. infosys_get_page reads any page in the package, indexed or not, with its breadcrumb. docs.source = "web" brings back the behaviour below.

  • What exists (web) comes from infosys.beckhoff.com/sitemap.xml (every English page URL with its lastmod), cached a week. infosys_books groups it by book (tcplclib_tc2_system, tf6100_tc3_opcua, el3xxx…) with page counts; TwinCAT 2 books are dropped (tcplclib<name> without underscore, twincat2/). Tc2_System, Tc2_Standard, Tc2_Utilities are TwinCAT 3 libraries and stay.

  • What is indexed is per book, on demand: infosys_index tcplclib_tc2_system fetches its pages (≈300, parallel, ~30–60 s), converts each to Markdown with our own HTML walker, classifies the page (FunctionBlock / Function / Struct / Enum / Alias / Interface / GVL / Library / Page), extracts the declaration from the VAR_INPUT/VAR_OUTPUT code blocks and attaches the description tables, and stores it in SQLite with FTS5. A later run refetches only pages whose lastmod changed. The first infosys_search_symbols / infosys_declaration indexes the default libraries (docs.books) if nothing is indexed yet.

  • infosys_declaration ADSREAD → {kind, inputs:[{name,type,default,description}], outputs, in_out, members, enum_values, return_type, extends, implements, declaration, url} — call it before writing code against a library FB you have not used. infosys_search_code "IDXGRP:=16#F005" finds the example that uses a constant; infosys_search "rising edge" is bm25-ranked full text with excerpts.

  • infosys_get_page takes a URL, book/pageid, a bare page id, or a symbol name, fetches live (cached by lastmod) and returns Markdown — for any page the site has, indexed or not. Host-locked to infosys.beckhoff.com; the server is not a general web fetcher.

  • Web fallback: when the local index has no hit, infosys_search asks DuckDuckGo for site:infosys.beckhoff.com <query>, keeps only URLs that are in the sitemap and in TwinCAT 3 books, fetches them for title/excerpt and caches them. backend in the result says which path answered. docs.web_fallback=false turns it off.

Config ([docs] in the TOML / TCMCP_DOCS*): source (local | web), mshc, enabled, cache_dir; for the web source books (indexed first), exclude_books (regexes), tc3_only, max_workers (≤16; be polite), max_index_pages, sitemap_ttl_days, web_fallback — the local index holds every TwinCAT 3 book whatever they say. The infosys_* tools are read-only class; kb_rebuild is control class and always asks for approval.

A debugging session

> ads_status                              → PLC RUN, system RUN, TwinCAT 3.1.4024.x
> ads_read MAIN.fbFill                    → whole FB instance expanded: eState=3, tSettle=T#500ms, …
> ads_watch [MAIN.fbFill.eState, MAIN.fbFill.fbValve.bOpen] 5000ms 20ms
                                          → eState 3→4 at 812 ms, bOpen never true
> proj_resolve_symbol MAIN.fbFill.fbValve.bOpen
                                          → FB_Fill.TcPOU:14 (fbValve : FB_Valve), FB_Valve.TcPOU:5 (bOpen AT %Q*)
> proj_get_code FB_Fill                   → CASE eState OF … E_FillState.Bulk: fbValve.Open();
> proj_search "fbValve\.Open"             → only one call site; the state that reaches Bulk is never entered
> xae_pou_set …  / proj_set_code …        → fix
> xae_build                               → 0 errors, 1 warning (file:line)
> xae_deploy                              → asks for confirmation, then save/build/activate/restart
> ads_wait_until MAIN.fbFill.bDone == TRUE 30000

Verify-on-hardware list

Install, configuration and a 14-step zero-write smoke test: docs/INSTALL.md. Ordered first-day script that then exercises every layer, with expected outputs and what to paste back per failure: docs/HARDWARE_DAY.md.

The XAE and System-Service paths are written against Beckhoff's Infosys documentation and tested against fake COM/ADS objects; this repo was built on Linux, so the following have not been executed against a real XAE shell or IPC yet. Check them in this order on the engineering PC, with a non-production target:

  1. tc_doctor → router ok, ProgIDs registered, running shell listed.

  2. xae_attach → correct instance/solution; xae_status shows target_net_id.

  3. xae_build → error_source should be Windows.ErrorList or DTE2.ToolWindows; if it says OutputPane the late-binding fallback is in use (still works, less precise).

  4. xae_pou_get on a POU → declaration/implementation populated (late-bound DeclarationText; Beckhoff's own PowerShell examples use it this way).

  5. xae_plc login → if "no working DTE command", run xae_list_commands PLC and put the right name into PLC_LOGIN_COMMANDS in xae_backend.py. On the 64-bit 4026 shell the PLC.* commands are reported missing by other projects; ads_plc_state covers run/stop/reset without the shell.

  6. ipc_read_file C:\TwinCAT\3.1\TwinCAT.xml → file access (FOPEN/FREAD/FCLOSE).

  7. ipc_list_dir C:\TwinCAT\3.1\Boot\* → FFILEFIND struct layout (4-byte handle + WIN32_FIND_DATAA) is the least certain piece here.

  8. ads_ethercat → index groups 0x3/0x100 (master state) and 0x6 (slave count) on the master's ADS port.

  9. ipc_start_process with notepad.exe, then ipc_reboot on a test box.

  10. tcunit_run end-to-end.

  11. rec_start mode=change on a few booleans, toggle them, rec_stats → edge timestamps plausible against the task cycle.

  12. ads_task_stats, ads_app_info → TwinCAT_SystemInfoVarList members resolve by name (they are not in the uploaded symbol table).

  13. ads_call_method on a method marked {attribute 'TcRpcEnable'} → check the instance#method handle name and the packed parameter layout against the result.

  14. ads_types ST_<something> then ads_read of an ARRAY OF STRUCT variable → datatype-table parsing (AdsDatatypeEntry incl. the optional GUID/attribute/enum tails) against a real table; compare offsets with the TMC. On failure the server falls back to published members and reports decoder: none for arrays of structs.

  15. exp_run <name> max_runs=1 on a harmless spec → the stimulus write, the start acknowledgement, the done condition and the restore appear in tc_audit_tail as exp_write rows; then exp_abort during a run → factor restored, no recording left in rec_list.

  16. infosys_get_page ADSREAD and infosys_index tcplclib_tc2_system → the HTML walker was written against the page shape reported through a Markdown converter, not the raw HTML (this repo was built on a host that cannot reach infosys.beckhoff.com). Check: title = symbol name, kinds in the index result mostly FunctionBlock/Function/Struct, infosys_declaration ADSREAD lists NETID…TMOUT with descriptions. If titles come back as "Beckhoff Information System" or kinds are all Page, the H1/<pre> selectors in infosys.py::_MdWalker need the real markup — one page's HTML pasted back is enough.

  17. scripts\launch.cmd (used by the .mcpb) → Python discovery order TCMCP_PYTHON → py -3 → python → %LOCALAPPDATA%\Programs\Python\Python3*; the Microsoft-Store python.exe stub fails the version probe and is skipped. Run it once by hand with --no-run and watch stderr.

Anything that fails: the tool error text contains the ADS/HRESULT code; paste it back and the fix is usually one constant.

Changelog

0.8.19 — PLC libraries through XAE, and the 0.8.18 retest (N194 – N196, N180) fixed at their cause. Libraries (+8 tools, TE1000 ITcPlcLibraryManager): xae_library_list gives the references as XAE holds them — libraries (name, version, distributor) and placeholders (default and effective resolution) — and flags a library referenced twice, a version that is not installed (ScanLibraries) and the references or requested versions that differ from the saved .plcproj of the open solution (an unsaved resolve or freeze cannot be seen there, and it says so); xae_library_installed lists every installed version; xae_library_repositories the repositories (or that this XAE does not give them). xae_library_add, xae_library_remove, xae_placeholder_add, xae_placeholder_resolve and xae_placeholder_freeze run once, carry XAE's messages and the references before / after, and never build; guarded mode asks, the confirmation names the PLC project and the reference (remove: its kind and version too); a name referenced twice (a placeholder and a library) is refused until kind says which, and if XAE removes the other one the result says so. A TwinCAT restart during a python recording (N194): a change-mode recording across RUN → CONFIG → RUN received nothing after the restart and verified PASS. The python engine now reads the runtime when no sample came for a second; a task cycle count that started again (or an outage of 3 s or more) is a restart: the same program gets its notifications registered again and the span is marked in the file (_restart, resubscriptions, runtime_restarts, label INCOMPLETE); another program ends the recording; one failed read is no restart. PLCopen replace (N195): a library reference missing from the listing right after the import no longer stops a replace; what seems removed — or a renamed copy that should be there — is listed again before anything is said, and a refusal names the copies it leaves. Unknown arguments (N196): every tool refuses an argument it does not have, before it runs (tcunit_results(path=…) read the boot result file instead). Scope and a TwinCAT restart (N180): after a recording with Scope, the Scope View log's state lines since StartRecord are walked — a restart that cut the capture, Scope recording again after it, or a router stop while Scope was not recording — and said in the result and the signed link (restart_seen / restart). Two review rounds per part (independent reviewers): every HIGH / MEDIUM fixed with a test red before; the LOW left are in docs/TRACKER.md.

0.8.18 — the 0.8.17 retest (N189 – N193) and an in-depth review of the 0.8.16 – 0.8.17 Scope and recorder code, fixed at their cause; no addition. One Scope, one owner (N189): two recordings with Scope at once each got a part of the one Scope — the second stopped Scope at its end and saved the first one's capture, which was then saved and signed again for the first. Now a recording's Scope part owns Scope until it is finished, a call starting it from its check on (two starts sent together cannot both pass), a Scope recording of its own (scope_record start / new) until scope_record stop. Under another owner rec_start(also_scope=true) is refused before anything starts ("Scope belongs to recording …"; the 'ask' policy does not offer Scope, scope_note says why) and scope_record start / stop / save / disconnect / new are refused before they act; after scope_record stop the next recording with Scope asks to disconnect first, as after a recording. Scope's span (N191): a capture that begins later, ends earlier or runs past its recording by more than 1 s is said in the result and in the signed link (scope_span: covers x s of y s). Audit (N190): the disconnect question and the choice after a recording. xae_links (N192, N193): on TwinCAT 3.1.4026 the PLC instance has no tree children — it said "0 unlinked"; it now reads the variables from the instance's XML and the links from the mapping table (ProduceMappingInfo): link targets per variable, array element and member, the unlinked variables and elements (arrays of structs too), links whose variable is gone, and not_checked where gaps cannot be checked (a multi-dimensional array, a struct linked member by member); what cannot be read is said (unlinked_count null), never counted as 0; the instance path is accepted (every tool taking a PLC project path does). Review fixes: a rec_start cancelled during the start check no longer leaves rec_stop / rec_delete waiting forever with Scope recording; a StartRecord whose outcome is unknown (shell gone, E_POINTER after acting) stays with the recording and is stopped (it was "NOT started"); the start check reads only lines written after this StartRecord (another start's line confirmed a refused one); an answer to a Scope question is applied once, to the state it was asked about; 'new' says what ran when its StartRecord did not, and holds Scope between its Disconnect and its StartRecord; a dialog the shell shows after StartRecord is said again (open_dialogs); a delete between a finish's check and its link no longer leaves a signed link to a deleted recording; XAE messages read after a failed before-read are marked as possibly earlier calls'; the stale-data check compares one clock at a time (a start the Scope View log confirmed is this run's; without PLC time and confirmation it says it cannot tell). No index changes format. Not in this release: the offline documentation work (held); libraries are planned for 0.8.19 (docs/PLAN-0.8.19.md).

0.8.17 — the Scope part of a recording has one owner (N182 at its root): each rec_start(also_scope=true) recording's Scope part is run by one task that takes, in order, the recording's end (it watches the recording), rec_stop / rec_delete asking to finish it and a stop asked again — in 0.8.16 four actors shared five tables and every review found another interleaving. The fourteenth review's findings are fixed with it: rec_stop / rec_delete with Scope carry solution_mismatch / reattached again; SaveSVD refused right after StopRecord ran says that StopRecord ran and that scope_record(action='save') saves what Scope holds (no "repeat it"); no "retry in a few seconds" after a busy text that withholds "repeat it"; a StopRecord refused before it ran (XAE busy, a dialog another call opened holding XAE, the XAE worker busy) is asked again by the next rec_stop(id) — also after the recording was deleted: rec_status shows the part (by its id or a unique prefix; a recording the recorder still holds is never said deleted), rec_list lists it under scope_without_recording; a StopRecord a dialog holds or that timed out is stop_unknown — never sent again, and Scope is not said to be stopped or not; a StartRecord a dialog holds is start_unknown and stays with the recording (0.8.16 said "NOT started" and Scope recorded with no owner) — the link then has started: null and start_unknown; the part exists before StartRecord runs (state: starting), so a rec_stop meanwhile finishes it; a rec_start cancelled before its StartRecord ran (still queued behind another XAE call) is not started — nothing of Scope is stopped or saved for it; the link's started is when StartRecord ran; finished_by comes from the recorder's own stop reason — a rec_stop just after the recording ended by itself says that end, a call still stopping the recording is never labelled as one that ended; a rec_delete cancelled during its stop or its file removal waits for the delete's outcome — nothing saved for the deleted recording, finished_by names rec_delete; rec_delete while the part is being saved (the recording had ended) lets that save complete, then deletes the ADS recording and lists the Scope files that stay (scope_files_kept — rec_delete removes the ADS recording and its exports, never Scope's files); a recording deleted while Scope was saved gets no signed link; scope_record(save) with the export tool and an existing CSV names its own way out (another path). Scope after a recording (Ryan's decisions, 2026-10-21): every Scope file the plugin saves goes to <recordings>\Scope Recordings\ (0.8.16 and before: <recordings>\scope\ — those files stay where they are; [scope] export_dir still overrides); rec_delete never deletes them. After a recording Scope holds its data (state Reply) until it is disconnected, so the user chooses what Scope does next: close (Disconnect — XAE's Scope view is cleared, Scope is ready for the next recording), new (Disconnect and start a new Scope recording at once — on its own, stopped and saved with scope_record) or pause (Scope keeps the data to look at in XAE). rec_stop asks with a prompt (scope_next); after a recording that ended by itself rec_status carries the question for the agent to ask (a read-only tool does not act); a client without prompts gets the question in the result. The next recording with Scope while Scope still holds data asks to disconnect it first — rec_start(scope_disconnect=true / false) is the answer. scope_record(action='disconnect' | 'new'): without the plugin's own saved recording in Scope, discarding what Scope holds needs the user's confirmation. The 0.8.16 retest (S1 – S4): N186 — Scope in Reply (still holding the previous recording) refuses StartRecord, and StartRecord's return value does not tell (1 when it records, 1 when it refused): the Scope View log does — a start it refuses is NOT started with Scope's state and how to bring it back to Config (Disconnect in XAE's Scope View), scope_record(action='start') too; a start the log confirms says so (start_check); and Scope data whose CSV says it ends before the recording began (Starttime / Endtime of export) is never linked to the recording nor sealed (not_this_recording) — the previous capture was saved and signed as the next recording's. N185 — TcScopeView.log begins with a binary header whose length field changes with every write: the log is fingerprinted from its first text line, so only the lines written since the call began are reported; truncated when more errors were found than shown. N187 — Python engine: the connection is closed after the drain's last program check (it read the symbol version on a closed connection: the tail was dropped, verdict FAIL with a lossless counter). N188 — a result without xae_messages says whether XAE's message buffer was read and empty or could not be read (xae_messages_note; an error: "XAE messages (…): none …" / "not read: …"). N181b — a call a dialog refused at its first COM call says nothing of it ran. No index changes format. Not in this release: the offline documentation work (held).

0.8.16 — XAE messages and the 0.8.15 retests outside the documentation (S2 – S4), fixed at their cause, with independent reviews. XAE messages: what TwinCAT's System Manager logs during an action (ITcSysManager2::GetLastErrorMessages: activate, restart, build, ConsumeXml, CreateChild / DeleteChild, PLCopen import, boot project, online commands) comes with its result as xae_messages — TwinCAT's own text, also warnings on success; a failed action's error ends with "XAE messages (…)", and with what the call's earlier steps logged — also the steps of xae_deploy, xae_activate_configuration, xae_restart_twincat, tcunit_run before the one that failed; a call XAE rejects after an action of the same tool ran says which ran instead of "repeat it"; the messages are taken in the worker that ran the call, so a call queued behind never gets another's; a buffer that held something before the action is earlier_messages, not the action's. Scope: every numbered Scope View log (TcScopeView_1.log …, a second XAE shell) is read, scope_view_log.logs_checked / logs_written (N179); a recording that ends by itself (duration, stop_when, max_events …) finishes its Scope run — once, whichever of it and rec_stop comes first, finished_by says which, also when rec_stop is cancelled or times out before its Scope part (who ended the recording is the recorder's own stop reason); rec_delete stops Scope and saves nothing; a StopRecord XAE refuses is asked again by rec_stop; a StartRecord XAE refuses says the ADS recording runs and not to repeat rec_start; rec_status / rec_list show the Scope part (N182); SaveSVD refused after a TwinCAT restart is said as that, with the time from the Scope View log (without a reset line in the log: the state Scope is in; a log missing or unreadable is said so, no restart invented), and XAE's ExportCSV of what Scope still holds is recovered or the run's Scope data lost (N180). XAE: the interface replace reads TwinCAT 3.1.4026's export — InterfaceAsPlainText of the interface, its methods and properties (N175); a call a modal dialog refused did not run — a read-only tool says nothing was changed, any other that its earlier steps may have run (N181); the shell's own main frame is never a dialog (N176). Confirmations: the question says it expires after 10 minutes; a late answer is logged in server.log and audited confirmation expired (N178). Multi-PLC: wf_debug_symbol names the PLC project a name is in, as proj_resolve_symbol does (N141b). Recorder: rec_status / rec_list no longer fail while another recording is started or deleted during the reap of one that ended (and the Scope watch no longer takes such a failure for the recording's end); the Python engine's footer has overflow_samples, requested_s, missing_head / missing_gaps / missing_tail and verdict_hint as the native engine's. No index changes format. Not in this release (held): the error index and err_lookup (N125) and the documentation items of the 0.8.15 retest (N177, N183, N184).

0.8.15 — the 0.8.14 retests (§34 – §34j: N140 – N175, N44) and kb_verify I13 fixed at their cause, with three independent reviews of the work and of their fixes. After the update, once: three indexes change format and are reported as rebuild_needed — each answers as it is until you approve its rebuild: Infosys 7 (kb_rebuild(index='infosys')), ESI 2 (index='esi'), manuals 6 (index='manuals'). Infosys (format 7): a page's kind comes from its own evidence, never from its samples — an FB whose sample declares a STRUCT stays an FB, operator pages are Operator, method pages Method, "returns TRUE/FALSE" is a BOOL return; the header in a page's Syntax section counts, also FUNCTION BLOCK X written with a space (N150, N151, N157, N172). Symbols documented inside a page (N170): ## Method X sections with parameter tables are methods with a declaration reconstructed from the tables (RecipeManCommands' methods), the FB the text names gets its method list, IEC constant tables are Constants with value, type and GVL (ERR_RECIPE_NOT_FOUND → 16#4003), the build log counts them; a name only a title has as a word answers that page (match: title, outline). A page whose Syntax section declares another name than its title: the header is its declaration (declared_as) only when nothing contradicts it — no other page of its library documents that name, its tables document nothing the header lacks, it does not derive from the page's own symbol (tf8560's ActualsActuator declares FB_ActuatorActuals EXTENDS FB_MotionActuals, and FB_ActuatorActuals finds it); otherwise it is another symbol's header, Beckhoff's copy of a neighbour's (F_TimeToSeconds() shows FUNCTION F_SecondsToTime), and syntax_header_note says why. 'Definition:' under a Syntax heading no longer hides the declaration below it; SEL's syntax keeps the lines its 'means:' introduces. FB.Member follows the FB's definition location, EXTENDS and IMPLEMENTS (FB_TcMessage.Send → I_TcMessage's, defined_in), in the owner's library first (N158); the near list offers the owner and where the member comes from (N159); an owner documented differently by several pages is not guessed — the note names the library= that finds the member; FB_X.Member finds member pages titled LookUp(), SendAlarm(), GetHMI (4.1); member pages below two different symbols are never one document (FB_JsonSaxWriter.AddKey / FB_JsonSaxPrettyWriter.AddKey). Search: IEC keywords in capitals (THIS, FOR, BY) and operators as written (REF=, THIS^) are searched and put their page first — an acronym (PLC, LED) is a word like any other (N148, N149); words_ignored lists only words not used (N166); infosys_search_symbols takes globs (N161). Paging (N167): infosys_search, docs_search, hw_search, manual_search / manual_page page with offset / next_offset in one order; a limit above the maximum is used as the maximum and said (clamped); CLI search / show --offset (N168); ranges in -h and the MCP schemas (N169). infosys_get_page reads like docs_page — section, offset, outline, one max_chars range 200 – 60000; the skill takes library=; an MCP not-found names what is near and how to search (N160). kb_search (N143 – N147, N171): results and notes by kind, members mapped to their owner, the project's own units first, punctuation-joined tokens searched as a sequence, changed_files / added_files / removed_files when the project index is stale, one-letter message names ignored, a unit whose name holds none of the words no longer ranks by its name. ESI (format 2): sub-index in hex (8000:11 = 17, N152), revisions_available (N153), decimal product codes (N154), one answer envelope for MCP and skill (N155), modules found by their devices (N156); a CoE object defined twice in one dictionary is one object — EL6653 and EL6653-0010 listed 17 objects and counted 19 (Beckhoff's EL66xx.xml repeats #x1C32 / #x1C33); a repeat that differs keeps the first and says so (defined_again_note, also in hw_lookup's object list); hw_search pages by title in SQL and reads a page in two full-text queries (limit 100: 3.7 s → 0.1 s). Manuals (format 6): product codes of every Beckhoff family (ED2008, AL, AA, PS, ERI …) — manual_product and hw_lookup answer from the page text meanwhile, never "copy its PDF" for an indexed manual (N163); hex / CoE index forms in any notation (N164); unit symbols as written (°C, mV/V, µs, N165); manuals_db.py search / product / toc / docs print the skill's commands. XAE: a modal window of any class is detected — main window disabled, the window it owns read through UI Automation (N173: About, Options), also with a hidden main window (xae.visible=false); "Call was rejected by callee" is "XAE is busy … did not run this call"; every COM access goes through the retry; crash tracebacks in ~\.twincat_mcp\logs\server.log (N174); an interface replace is checked against the XML's methods (N175); a listing that fails before a replace import imports nothing (N44). Server: the connection instructions say when they were read and that kb_status is current, and are read again at each initialisation (N162). Scope View log (N140): its NUL padding is no text, the mark of a call is where the log's text ends, a rotated log is told by its beginning, new_bytes counts text. Multi-PLC: a symbol of another PLC project names the PLC project looked in and where the name is (N141); a <PLC project>@Name pin names that PLC project, and a file several PLC projects compile is analysed in each and answered once when the results agree (N142); proj_variables names the PLC project it walked and resolves types in it; proj_list / proj_search / proj_references items carry plc_project; proj_validate_xml(fix=true) keeps one .bak per file per call. kb_rebuild gives the build's own pid (launcher_pid for a venv launcher), kb_status names it process_pid. Web cache: a lookup reads the index again when the background indexer changed it during the call (infosys_declaration answered a title page while the default books were being indexed). Not in this release: the error index (N125, 0.8.16).

0.8.14 — the 0.8.13 retests (§33, §33b, §33c, §33d) fixed at their cause: N127 (S1), N116–N124, N126, N128–N138, N99b, N103b, the Scope and multi-PLC audits, the knowledge-base agent findings, and what kb_verify found (search by a title that is the query; page ids that are not numbers). After the update, once: the Infosys index changes format (5 → 6) and is reported as rebuild_needed — it answers as it is until you approve kb_rebuild(index='infosys') (or tools\infosys_local.py index); format 6 stores each page's place in the Help Viewer contents (N126) and reads pages in their own charset (N138). Folders indexed by kb_add_project before need nothing (their stamp is compared the old way until the next kb_reindex). Knowledge base (N127, S1): kb_set_location (with a path), kb_add_project, kb_remove_project, kb_reindex are refused in readonly mode and audited (ok / error / refused) like every EDIT tool; kb_rebuild is refused in readonly and still asks in every other mode. kb_add_project refuses the plugin's folders, the knowledge folder and a folder inside or around one already indexed (N128); a new folder is registered in the transaction that stores its units; one change of knowledge.db at a time (index\knowledge.db.lock, a second is refused with what runs; kb_set_location waits for it); kb_status / kb_search never create index\ or knowledge.db. kb_set_location: a file is "a file, not a folder", \\?\ paths are local paths, cloud folders are recognised by folder name (D:\Toolbox Drive is no Box Drive), choosing a drive root is refused, path + use_fallback that differ are refused (N136). Project sources (N132): .Tc* files are read as XML is — BOM, UTF-16, the declared encoding; a file that is not valid UTF-8 and has no UTF-8 in it is read as Windows-1252 and said so; files that could not be read, read notes and files no PLC project compiles are named in proj_scan, kb_add_project, kb_reindex and kb_status; code and comments are indexed whole; proj_set_code and proj_validate_xml(fix) write a file back in its own encoding and do not edit one read with a note. kb_status gives each folder's state and kb_search lists stale folders (changed, renamed, deleted since indexing; .tsproj/.xti/.sln count) (N133). kb_search: the unit that declares the name first (declares, N131); kinds=['POU'] (N134); OR / AND / NOT / NEAR and operator characters are said not to be operators, single characters are not searched among other words, _ alone is refused, a phrase in a string literal is not "comments" (N135); an error message is decided by its code — ADSError 1808, pyads' ADSError: … (1808)., error 1861, error no. 1861, nErrId := 1861 / 16#745, 0x98110745, ADSERR_…, a compiler message — not by the word 'error', a number or a hex number anywhere, and the names of the code in it are searched (ADS error 1808 fbCounter, N129); ADS notes need a message about ADS ('not permitted', 'timeout elapsed', nCycleCount 0x705 of any program no longer get one), name the code and symbol (checked against the local ADS return-code table), and an error the plugin has no note on is known_error: null with what is covered — never searched as words (N130); 'not logged in' is not the logged-in note, and errors the plugin composed itself are not annotated. XAE (N116, N120, N123, N124, N42): every retried COM call takes the System Manager / tree item / Scope object of the live shell (a solution reopened in the same shell failed the first call); an action that must not run twice (activate, restart, PLC online commands, create / delete / import, shell commands, Scope actions) is never repeated — not after a busy read-back (an online command went on to PLC.Download), not on a re-attached shell after the shell went away during it, not after a stale-object error ("may have acted, not repeated"); before an action a stale System Manager is refreshed by a read; solution_mismatch and reattached are on the result of every tool that used the shell; xae_build(save_first) finds a property accessor's file and drops edits of objects deleted since; an XAE token's scope is the machine. Project: a pin (Plc2@MAIN) names the PLC project, not a substring of the path; with several PLC projects, a port means its PLC project in every reader — also when no name is declared twice (proj_variables port, CONSTANT check in full mode, PRG_B of Plc2 on 851), a pin still names another, and a file linked into several PLC projects belongs to each; the PLC projects and files are read in one order on every file system; ENUM / STRUCT return types (N137). Scope (N117, N119): scope_view_log reads the padded [ ERROR ] tags; rec_stop(also_scope) / scope_record save compare the CSV of the saved .svdx with XAE's in-memory export (cross_check); exports go to a work file and replace the CSV only when complete, a sealed CSV is never written over; a .svdx still being written is not sealed into the link. Docs: methods and properties link to their FB (parent / children, FB.Member, N126); the skill's docs_declaration gives the members like infosys_declaration (N103b); one source page placed twice in a book is one hit and the defining table comes first (N99b); a number that is the query is a code, and a code next to its word is found among other numbers (N121, N122). Two independent reviews of the release, and a review of their fixes, found the points above beyond the retest list (among them: the stand-in database of a first read left the first kb_add_project without a search table; ERR_… identifiers, numbers and model numbers were taken for error messages; decoding by a single valid-looking byte pair). N125 (error descriptions from three places) is the error index of the spec — not in this release.

0.8.13 — the 0.8.12 retests (§31, §32) fixed at their cause: N116 (S1), N113, N114, N103b, N105, N117, N118, the Scope View log, and the polish items. Nothing to rebuild after the update (no index format changed). XAE (N116, S1): the XAE tools are bound to one solution — the configured xae.solution_path, the one passed to xae_attach, or the only one open — and every call checks that the shell still has it open; when it was closed they re-attach only to a shell that has that solution, and otherwise refuse ("the solution … is not open in any XAE shell"), never acting on another shell's project or target; xae_attach never falls back to another solution and never picks one of several when none is configured; xae_status reports solution_bound, reattached, solution_mismatch. Project (N113, N114): the PLC projects of the project are those its .tsproj names (inline or in _Config\PLC\*.xti, with tree name and ADS port) — a .plcproj it does not name (the folder of a PLC project removed from the tree) is not part of the project (plcproj_not_in_project, its files in not_in_project, its tasks dropped); when the .tsproj cannot tell, every .plcproj counts and proj_scan says why; a .tsproj / .xti change rescans. Every file's units are kept, so MAIN of Plc2 no longer replaces MAIN of Plc1: xae_build(save_first) checks an edit in the PLC project its tree path names (it refused every build with two MAINs), and rec_start's task check takes the PLC project on the ADS port it records (it said "task configuration not available" with two MAINs, and with one after Plc2 was removed). With names declared in several PLC projects nothing is picked by chance: lists, searches and references show both (proj_list, proj_search); a name in two (MAIN, MAIN.Act, a method name alone) is refused unless pinned (Plc2@MAIN), for writes too; symbol resolution, proj_variables/proj_vs_runtime, pointer aliases, interface and CONSTANT checks use the PLC project on the connected ADS port (the CONSTANT check refuses in guarded mode when that cannot be told); proj_lint, proj_call_graph, proj_interface, proj_validate_xml, tcunit_scaffold and the wf_* workflows run inside one PLC project — a whole-project lint is each PLC project's, merged, every finding tagged plc_project; a .tsproj reference that cannot be followed keeps every .plcproj (said in plc_projects_note). Docs: the skill's docs_declaration gives kind, return_type and the parsed declaration with its header — the same answer as infosys_declaration (N103b: a reader of the skill never saw FUNCTION MEMCPY : UDINT); a symbol's library names query words too (N105: "EtherCAT slave state" lists the Tc2_EtherCAT slave-state symbols first, FB_EcGetSlaveState 5th — no word of the query tells Get from Set, Req or the ST_ type). Scope (N117, N118): rec_stop(also_scope) and scope_record save export the CSV from the saved .svdx with Beckhoff's export tool — XAE's ExportCSV right after SaveSVD lacked the end of the file — and use ExportCSV only without the tool, flagged; whether the saved file still grows after SaveSVD returns is watched and reported; a read-only .svdx (rec_stop seals it) is exported from a byte-identical writable copy (the tool exited 0 without a CSV on it; that read-only is the cause is not proven), and a run without a CSV says exit code, output, size, read-only state; the ERROR entries TcScopeView.log gets during these calls are in the result (scope_view_log, [scope] view_log). Scope robustness: file errors and undecodable tool output are messages, a failed Scope part of rec_stop keeps the stopped recording's result, a non-zero exit with a CSV is flagged, a log without [ERROR]-style tags gives its 'error' lines and says the format was not recognised. Two independent reviews of the work and of their fixes found the points above beyond the retest list. Polish: xae_plc with several PLC projects and none named says that first (it began with "needs a confirm_token … target ''"); xae_plc start/stop/reset while logged out is refused with "log in first" (it returned and did nothing); kb_status → builder_upkeep is labelled as what the server start did; label_reason names every cause of INCOMPLETE in both engines (a RUN→CONFIG→RUN gap was only in errors).

0.8.12 — the EtherCAT device descriptions get an index of their own, and the 0.8.11 retests (N37, N50, N93–N111, D19) fixed at their cause. After the update, once: the Infosys index (format 4 → 5) and the manuals index (page text format 4 → 5) are reported as rebuild_needed and used as they are until you approve the rebuild — kb_rebuild(index='infosys') / kb_rebuild(index='manuals'), or tools\infosys_local.py index / tools\manuals_db.py update; the ESI index index\esi.db does not exist yet, so its first build starts by itself (server start or the first hw_* call); knowledge.db's search table is rebuilt from its stored units at your next kb_reindex / kb_add_project (seconds, no file read again) — until then kb_search uses it as it is and says so. ESI index (index\esi.db, twincat_mcp/esi_index.py, builder esi_db.py): every ESI file of this PC — the .xml files under manuals\ (e.g. Beckhoff's ESI folder in manuals\Beckhoff_EtherCAT_XML) and TwinCAT's Config\Io\EtherCAT — read once: devices with PDOs (per-channel templates, gaps kept), PDO assignments with DC mode and init commands, slots resolved to their modules by rule, CoE dictionaries (sub-indices, array elements, decoded defaults, enum texts), diagnosis catalogues, modules; duplicates across folders by the vendor's FileVersion (also_in / differs_in); streamed device by device. hw_lookup reads it; new hw_search, hw_object, hw_diag, hw_module, and the skill's hw_* commands; knowledge.db no longer holds ESI rows (its old table is listed by kb_status, never dropped). Infosys format 5: a page's kind and return type come from its own evidence (N103 S2: FUNCTION MEMCPY : UDINT written as a heading, or only a return-value table, was a function block with no return type), a title that is a sentence documents no symbol (N101: "Attribute 'linkalways'" was a GlobalVariable), and every title's identifier words are indexed (FB_SocketConnect: socket, connect). One rule for which page documents a name (N100), shared by infosys_declaration, infosys_get_page and the skill's docs_declaration / docs_page: one page in several books is one answer (same_page_in), a C++/.NET page is no IEC symbol, library names compare without case, and different pages of one name — two libraries, or two methods of one library — are refused as ambiguous. One search for both readers (N105, N99): infosys_search and docs_search are the same code — identifiers as words, titles that name the query first, an error code's defining table (hex and decimal in one row) first (code_note), copies listed once. Measured on a copy of the real index with the format-5 words column: of the retest's four misses, FB_FileGets (2nd), FB_SocketConnect and F_GetSystemTime (1st) are now found, "EtherCAT slave state" still lists ST_EcSlaveState / FB_EcSetSlaveState before FB_EcGetSlaveState, and 0x745 lists the ADS return-code table first; on the format-4 index as it is, until the rebuild, the ordering helps less (identifier words are not indexed there). kb_search (N102): names and identifiers count as their words (FB_AlarmList: alarm, list), a unit whose code holds the words comes before a comment-only match (match_in), exact and prefix matches are both listed; one stop-word list for every search. The build lock is probed with a shared lock (N104: two readers probing at once saw a phantom "build RUNNING (0 of ? pages)"). Project (N106): the project is what its .plcproj compiles — a .Tc* file no .plcproj lists (a backup copy, an export) is no unit and is named in not_in_project; a .plcproj change rescans. Recorder: rec_compare works on native-engine recordings (N107 S2); rec_verify explains a counter that went back from the task's cycle counter recorded with the data, never "TwinCAT restart" for a program reset (N111). ipc_eventlog resolves the boot folder (N110 S2: boot: and boot are one prefix). wf_debug_symbol follows the symbol's scope (N111). exp_run(dry_run) archives nothing and says why its plan is short (N108). tcunit_scaffold outside the PLC project is not gated by config mode (N109). An output folder that does not exist yet is created inside the allowed roots (N98). proj_lint: an instance whose creation runs FB_init (a TcUnit suite) is not "never used". Manuals (N37, format 5): text below 1 pt is not page text. N50: an alias of a pointer is decoded from the project source. N93: a restart compares the application it read. N94: an unticked confirmation says so. N95: UTF-8 comments. N96: kb_rebuild checks before it asks. N97 (S2): PLCopen replace keeps foldered objects in their folder. D19: ESI templates. An independent review of the release found, and this release fixes: an ESI description replaced by a newer file left its objects behind (searchable, counted); every Profile of a device is read (their dictionaries joined, differences named); --no-twincat is recorded (no false OUTDATED); a work file left next to a current index is discarded; hw_lookup counts every match (not the first 200) and hw_search counts every variant; % / _ in a device query are literal; an out-of-range number is refused with a message; hw_object / hw_diag / hw_module start the first build too, and an .xml that is no ESI starts none; two pages of one book are never "one page in several books" (two FBs' methods of one name stay ambiguous); truncated says whether hits were cut, not whether copies were merged; a decimal number is an error code only next to a word that says so (error 1861, not port 851); wf_debug_symbol keeps bare uses of a global variable (a GVL without qualified_only) and reads aFill[i + 1].x as a qualifier; kb_search with quoted phrases only lists units with every phrase, and units whose code holds the words are read first; rec_verify counts resets it could not decide and those not assessed separately, and no longer slows down on long recordings with many repeats. Builders: manuals_db.py 6, esi_db.py 1 (new), stub 2.

0.8.11 — the 0.8.10 bug list fixed at its cause (N5, N37, N75–N79), the long-standing ADS stale-address defect, and permanent ground rules for the knowledge base (docs/KNOWLEDGE_BASE.md). After the update, once: the knowledge folder's indexes are moved into index\ (a rename, nothing copied or deleted); the Infosys index (format 4) and the manuals index (page text format 4) are reported as rebuild_needed and used as they are until you approve the rebuild — kb_rebuild(index='infosys') / kb_rebuild(index='manuals'), or tools\infosys_local.py index / tools\manuals_db.py update; helpviewer\infosys_en.db (the builder's old second index) is no longer read — kb_status lists it with its size, delete it yourself. ADS (root): pyads keeps each name's address for the life of a connection, so after a download, an online change or a restart with another build ads_read_many, ads_watch, polled recordings and the restart witness read the old offsets — another variable's bytes with no error. Every read and write by name now goes through a symbol handle made in the same request as the symbol version (0xF008): a handle names the variable, so the runtime answers for that variable or refuses the handle; a value of another symbol version is never decoded (renewed and read again). One sum request per call, per-item error codes, the same value conversion as a single read. ads_dump (N76): max_total_mb is the size of CSV + JSON on disk, known exactly before each row is written (the row, the tree after it, and the largest ending still possible) — nothing estimated; a limit below the files' own frame is refused; the result names written_mib and limit_counts. Restart proof (N75): the after-witness is taken in RUN from the runtime that came back, a counter that ran on outweighs one poll without an answer, the compile timestamp is compared by its number, an unreadable value says why; steps.restart.duration_s lasts until RUN was seen again (N5, command_s the shell part). Confirmation tokens (N78): tc_request_confirmation(action='xae_plc', args=…) gives no token for a PLC project the open solution does not have. Recorder (Python): rows are written in PLC-time order, the root of rows past a later end. Knowledge base: one layout (index\infosys-<lcid>.db, index\manuals.db, index\knowledge.db; manuals\ and sop\ are yours and never written), one Infosys index — the builder runs the plugin's own extractor, and the infosys_* tools and the twincat-docs skill read the same file; text normalised once when indexing (links as page addresses, table cells as plain text with the type's page as type_ref — N77, no invisible marks, no image placeholders); every index records its format and source, and a test fingerprints the code behind each format; the first build of a missing index starts by itself, every later one only after your approval (kb_rebuild, new, control class); builds write <index>.building and swap when complete, the ESI part of knowledge.db changes in one transaction; the plugin deletes nothing. Manuals (N37, format 4): text of font size 0 or fully transparent is not page text — the invisible copy of the running header under every heading no longer doubles headings and toc titles; an update of a complete index changes nothing. Docs search (N79): a query of stop words only is refused, as in kb_search. Builders: infosys_local.py version 3, manuals_db.py version 5. ADS: one STRING codec, Windows-1252, for every read and write (N91: ü failed or was written as two bytes; a character a STRING cannot hold, or a text too long, is refused before anything is written). D5: BOOL members read as 1/0 — the 4026 datatype table aliases BOOL to BYTE and the decoder followed the alias; a scalar alias now decodes by the first elementary name of its chain (BOOL stays BOOL, TYPE T_Level : UINT is a UINT), else by the runtime's data type id — an enum with an unsigned base reads unsigned. Values as a read returns them (an enum {value, name}, a TIME {raw_ms, text}, arrays of them) are accepted back by writes, snapshot restores and comparisons, and ads_wait_until sees an enum condition that already holds. N50: an unknown type name was sized by guess; the datatype table decides now, so a TYPE PT_X : POINTER TO … alias is an address with the pointer note in ads_read, ads_read_many, ads_dump and recordings. Recordings (R43): a recording is of one program — a block sample is written only once a symbol version read taken after it returned the version the recording started with; a download or online change ends the recording at the last verified sample (program_changed), a restart of the same program continues (program_watch.notes), samples never verified are counted (unverified_rows), not written; the start refuses addresses resolved against another version. A sample that reaches the recorder after its last drain is counted in after_limit, none twice. Native engine (N84): rows before a trigger window are counted (rows_before_window) and skipped by the readers and rec_verify. Confirmations (N89, N90, MCP SDK 2.3): on MCP 2026-07-28 a server cannot call the client, so the in-chat confirmation never reached you on 0.8.10; the question is now returned as an input-required result (sealed by the SDK, bound to the tool, its arguments and 600 s) and elicitation/create is kept for earlier revisions; a refusal says what blocks the prompt (the client declared no elicitation, or the transport has no channel); tc_doctor → elicitation (works, route, why). Every error reaches the model with its text; a defect says its type and is logged under a crash id. XAE (TE1000 Automation Interface): xae_plc uses ITcPlcOnline on the PLC project first (Login with its flags, Logoff, Start, Stop, Reset cold/origin, the state read back — method), then ConsumeXml (a refusal carries GetLastXmlError), then the shell's commands; xae.silent_mode (opt-in) sets TcAutomationSettings.SilentMode for one confirmed activate / restart; xae_check_all_objects (N82) clears the Error List and reads only the Build pane lines of this run, a failed check returns its findings; a graphical body (CFC, FBD, LD, SFC) is recognised by ITcPlcImplementation.Language before any text is compared (N81); PLCopen import options come from the live type library (the two TE1000 pages disagree on REPLACE / RENAME) and the value used is in the result; xae_pou_create(kind='property') creates the Get/Set accessors (N80); activate / restart compare the application's compile timestamp before and after (plc_application); xae_tree_get names TIRT for tasks (#28). Dialogs (N85–N87): a call held by a modal dialog it opened is reported after about 2 s with the dialog's title, text and push buttons, every XAE call is refused until it is answered, and the call's late result is in xae_dialogs; check boxes and radio buttons are listed as options and never clicked (N86); a dialog already open when a call starts is reported (N87); xae_deploy stops before its next step (with what was done) when a step left a dialog waiting; a progress window (Cancel only) stops nothing. An ITcPlcOnline command whose state does not follow within 5 s is reported as possibly done and never sent again through another route. Project (N88, N92): the project index is built aside and published whole — parallel ads_dump calls no longer report "no project configured", and no tool sees a half-built index; a PROGRAM or GVL of the source with variables but no symbol on the target is named by ads_dump (not_on_target) and proj_vs_runtime (roots_not_on_target) with its cause, and xae_build names GVLs nothing in the source references (link_warning: TwinCAT does not link them; {attribute 'linkalways'} does); with several PLC projects only the one whose symbols the target has is judged, and a name declared twice is never called missing; a // or (* inside a string literal no longer hides code from this search or from proj_lint. ads_dump (N47): a cut dump fills its limit (the 0.8.10 estimate left files at 64–67 % of max_total_mb). Infosys: a page is answered from the Help Viewer package while the first index is still being built (it failed with "no Infosys index yet" once converted). R30: the infosys_* descriptions describe the configured source. kb_status → builder_upkeep.pointer: written / unchanged / why not. D19 still needs the ESI file.

0.8.10 — 0.8.9 retest fixes at their cause (N38–N69, R40, R24; D19 still needs the ESI file) and an independent review of every fix. After the update, once: the Infosys index is read again in the background (R24 parser and code-space change, INDEXER_VERSION 3), and the manuals are read again (TEXT_FORMAT 3) — the first docs lookups say "rebuilding" until it is done. XAE: plcopen_import(option='replace') checks the copy against the imported XML (TwinCAT's plain-text declarations and ST bodies — methods, actions, property Get/Set — are the oracle, not the copy TwinCAT made), renames the declaration header back (PROGRAM PRG_X_1 → PRG_X; an unrecognised header, or the copy's name anywhere the XML does not hold it, writes nothing), checks the declared name after writing independently of the written text, and keeps every copy whose original is not verified (N38, N43–N45); a body that is not ST (CFC, FBD, LD, SFC, IL) is refused with the copy kept; a 'replace' whose project tree cannot be listed is refused before anything happens. xae_plc resolves the PLC project once and every route (ConsumeXml, named DTE command, generic command) acts on exactly that project; with several projects and none named, or a project list that cannot be read, nothing is guessed (N41). Confirmation tokens: the server computes the target every guarded tool checks (xae_plc → <action>:<project>@<NetId>, xae_command → <command>@<NetId>, xae_boot_project, xae_tree_delete), and tc_request_confirmation(action, args=…) uses the same rule — a token can no longer be issued for one project and used on another (N40, N42, N69). Restart proof (R40): a witness (mode, task 1's CycleCount, the application's compile timestamp) is taken before activate / restart; proven by a poll seeing another state, a start from CONFIG, a counter that went back, or a changed timestamp; "in RUN, restart not proven" is reported as that, never as "not in RUN"; a frozen counter is "cannot tell", not a restart. Infosys (R24): Help Viewer code keeps non-breaking spaces; they are normalised where the page is read, so infosys_declaration gives FUNCTION F_GetTaskTime : ULINT without a VAR_OUTPUT. Manuals (N37, N66, TEXT_FORMAT 3): running headers, footers and margin labels are found by their place on the page, not by repeated text — the section-title header and a footer with the page number first are removed, table header rows repeated at the top of continuation pages stay; a space set in its own font is kept ('Note that', not 'Notethat'). Knowledge folder (N64, N68): the builder stubs replace only files this plugin shipped (sha256 list, any line ends); your own scripts (*OLD.py …) are left alone; the pointer to the plugin is written before the stubs; a finished Infosys rebuild that is being swapped in reads as running, not as 'waiting — run index again'. Knowledge base (N70–N74, from your retest SOP): kb_search knows ADS errors in any notation (ADSError 1861, ADS error 1861, ADS-Error: 0x00000745, 0x745) and the compiler messages identifier not defined (C0046), cannot convert type (C0032) and unknown type, with the quoted names in cause and fix; an error message (a quoted name, an ADS code, a hex number, a C-number) is searched in the code only for the names it quotes; stop words are not searched (a query of nothing else is refused) and in the some-words tier words on no unit or on most units are not used (each hit names its matched words); a copy name no unit has (PRG_TcUnitRunner_9) falls back to the name it was copied from and says so; hw_lookup takes detail = newest (default: PDOs and CoE objects of the newest revision of each type, each type's newest listed first) / summary / full, and revision as shown (#x…) or as a number; infosys_declaration gives an FB's or interface's methods and properties as their own lists (by the page's headings), no longer inside description. Docs search (N65, N67): tiers "all words found in the index" → "some words" (which words each hit holds; stop words, words on no page and words on most pages are named and not used), a page titled like a query word first; a product code without its revision falls back to the base code (matched_as). Launcher (N46): a new venv is built beside the live one and swapped in on a later start when another window still runs the server; an older pending build never replaces a newer install; a health-check timeout is "unknown", not "broken". ads_dump (N39, N47–N55): every root read in bounded pieces (no 1802 for a big variable), a root that cannot be read named in the result, the CSV (NOT READ) and the JSON footer (complete: false); CSV and JSON come from the same decoded leaves; CSV header path,type,value,note (why a cell is empty: not expanded, no storage, outside the symbol); a NULL pointer is the address 0x0000000000000000; sizes in MiB; both files moved into place or neither, a partial commit reported as such; file names unique per dump (-2, -3 in the same second), an existing file is never overwritten (not even one that appears during the commit); a leaf the datatype table places past the symbol is never read from the neighbour's bytes — it is listed in unreadable_leaves, marked in both files, and the dump is not complete. ads_leaves(with_values) reads only the head of a value that is not expanded and says why a value is missing (value_note). Writes: a POINTER TO alias (TYPE PT_X : POINTER TO FB_X) or an alias of an interface is refused like the type itself. Recorder (N56–N63): rec_stop ends at the newest PLC time received and waits (at most max_delay_ms + 1 s) until every block has been seen at or past it — footer stop_on_request; in the Python recorder every other end at a PLC time (duration, post_trigger_s, stop_when, max_events) waits the same way (footer stop_at), so another block's samples still in transit are not lost (rows a block that ran ahead wrote past an end set later are counted as rows_after_window and skipped by rec_read, rec_stats, rec_export and rec_verify); rec_verify checks the file independently (its own window, one period of allowance, block_ends), reads a ≤ 0.8.9 stop as INCONCLUSIVE instead of lending it a tolerance, says INCONCLUSIVE for a change / poll recording without a counter= check that ran (intact, but nothing shows it complete), and fails on a block that never delivered or on symbols that could not be subscribed (a block that could not be registered with allow_partial is not counted as a block that never delivered); a block with one sample or none is counted with the other blocks' period (it read COMPLETE); counts in integer 100 ns ticks in both engines; a trigger with pre_trigger_ms 0 checks the head; a level start_when that was true only during the warm-up is reported (and a later fire is not reported as delayed); exports are written to a temporary file and moved into place, never over the recording; the recording's cycle_ms is compared with the task that runs each recorded program (per PLC project). TestBench.expect compares addresses as addresses (null matches a NULL pointer).

0.8.9 — 0.8.8 retest fixes (R42, #10, R7, R41, R15, R23, R11, R24, R32, N31, N32, N34–N37), the knowledge-folder builders in the plugin, and Python 3.12 as the one version (minimum and the only one tested). Python: requires-python >= 3.12, tomli dropped; the server, launch.py, launch.cmd, install.cmd, kb_docs.py (was 3.9) and the builders refuse an older Python with one line naming the version found; a venv an earlier plugin built on 3.10 / 3.11 is rebuilt with the configured Python on the next start; CI runs Windows and Linux on 3.12 only. ads_dump (R42, S1): a POINTER TO / REFERENCE TO / interface is dumped as its address and never expanded as the target (TcUnit's 1,000 POINTER TO FB_TestSuite had produced 4.7 GB of fabricated members); the pointer width comes from the declared size (4 bytes on a CX9020); one leaf budget (max_leaves) for CSV and JSON, max_total_mb measured on the bytes written, the root being written included; the JSON is written root by root (a cut root is {"_truncated": true, "_leaves": …}, NaN/Infinity as strings); the project's own programs and GVLs first, library globals (GVL_TcUnit, Global_Variables …) last; cancellation is checked inside a root, and a dump whose call already ended (timeout) deletes its .partial files instead of renaming them; the timeout names the phase, root, leaves and MB instead of router/firewall; the result names truncated_reason, skipped_roots, largest_roots. XAE: the outer PLC node and its nested <Name> Project are one PLC project (#10 — no more 'ambiguous' and the slow DTE fallback); plcopen_import(option='replace') that TwinCAT turned into a renamed copy at the project root (PRG_X_1) is finished by the tool: both objects read and compared at every level, the copy's texts written into the original, read back and compared, the original restored if anything fails, the copy deleted only once its original is verified (R15); a 'replace' is refused when the project tree cannot be listed; StartRecord returning 1 is a note, not a warning (R11). Recorder: native level triggers fire only after every notification block delivered (or 2 s), so every block starts at the trigger cycle (R41); rec_verify uses the engine's tail rule after a stop on request (R7); cycle_ms below the fastest task is flagged with fastest_task_ms (N31); an earlier export at the default path is only replaced with overwrite=true unless the re-export is identical — replaced says what was replaced (N32). Infosys / docs: a name documented in several libraries is refused with every library and page instead of picking one (R23); a function's return value is no longer listed as VAR_OUTPUT, also with a reconstructed header (R24); type names wrapped in narrow table columns are joined when a page is read — on the page's own declaration or in a Type column — and zero-width characters dropped, without rebuilding the stored index (R32, checked on synthetic pages only); hw_lookup takes the order code out of the ESI type (CX9020 EtherCAT slave, N34); near answers from titles (N35); docs_search / manual_search fall back from all words to prefixes to some words, match says which (N36). manuals_db.py version 3 (N37): running headers, footers and margin labels are removed from the page text (also where glued to a heading), a heading wrapped over two lines is one toc entry; an index of the older page text format is reported outdated and the next update reads every manual again. Builders: the knowledge-folder builders ship with the plugin (skills/twincat-docs/builders/infosys_local.py version 2, manuals_db.py version 3). They need Python 3.12 and say so on an older one instead of a SyntaxError (version 1 claimed 3.9 but did not compile below 3.12); they find the knowledge folder like the other tools (--kb, TCMCP_KNOWLEDGE_DIR, kb_set_location, the folder above the script). Infosys index: a rebuild writes <db>.building and replaces the index only when complete, one build at a time (<db>.lock, heartbeat) — an interrupted index --force can no longer leave a half index that the next run calls up to date; a version-1 index is upgraded by the next index. The real state (complete / outdated / old format / incomplete / missing, a rebuild running / interrupted / waiting) comes from stats --json, from every kb_docs.py answer (source.state), from kb_status → docs, from tc_doctor → offline_docs, and from the instructions the server sends at every connection and reconnection. search --book / --doc filter before the row limit; show / decl refuse a name several pages share and list them; links are kept (table link, ms-xhelp ids resolved) and docs_page / docs_declaration return them as refs. Manuals: one update at a time, state and progress in a meta table, PDFs not indexed reported. CI checks kb_docs.py on Python 3.9 and the builders on 3.12 (and their refusal below). Docs: skills/twincat-docs/builders/README.md.

0.8.8 — offline documentation as a skill, kb_* tools aligned with the knowledge folder, R33–R39. New skill twincat-docs (skills/twincat-docs/: SKILL.md + kb_docs.py, standard library, read-only) over the databases the knowledge folder's own tools build — helpviewer\infosys_en.db (tools\infosys_local.py, every Infosys page of the Help Viewer package) and manualsdb\manuals.db (tools\manuals_db.py, PDF manuals): docs_search, docs_declaration, docs_page, docs_books, manual_search, manual_product, manual_toc, manual_page, manual_docs, status, one JSON object each, with the builders' ranking, snippets and page references; a name in several libraries is refused as ambiguous with the candidates, filters run before the row limit (total exact), ranges are refused rather than clamped, invalid FTS5 is retried once as a phrase, ms-xhelp links open via the help id; the twincat-mcp skill and the server instructions send documentation questions there, never to ads_*. kb_status → docs: both databases with counts and package stamp, the PDFs not indexed / changed / gone, the folder's tools and SOPs, the exact command for this folder; kb_set_location names the documentation it finds and without arguments returns the current folder (R38); hw_lookup lists the manuals that mention the product code. Fixes: the whole ~/.claude/plugins tree is refused as a location (R33); reads never write-probe, a choice probes under a name of its own (R34); one project per folder in any spelling, the label works for project=, kb_reindex and kb_remove_project, earlier double entries merge (R35); kb_search finds units with every word first, then every word as a prefix (CounterMod → FB_CounterModule), only then some words (match says which), "quoted" phrases (R36); punctuation-only queries refused with a message (R37); kinds, project, limit checked (R39); relative paths refused; a label shared by two folders is not removed blindly.

0.8.7 — 0.8.6 retest and robustness pass (R1–R32, D46, D29, N29, #10/#45, D19). Safety of side effects: tools write files only inside known folders (recordings, project, solution, scope export, experiments, audit log, plus [server] output_dirs) and never replace an existing file without overwrite=true — rec_export, ads_dump, ads_export, tc_session_report, scope_record, scope_export, tcunit_scaffold (R4); tc_request_confirmation issues tokens only for real tool names (R2); tc_session_report returns a 25-line preview unless inline=true (R12). Workers: ads_dump runs on its own worker and writes *.partial files renamed on success; a queued call whose timeout ran out is withdrawn and says what the worker is busy with instead of cancelling the running job (R6). Recorder: every numeric rec_start argument validated before anything starts (R9); conditions refuse operator-led values, unknown types and bad literals and resolve enum names (R10); rec_snapshot reads the file for recordings of an earlier session (R13); counter checks per segment across PLC resets (D46); armed is false once the trigger fired or the recording ended, native engine included (N29); native tail slack after a manual stop (R7); rec_profile_start starts all groups on one PLC cycle via a shared CycleCount trigger, align=false for the old behaviour (D29). XAE: PLC paths split into the outer ITcPlcProject and nested ITcPlcIECProject item (R14); xae_plc login/logout/start/stop and Check all objects go through the Automation Interface (ConsumeXml online commands, CheckAllObjects) before the DTE commands (#10, #45); plcopen_import reports added objects and refuses a 'replace' that created duplicates (R15); COM methods invoked as methods (R11). TcUnit: results counted from the test cases, suite attribute mismatches reported (R3). Infosys: small lookup tables of what is indexed (catalog, code blocks, help ids) built once in the background — no page is re-parsed and no warm-up query runs (R18); code search normalises non-breaking spaces, ignore_spacing, validated languages (R17–R22); ms-xhelp links become page URLs, images and empty links removed, declarations tidied, quoted phrases kept, ambiguous declarations name also_in (R23–R32). Also: readable spec errors with line/column (R1), the 'datatype table unavailable' answers carry the config hint (R5), RPC 1797 explained with the parameter sizes (R16), unparsable ESI PDO rows carry the raw element (D19, parser v3).

0.8.6 — 0.8.3 deep test, last part (D20, D25–D29, D32, D38–D43, #10, N19b). XAE: xae_build / xae_diagnostics parse the 4026 compiler format File.TcPOU@Method(9) : error: C0185 … (file, object, line, column, code; they were empty, D41); xae_diagnostics reads the Error List late-bound (the cached 7.0 DTE wrapper has no ToolWindows), copies the Error List view when the automation interface reports nothing (TwinCAT's own Scope / Measurement warnings), merges the Build pane and names each source (D20); xae_plc login/logout finds Solution Explorer the same way and selects the PLC project node, then uses 'Set as Active PLC Project' where the shell offers it (#10); xae_status with no solution says so instead of a raw COM error. TcUnit: proj_libraries scans the 4026 repository ProgramData\Beckhoff\TwinCAT\PlcEngineering\Managed Libraries (D38) and gives effective for profile-managed placeholders (the only installed version, else "profile", N19b); tcunit_scaffold arranges enum inputs with a real member (E_Command.None, not E_Command.0) and lists the stub tests that fail until written (D39); tcunit_run refuses before activating anything when the project leaves GVL_Param_TcUnit.xUnitEnablePublish FALSE, stops waiting when the PLC reports FALSE, and names the resolved boot: folder (D40); its token target is the NetId (D43); xae_tree_delete tokens name the item (D42). Recorder: rec_pulses duty_percent over complete periods (the idle lead-in counted, D26) and the open first run is no pulse; rec_profile_stop after the profile ended gives the final status (D27); rec_profile_list updated always ISO (D28); rec_profile_start reports each group's start_offsets_ms from the PLC timestamps (D29); rec_snapshot counts a finished native recording's events (D32). Infosys: the background index reports pages inside the current book and seconds_since_progress (D25).

0.8.5 — 0.8.3 deep test, second part (D33–D37, D44, D45). xae_build(save_first), xae_deploy and tcunit_run (which did not save at all; new save_first) run File.SaveAll, save each document/project the shell still reports unsaved, and check every xae_pou_set / xae_pou_create edit of the session in the source files — they refuse to build while one is missing (an external reload had discarded edits that were only in the shell, D44); save in the result lists what was dirty before and after. Experiments: a condition that already holds at a recording's first sample is its initial state, not an edge — no latency is measured from it (the first-sample "1 ms" values that passed a criterion, D34); a latency between symbols in separate change-mode notifications is not reported (timestamps up to cycle_ms off, order not kept — use cycle mode or one notification; rec_latency returns timing.trust exact / quantised / unreliable, D35); measures use the samples up to the start of the after steps (last read the reset value, D33); exp_abort still runs the current run's after steps, marks that run aborted and ends the experiment aborted also when it was the last run (abort_received shows when it arrived, D37); the 95 % CI of a count or duration is clipped at 0 and never narrower than the timestamp resolution (ci95_note, D36). tc_doctor: TwinCAT in CONFIG is reported as info, not as a problem (D45).

0.8.4 — 0.8.3 deep test (D1–D31, N5, N27–N30, #17, #20, #28, #56, #78, A5). Recordings: a PLC STOP (cycle counter frozen while 1 ms notifications keep coming) is a {"_stall":…} line, counts as missing and labels the file INCOMPLETE with label_reason (D11); the native engine re-subscribes when every block went silent, e.g. after RUN → CONFIG → RUN (D13, resubscriptions in the footer); live status counts silent time as missing (D14) and stops on the PC clock when PLC time no longer advances (D15); a recording that ends by itself is sealed at once and a start-up sweep seals any left unsealed (N27); rec_read(wide=true) gives one row per PLC timestamp with null where nothing was sampled, fill=true marks filled cells (D9); counter completeness capped at 1 with duplicates reported (D12); armed false once triggered (N29), values_per_s counts array elements (N30); rec_list pages the session list too (D21). rec_start(pattern=…) selects exactly the leaves rec_scan lists: */? wildcards, [ ] literal (GVL_Sim.aCh[1].*), a leaf matches when it or a parent matches (A5); prefix may name one element of an array of structs (D31). ads_wait_until / ads_watch use scratch recordings that are always removed, interval_ms honoured (D7, D6); top-level enums read as {value, name} (D4). exp_run writes the stimulus only after every recording delivers (D22). xae_restart_twincat / xae_deploy count a restart only after the target was seen leaving RUN and coming back (modes_seen, transition_seen; the first poll read the old runtime's RUN, N5/#4). ADSError 6 is explained for the port that was asked (D24). proj_vs_runtime gives no missing/extra verdict from a list cut at max_items (complete, not_judged, D23), keeps the PLC's and the source's spelling (#20). xae_tree_get walks the nested <Name> Project (#17). ipc_eventlog never guesses the boot folder and reports whether its temp file is really gone (#56). Infosys: one transaction per book, FTS optimised once, external-content FTS (10,000 synthetic pages in 11 s here, DB −30 %; not yet timed on the real package), CRC-based page identity so an unchanged package (or the same package on another PC) is never re-read, re-index only when the indexer version changes (an existing 0.8.3 index rebuilds once), progress names the book being indexed (D1, D25); version only from Microsoft.Help.DisplayVersion (D2); answers carry doc_date + indexed_books_count instead of the book list (D3). proj_lint real_eq ignores := (D17); proj_interface inherited members have file (D16); proj_variables keeps the CONSTANT qualifier (D18); hw_lookup reads namespaced ESI files (PDOs, entries, CoE; ESI files are re-read once, D19). Scope found through IMeasurementScope (N28, not yet run on hardware). D8: the server already published engine / also_scope / scope (a regression test now pins them) — a client that does not show them is using a cached schema.

0.8.3 — Infosys offline from the Help Viewer package. docs.source = "local" (default) reads the BKINFOSYS3_*.mshc TwinCAT XAE installs (found under %ProgramData%\Microsoft\HelpLibrary2, or [docs] mshc): every TwinCAT 3 book indexed in the background (default books first), pages keyed by their real infosys.beckhoff.com URL, no network call and no web fallback; results carry the doc version and the package date; a new package re-indexes, an unchanged one is never re-read; index next to the knowledge base. Missing package → the infosys tools say where they looked and how to fix it (docs.source = "web" keeps the website path). Infosys tools no longer crash when the index is disabled.

0.8.2 — TwinCAT Scope next to the ADS recorder. scope_export runs Beckhoff's TC3ScopeExportTool.exe ("svd=<file>" target=<csv> silent, TE130x / TF3300 folders, [scope] export_tool) on a saved .svdx, never edits its CSV, and writes a signed <csv>.provenance.json (source and tool SHA-256, command line). Through the XAE Automation Interface (IMeasurementScope of a Measurement project): scope_list, scope_record start / stop / save (SaveSVD + ExportCSV into <recordings>/scope). rec_start(also_scope=true, scope=…) starts the Scope configuration with the recording; rec_stop stops it, saves <id>.svdx, exports <id>.scope.csv (falls back to the export tool) and writes a signed <id>.scope.json with both SHA-256s; the files are read-only. [recorder] also_scope = "ask" (default) asks the user whenever XAE has a Scope configuration open — by prompt, or with allow_elicitation = false by an error telling the agent to ask and call again; always / never. New tool group scope; 155 tools. The XAE Scope calls are late-bound against the documented interface and not yet run against a real Scope View.

0.8.1 — recording authenticity (field report R1–R12) and the 0.8.0 retest. Both engines write {"_gap":…} lines where samples are missing (inside the run, before the first and after the last sample), a footer label COMPLETE / INCOMPLETE / NOT_PROVABLE, and a signed {"_chain":…} checkpoint (running SHA-256 + HMAC) every second, so a file whose footer never got written is still proven intact up to its last checkpoint. After a recording ends it is sealed: <id>.manifest.json (whole-file SHA-256, footer checksum and signature, summary, HMAC-signed) and both files read-only; rec_verify checks every checkpoint, names the first bad line, checks the manifest and reports read_only; rec_delete clears read-only and removes the manifest. Every export writes a signed <export>.provenance.json (source file and SHA-256, footer checksum, label, seal state, parameters incl. fill, exporter version, export SHA-256); CSV gets an exact time_utc column (7 decimals, integer maths). The header records each symbol's datatype GUID, base type and (structs recorded whole) member layout. Retest: N13 duration stop waits ≤ 1 s for in-flight samples up to the cut (lossless runs no longer FAIL by 3–10), N17 ADSError 6 explained from port and RUN/CONFIG, N18 PROGRAM calls in proj_call_graph, N19 (System) placeholders are info, N21 infosys names the books being indexed and the real backend, N22 BOOL writes accept only true/false/0/1, N23 rec_capture explains missing stats, N24 edge_triggers in the header, N26 project index scans serialised, #66 tcunit ProductVersion from the project. N25: tcmcp-capture.exe now ships in the plugin, built and tested by the release workflow (release/v* branch → exe + SHA-256 committed, tag, release with zip, .mcpb, SHA256SUMS, build provenance); the server refuses an exe whose SHA-256 differs from the pinned one; /Brepro makes the build deterministic.

0.8.0 — native capture service (C++ capture spec). tcmcp-capture on Beckhoff's AdsLib (vendored, MIT) in TwinCAT mode over TcAdsDll.dll, bound at start so CI builds the exe without the TwinCAT SDK (-DTCMCP_TCADSDLL_SDK builds against Beckhoff's headers and lib, same layout asserts); AdsLib standalone elsewhere. Lock-free per-block rings, PLC-time merge, format-2 file byte-compatible with the Python recorder (spec test 10: identical rows and exports), SHA-256 + HMAC footer, head/gap/tail/overflow accounting, triggers and stop conditions evaluated on raw bytes, all-or-nothing subscription, clean stop when the server goes away. rec_start / rec_capture engine parameter, [recorder] config section, engine and reason in every response, tc_doctor → recorder. Python recorder: pre-trigger samples that are discarded no longer count in the block timeline; window_start_ms (trigger − pre_trigger_ms) and missing_head; rec_verify fails on overflow and on a FAIL verdict hint. Simulator backend + 15 tests for spec items 1, 5–10. 151 tools.

0.7.2 — knowledge base and the 0.7.1 retest. Knowledge base (decisions of 2026-10-17): the database lives in a folder the user names (kb_set_location; checked: local fixed drive, not cloud-synced, not the plugin folder, writable, ≥ 1 GB; D:\TwinCAT-MCP\knowledge only when the user agrees); kb_add_project / kb_search over folders the user adds (nothing by default); hw_lookup (PDOs, CoE objects from TwinCAT's ESI files); proj_libraries (what each library reference resolves to on this PC); known causes/fixes attached to tool errors. Recorder: above 20,000 values/s nothing is decoded on the ingest thread (300 leaves × 1 ms lost samples because decoding starved the ADS callback); the GIL switch interval is 0.5 ms while recording; the missing tail up to the window end is counted (N11); responses trim long arrays; triggers on elements of recorded arrays and edge_triggers. rec_delete needs a confirmation and the audit keeps the file's SHA-256 (R11). Interfaces are recognised from the project source when the datatype table does not mark them: reads as 0x…, writes refused (#52/#64). tc_allow_write tokens for the pattern as typed (N1); session allow-list kept over tc_reload_config (N6); writers scoped to the declaring unit (N3); System Manager refreshed after a solution reopen (N9); env overrides of TOML values reported (N10); external tcunit_scaffold not gated (N12); restart duration_s until RUN (N5); Check all objects selects the PLC project node and reports the real refusal (#45). 151 tools.

0.7.1 — decisions of 2026-10-17. The CONSTANT check runs on every write path (snap_apply, test_*, exp_* too); with no project source loaded, guarded mode refuses writes and full mode allows them. Recordings carry a manifest (AppTimestamp, OnlineChangeCnt, tasks and cycle times, TwinCAT build, symbol version) and, in cycle mode, the task's per-cycle counter as ground truth that rec_verify uses automatically. csv_wide is one row per PLC sample time with array elements as columns; empty cell = not sampled then (fill=true for charts). The example config carries the agreed machine-PC settings (allow_elicitation = false, edit_requires_config_mode = true, tool groups, narrow allow-list). 143 tools.

0.7.0 — recording accuracy and field report round 3 (A1–A7, #75–79, P2–P19, K1). Recorder: one ADS notification per contiguous memory block instead of per symbol (the field test: 300 values as one block lossless, as 300 notifications ~5 %); the callback only copies the raw sample; file format 2 keeps the runtime's raw bytes and exact PLC FILETIME per sample, a symbol table and block layout in the header, and a signed SHA-256 footer; missing_samples/completeness per block from the PLC timestamps, dropped, dropped_on_stop; a stop drains the backlog to the file; duration is PLC time; a notification that cannot be registered fails the start (allow_partial); patterns expand to leaves like rec_scan; live statistics step aside under load and rec_stats recomputes them from the file; new rec_verify (integrity, timeline, per-cycle counter) and rec_capture (record → stats → verdict in one call); the acceptance run proves a lossless recording of _TaskInfo[1].CycleCount at the task cycle. ads_watch / ads_wait_until on ADS notifications, off the ADS workers; ads_write_many as one sum-write (all values in the same PLC cycle); writes report written vs read_back; symbol/datatype caches follow the runtime's symbol version instead of a 300 s timer; ads_system_mode waits for the requested mode; COM calls blocked by a modal dialog fail within a second naming it; xae_deploy fails unless the target runs afterwards; tc_doctor one-line summary (verbose for the config); server.tool_groups; launcher skips hashing unchanged sources; Infosys indexes the books of the libraries the project references. Older recording files stay readable. 143 tools.

0.6.3 — field report round 2 (items 51–74, framework project with inheritance, interfaces, enums, strings, arrays). Writes: an array write must supply every element (a short list zeroed the rest); POINTER/REFERENCE and INTERFACE variables are refused (an interface is a pointer the PLC calls through) and read as 0x… hex or null; writes to anything declared in a VAR … CONSTANT block are refused from the project source (the runtime does not flag them READONLY); STRING(n) length is checked before ADS; enum names are accepted (Idle, E_State.Idle) in ads_write and test_expect; ads_write_many pre-checks every item before the first write and reports applied/failed/not_attempted if the PLC rejects one. Recorder: duration_s no longer compares the PLC's task clock with Windows time (cycle mode ran on for 30 s), rec_stop keeps its own stop reason, the file is flushed every second, post_trigger_s ends a triggered recording after the trigger. Project: the index refreshes incrementally (mtime) before every index-based tool; proj_vs_runtime matches x[*] source arrays to their elements, collapses arrays and caps output; proj_call_graph follows interface calls to every implementing FB, inherited methods and THIS^ overrides; proj_interface merges the EXTENDS chain (inherited_from) and inherited IMPLEMENTS; wf_debug_symbol no longer calls fb(x := y) a write of y and lists .TcVIS input-action writes; tcunit_scaffold takes the project's ProductVersion, keeps declared input defaults, includes inherited methods; empty_method skips interface/abstract methods; C# enums use the declared base type. Safety: confirmation prompts read DESTRUCTIVE: <tool> / Target / Machine / Mode / Effect, the audit records how long the prompt was open and flags sub-1.5 s answers, safety.allow_elicitation = false forces the token path, safety.edit_requires_config_mode = true refuses code edits unless TwinCAT is in CONFIG; destructive XAE tools refuse via the guard even with no shell attached. IPC: ipc_eventlog is confirmed as itself, lists the registered TwinCAT/Beckhoff providers, deletes its temp file; boot: resolves to the live 4026 folder (ProgramData), not the stale C:\TwinCAT\3.1\Boot. ADS errors 6/7/1797/1808/1861 carry a plain-language hint; TOML config loads on Python 3.10 (tomli). 141 tools.

0.6.2 — second and third field reports (50 items, same engineering PC). Integer writes are range-checked against the ADS type and BOOL accepts only true/false/0/1 — 70000 into a WORD is refused, not wrapped to 4464; tc_set_mode escalation needs a confirmation (lowering stays free); confirmation tokens for XAE destructive actions are bound to the shell's real target at issue time; ipc_list_dir boot:* resolves the real boot folder by probing (FFIND ignores path ids) and drops ./..; proj_read_file is confined to the project roots; 4026 PLC command names (PLC.Loginto<Project>) are discovered from the shell and the project node is selected when none is active; the nested PLC project node (ItemType 56) is recognised and walked; experiments gain run.ack: falls|edge|none, ack_timeout_ms, wait_ms/wait_until steps, after as cleanup on failure, resume=false archiving earlier runs, spec_version on every run; BOOL leaves keep their declared name on 4026 tables; library FB members are expected in proj_vs_runtime, counted as instances by proj_references, shown as leaf calls in proj_call_graph, resolved via the runtime in proj_resolve_symbol; => x counts as a write; unqualified type names resolve when unique; confirmed actions audit their final outcome (ok/error); rec_latency reports absorbed edges; Infosys DB in WAL mode with serialised indexing; clearer EtherCAT/IO/HMI/AppTimestamp/raw-write messages. Third report: xae_build check_all_objects=true discovers the shell's actual command name (PLC.CheckAllObjects, localized or 4026-prefixed variants) instead of assuming one; a shell closed and reopened behind the server (RPC_S_SERVER_UNAVAILABLE 0x800706BA) is re-attached automatically on the next call; proj_lint reports root/files_indexed/parse_errors and says plainly when proj_scan has not run instead of units: 0; eof_newline removed (XAE never writes one) and lineids_missing only fires when a POU is inconsistent (some blocks have LineIds, others not); hmi_scan parses TF1800 .TcVIS files — VisualElemMember paths are read bindings (kind tcvis, tagged with the member id name where known), ST input-action assignments are write bindings (kind tcvis_write), so hmi_vs_runtime covers classic visualizations; xae_status attaches to the shell itself. Not done: TwinCAT Scope/Measurement control (IMeasurementScope is not IDispatch — needs a .NET host) and visualization creation (.TcVIS is an opaque XmlArchive; editing it blind would corrupt the file). 141 tools.

0.6.1 — field fixes from the first real session (Windows 11, TwinCAT 3.1.4026, engineering PC): the launcher no longer blocks the MCP handshake on first start — it builds the venv in a detached background process (exit code 5, reconnect once; a SessionStart hook pre-builds it; --sync-install keeps the old behaviour); template placeholders (<CX_NETID>, C:\path\to\…) and malformed AmsNetIds are dropped with a config_FIX_THESE list in tc_doctor instead of being loaded; tc_allow_write (session allow-list entry, confirmed, audited) and tc_reload_config (apply list-type settings without a restart); xae_restart_twincat / xae_activate_configuration verify the target's mode over ADS and the shell's dialogs and fail with the dialog text instead of reporting success; TwinCAT license errors (0x98110724) mapped to the 7-day-trial remedy; rejected COM calls name the open dialog; a cancelled confirmation prompt is distinguished from a decline; recordings end at their limit immediately and release their notifications from the ingest thread (rec_status no longer lags, rec_export rows == events, footer reported); Infosys default books index in the background on first use; python -m twincat_mcp.acceptance exercises every tool against the live PC/target with a PASS/FAIL/WARN/SKIP/MANUAL report and guard-refusal proofs. 141 tools.

0.6.0 — experiments (12 tools): YAML spec, background runner with snapshot/profile per run and factor restore, measures from recordings (last/latency/pulses/settle/dwell/edges/expr…), metrics with t/χ² CIs and Cpk, pass/fail/inconclusive verdicts with n-to-settle, Markdown+HTML report with identity/charts/audit/interpretation, compare. Capture profiles (7 tools): rec_scan of runtime or source with cost estimates and a markable checklist, {attribute 'tcmcp.record'} pragmas collected through proj_variables (pragmas now parsed and inherited down instance trees), named profiles replayed as one recording per mode group. infosys_* reference lookup (7 tools): sitemap-driven book list, per-library local index with FTS5, symbol search, declarations as data, code-example search, live page → Markdown, sitemap-verified web fallback, TwinCAT 2 filtered out; scripts/gen_tools_md.py. Packaging: Claude Code plugin + marketplace in .claude-plugin/ (/plugin install twincat-mcp@twincat-mcp, userConfig for Python/AmsNetId/modes), Claude Desktop .mcpb bundle (packaging/mcpb/build.py, manifest 0.3, tool list generated from the server, passes mcpb validate), self-bootstrapping launcher scripts/launch.py (+ launch.cmd) that creates the venv on first start and reinstalls only when the shipped sources change; skill moved to skills/twincat-mcp/; HTTP mode bearer-token gate for claude.ai remote connectors. Plugin path verified end-to-end on Linux (install → venv → tc_doctor via mcp__plugin_twincat-mcp_twincat__tc_doctor); launch.cmd Python discovery is untested on Windows. Windows CI (.github/workflows/ci.yml, ubuntu + windows × py3.10/3.12 with a stand-in TcAdsDll.dll) found and fixed: tc_doctor crashed instead of reporting a dead router; the dialog scan looked at every program's dialogs when no XAE pid was known; a PC without TwinCAT got a ctypes traceback at start instead of the cause. proj_lint gains six OOP/safety rules (interface_contract, extends_cycle, abstract_instantiation, shadowed_member, unsigned_loop, new_delete), default-on, zero findings on the sample project. System Service file paths accept OS-independent prefixes (boot:, bootprj:, config:, user1:… = ADS path ids); tcunit_remote_result defaults to boot:TcUnit_xUnit_testresults.xml so the same config serves Windows, CE7 and TC/BSD targets. Refused and declined actions are now audited (outcome: refused / declined-elicitation:*), not only the ones that ran. docs/INSTALL.md: install → config → 14-step zero-write smoke test.

0.5.0 — dialog watchdog, TwinSAFE guard, XML validation/fixes + LineIds regeneration, TE2000/TcVIS HMI binding index with runtime/source cross-check, I/O disable, variable links, UDP discovery, Windows event log, C#/TypeScript/JSON exporters, snapshot apply, session report, naming_prefixes config.

0.4.0 — composite workflows (wf_debug_symbol, wf_fb_profile, wf_release_check, wf_project_overview), MCP prompts as workflow recipes, rec_compare, proj_changed (git), proj_scan incremental, ads_io_read (process image), compact symbol listing, size-guarded ads_read, separate ADS workers for quick vs long calls, Claude Code integration kit (integrations/claude-code/).

0.3.0 — datatype-table upload and parsing: full nested decode of any variable in one read (ads_read), ads_leaves, ads_dump (every variable on the PLC → JSON + CSV), ads_types; recorder prefixes expand through the table (arrays of structs included); proj_variables (source-declared variables flattened to instance paths) and proj_vs_runtime (source vs online cross-check).

0.2.0 — real-time recorder (rec_*), test bench (test_*, snap_*), runtime diagnostics (ads_app_info, ads_task_stats, ads_ping), ADS RPC (ads_call_method), static checks (proj_interface, proj_lint, proj_call_graph), tcunit_scaffold. Review fixes: ROT enumeration (EnumRunning), vsBuildState constant, raw writes limited to PLC ports with symbol-overlap deny checks, tokens bound to the connected machine, ads_connect re-targeting gated, destructive DTE commands classified, project write-back byte-exact (BOM/EOL preserved) and duplicate-name aware, cooperative cancellation of long ADS loops, blocking calls moved off the event loop.

0.1.0 — initial release.

Not covered (deliberately)

Scope/TE13xx recording, TE1200 static analysis, NC axis commissioning, Safety (TISC) editing, library repository management, semantic code search, OPC UA. The tree XML tools (xae_tree_get / xae_tree_consume_xml) reach most of the rest of the System Manager generically.

Development

python -m pytest            # 159 tests (safety matrix, type codec, project parser, fake ADS incl. notifications/RPC, fake COM, recorder, bench, lint, MCP e2e incl. elicitation, packaging)
python packaging/mcpb/build.py      # dist/twincat-mcp-<version>.mcpb; npx @anthropic-ai/mcpb validate runs if Node is present
claude plugin validate .            # plugin + marketplace manifests
python -m twincat_mcp --print-config
python -m twincat_mcp --http 8765   # streamable-http on loopback; --token / TCMCP_HTTP_TOKEN adds a bearer gate for tunnels

MIT.

Available Tools

171 tools
ads_add_route_to_plcC
Destructive

Create the PLC-side route back to this PC (UDP discovery protocol, needs the target's Windows/TC-BSD credentials). Control-class.

NameRequiredDescriptionDefault
plc_ipYes
hostnameNo
route_nameNo
local_net_idNo
plc_passwordNo1
plc_usernameNoAdministrator
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=true, so the safety profile is covered. The description adds useful context by naming the UDP discovery protocol and stating that credentials are required. It does not explain reversibility, side effects, or what the confirm_token parameter is for, leaving meaningful behavioral gaps.

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 very concise and front-loads the action and target. The trailing fragment 'Control-class.' is terse but cryptic, slightly weakening an otherwise efficient structure.

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

Completeness2/5

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

The tool is a destructive mutation with 7 parameters and zero schema descriptions, yet the description omits parameter-level meaning, confirmation flow, and side effects. It does mention protocol and credential requirements, but this is not enough for the agent to invoke the tool confidently.

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

Parameters2/5

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

Schema description coverage is 0% for 7 parameters, so the description must compensate but largely does not. 'Needs the target's Windows/TC-BSD credentials' loosely hints at plc_username and plc_password, but plc_ip, hostname, route_name, local_net_id, and confirm_token are not explained at all.

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

Purpose4/5

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

The description states a specific verb ('Create') and resource ('PLC-side route back to this PC'), which distinguishes it from sibling route-listing tools such as ads_routes. However, it does not explicitly name any alternative tool or clarify when this creation tool should be preferred over discovery or listing tools.

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

Usage Guidelines2/5

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

It mentions a prerequisite ('needs the target's Windows/TC-BSD credentials') and the protocol involved, which gives some usage context. But it gives no explicit when-to-use guidance, no when-not-to-use conditions, and no alternatives among the many sibling tools.

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

ads_app_infoB
Read-only

PLC application info (TwinCAT_SystemInfoVarList._AppInfo): project/app name, online change count, boot data loaded, task count, logged-in flag, app timestamp.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the field inventory, which is useful, but says nothing about connection/auth requirements or whether it is safe to poll repeatedly. Adequate with annotations, but not rich.

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?

A single dense sentence with the resource definition front-loaded and the field list appended parenthetically. It earns its place, though the internal TwinCAT type name is borderline clutter for an agent.

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 parameters and an output schema present, the description needn't explain return formatting, and it does supply the semantic meaning of the payload fields. The only real gap is the lack of connection/precondition context for a PLC-targeted read.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. The empty schema leaves nothing to disambiguate, and the description correctly adds no parameter guidance that would be redundant.

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

Purpose4/5

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

Names the specific resource (PLC application info, anchored to TwinCAT_SystemInfoVarList._AppInfo) and enumerates the fields it covers, so an agent knows exactly what it returns. It does not differentiate itself from adjacent siblings such as ads_status or ads_task_stats, which overlap on task count and state, so it falls short of a 5.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no stated prerequisites (e.g. an active ADS connection via ads_connect), and no named alternative among the many ads_* siblings. The agent must infer invocation context entirely.

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

ads_call_methodA
Destructive

Invoke an FB method on the running PLC via ADS RPC. The method must carry {attribute 'TcRpcEnable'}. inputs: [{type:'LREAL', value: 12.5}, …] in VAR_INPUT order (use base types: INT not E_Enum); outputs: ['BOOL', …] in VAR_OUTPUT order. Write-class.

NameRequiredDescriptionDefault
inputsNo
methodYes
outputsNo
instanceYes
return_typeNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already flag readOnlyHint=false and destructiveHint=true; the description is consistent ('Write-class') and adds substance the annotations cannot: the TcRpcEnable prerequisite and the ordering/type constraints for arguments. It still does not describe failure modes on the PLC side or whether a partial write can occur.

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?

Terse and front-loaded: the purpose comes first, then the prerequisite, then the argument contract. The telegraphic fragments ('Write-class.', parenthetical type note) are dense but each carries information; no filler sentences.

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?

An output schema exists, so return values need not be explained, and the description covers the essential calling contract plus the RPC-enable prerequisite. Missing pieces are secondary: how to address the FB instance, error behavior, and side effects of a destructive write-class call.

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

Parameters3/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 burden. It does well on two of the five parameters (exact shapes for inputs as {type,value} and outputs as type-name strings, with VAR_INPUT/VAR_OUTPUT ordering and a base-type warning), but says nothing about instance, method, or return_type, which are the required/optional identifiers.

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

Purpose4/5

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

States a specific verb and resource: invoking an FB method on a running PLC over ADS RPC, which is distinct from the symbol-level ads_read/ads_write siblings. It does not explicitly name a sibling it competes with, so an agent must infer that this is the only method-invocation tool.

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 a real precondition (the method must carry {attribute 'TcRpcEnable'}) and labels the operation 'Write-class', which steers the agent toward mutating-use context. It stops short of stating when to prefer this over ads_write/ads_write_many or what to do if the attribute is absent.

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

ads_connectA
Destructive

(Re)connect to a target. ams_net_id like '5.12.34.56.1.1', 'local' for this PC, None = keep current; port 851 = PLC runtime 1. Re-targeting to a NetId other than the configured one is control-class (it changes which machine every later write hits).

NameRequiredDescriptionDefault
ams_portNo
ams_net_idNo
ip_addressNo
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, but the description adds genuinely new context beyond them: re-targeting is 'control-class' because it changes which machine every later write hits. That side-effect disclosure is real value. It omits that re-targeting likely requires the confirm_token the schema exposes.

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?

Three compact sentences, front-loaded with the action and followed by the highest-value caveat. No filler; a slight tightening of the parenthetical would be the only improvement.

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

Completeness3/5

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

An output schema exists so return values need no explanation, but for a destructive, non-idempotent control operation the description should say whether a confirmation/confirm_token is required and what happens on failure. That gap is meaningful for a 4-parameter mutation tool.

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

Parameters3/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 the parameter burden. It ably explains ams_net_id formats ('5.12.34.56.1.1', 'local', None) and the 851 port meaning, but leaves ip_address and confirm_token completely unexplained.

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

Purpose4/5

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

(Re)connect to a target' states the verb and resource clearly and could not be confused with read-oriented siblings like ads_read or ads_status. It does not, however, differentiate itself from ads_discover or ads_add_route_to_plc, which also concern target/routing topology.

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

Usage Guidelines3/5

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

It implies when to call it (reconnect, optionally re-target) and gives useful defaults ('None = keep current'), but never states when NOT to use it or names an alternative tool for changing targets. Usage is inferable rather than explicit.

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

ads_discoverA
Read-only

Broadcast search for TwinCAT targets on the local network (UDP 48899): NetId, host name, TwinCAT version, IP — the same thing XAE's 'Broadcast Search' does.

NameRequiredDescriptionDefault
broadcastNo255.255.255.255
timeout_sNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the operation is a UDP broadcast on port 48899 scoped to the local network, meaning it cannot reach remote subnets and may block for the timeout window. It does not mention behavior on zero results or timeout exhaustion, which keeps it short of a 5.

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

Conciseness5/5

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

A single sentence, front-loaded with the action and the transport, followed by the returned fields and an intuitive analog. No filler or redundancy.

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?

Low-complexity tool with only two optional parameters and an output schema, so return-value explanation is unnecessary. The remaining gap is the lack of any workflow framing (that discovery precedes connect/route-added operations) and timeout semantics, but for a discovery tool this is close to complete.

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

Parameters2/5

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

Schema description coverage is 0%, and the description compensates only partially: 'local network' loosely gestures at the broadcast address parameter, but neither the broadcast target handling (default 255.255.255.255) nor the timeout_s semantics or units are explained. For two undocumented parameters the description should carry this load, and it does not.

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 description names a specific verb and resource (broadcast search for TwinCAT targets), states the transport (UDP 48899), and enumerates the payload fields returned (NetId, host name, TwinCAT version, IP). This clearly separates it from connection-oriented siblings like ads_connect/ads_ping and from the XAE-side xae_target tool, without the agent needing to open either schema.

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

Usage Guidelines3/5

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

The XAE 'Broadcast Search' analogy implies this is the discovery step performed before connecting (e.g. ahead of ads_connect or ads_add_route_to_plc), but usage is only implied. There is no explicit statement of when to prefer this over e.g. ads_status or a direct-IP connection, nor any prerequisite/exclusion.

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

ads_dumpA
Read-only

Read EVERY variable on the PLC (all top-level symbols, fully expanded through the datatype table — structs, FB instances, arrays of structs) in one pass and write a flat CSV (path,type,value,note) and a nested JSON tree built from the same values, so the two files never disagree. pattern limits the roots ('MAIN.', 'GVL_'); system symbols excluded unless include_system. With a project configured its own programs and GVLs come first; without one the order is alphabetical (origin unknown). POINTER TO / REFERENCE TO / INTERFACE values are addresses (NULL = 0x0000…0000) — the target is never expanded. An array beyond 4096 elements or a value beyond 64 KiB is not expanded: both files show the same {not_expanded, bytes, elements, head_hex}. Big symbols are read in 256 KiB pieces. max_leaves bounds CSV and JSON together; max_total_mb (MiB) bounds the CSV + JSON on disk (written_mib; the bytes read from the PLC are not counted): a row is written only when it, the root's JSON with it and the ending still to be written (the footer naming what is left out) fit — nothing is estimated. complete=false names every root that is missing or cut (skipped_roots) and every root that could not be read (failed_roots, also in the CSV note column and the JSON footer). not_on_target names the programs/GVLs of the source that have no symbol on the target, with the cause (not linked, or another program on the target). Returns counts, largest_roots, file paths and a 50-leaf preview.

NameRequiredDescriptionDefault
out_dirNo
patternNo
max_leavesNo
max_total_mbNo
include_systemNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior5/5

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

The description discloses behavioral traits far beyond the readOnly/destructive annotations: POINTER/REFERENCE/INTERFACE values are addresses and never expanded, arrays >4096 elements or values >64 KiB are shown as {not_expanded, bytes, elements, head_hex}, large symbols are read in 256 KiB pieces, and the bounding semantics of max_leaves/max_total_mb are defined precisely (nothing estimated, row written only when it still fits). It also explains the complete=false contract with skipped_roots and failed_roots and the not_on_target reporting, so an agent knows exactly what partial or missing results look like.

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 and dense, but it is front-loaded with the core purpose and every subsequent sentence adds a concrete, non-redundant behavioral fact (expansion limits, chunk size, bounding rules, partial-result contract). Given the tool's genuine complexity, the length is mostly justified, though a few clauses (e.g. the byte-accounting aside) could be tightened.

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 complex whole-PLC dump with five parameters, zero schema coverage and an output schema already present, the description supplies everything an agent needs: what is read, how it is bounded, what is excluded and what a truncated or failed run looks like. Return values are additionally previewed despite the output schema, which is more than required.

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

Parameters4/5

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

Schema coverage is 0%, so the description carries the full burden, and it does so for four of five parameters: pattern syntax and root-limiting behavior is shown with examples, include_system default effect is stated, and both max_leaves (CSV+JSON leaves together) and max_total_mb (MiB, on-disk CSV+JSON only, PLC bytes excluded) are defined in a way the schema cannot convey. out_dir is the one gap — never explained even implicitly as the destination for the two files.

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 with explicit scope: reads EVERY variable on the PLC (all top-level symbols, fully expanded) in one pass and emits both a flat CSV and a nested JSON tree. This is clearly distinguishable from siblings like ads_read, ads_read_many, ads_list_symbols and ads_export, all of which imply narrower or differently-shaped output.

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

Usage Guidelines3/5

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

Usage context is implied through scope statements (one-pass whole-PLC dump, pattern to limit roots, ordering behavior with/without a project) but it never explicitly says when to pick this over ads_export, ads_read_many or ads_list_symbols, nor does it name an exclusion condition for those alternatives. An agent can infer the 'dump everything' case but must decide unassisted whether a narrower sibling is more appropriate.

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

ads_ethercatA
Read-only

EtherCAT master state (INIT/PREOP/SAFEOP/OP) and slave count via the master's ADS port (default 65535 for the first master; see Device → ADS tab in XAE).

NameRequiredDescriptionDefault
master_portNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful return-content context (master state and slave count) and the default port, but it omits behavioral details such as connection prerequisites, error conditions, or what happens when no master is found.

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

Conciseness5/5

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

The description is a single, front-loaded sentence: purpose first, then parenthetical port details. Every fragment earns its place with no filler.

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?

For a read-only tool with an output schema, the description provides the necessary purpose, return fields, and parameter default. It is nearly complete, though it could mention that the ADS connection must already exist and clarify its relationship to general ADS status tools.

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

Parameters4/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 the parameter meaning. It does this well by stating the default port (65535 for the first master) and pointing to the Device → ADS tab in XAE, which is meaningful guidance beyond the bare 'Master Port' schema title.

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

Purpose4/5

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

The description names the specific resource (EtherCAT master) and the exact information returned (state values INIT/PREOP/SAFEOP/OP and slave count). It is clear enough to distinguish from generic ADS tools, but it does not explicitly contrast with siblings like ads_status or ads_plc_state.

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

Usage Guidelines2/5

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

No when-to-use guidance is provided. The description explains the default ADS port and where to find it in XAE, but it does not say when an agent should call this tool versus ads_status, ads_discover, or other diagnostic siblings.

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

ads_exportB
Read-only

Generate code from the runtime: fmt=csharp (explicit-offset structs + enums for Beckhoff.TwinCAT.Ads ReadAny/WriteAny), typescript (interfaces), json (type descriptions), or csharp_symbols (const symbol paths under prefix). types = struct/enum names; prefix = take the types of every symbol under it.

NameRequiredDescriptionDefault
fmtNocsharp
typesNo
prefixNo
out_pathNo
namespaceNoTransflo.Plc
overwriteNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

readOnlyHint=true and destructiveHint=false already declare the safety profile, so the description earns credit for detailing what each format emits. However, it is silent on out_path and overwrite, so an agent cannot tell whether the tool writes a file to disk or only returns text, which is material for a tool carrying an overwrite flag.

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?

Two dense sentences, front-loaded with the core verb and the format semantics; the semicolon-clause for types/prefix is compact and each element earns its place. Slightly terse on the parameters it omits, but no filler.

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

Completeness3/5

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

An output schema exists, so return-value explanation is not required. Still, for a tool with out_path and overwrite parameters, the description never clarifies default output or on-disk side effects, leaving a meaningful behavioral gap for a 6-parameter tool.

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

Parameters3/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 the burden. It explains fmt (with all four values), types, and prefix reasonably well, but leaves out_path, namespace, and overwrite completely undefined in both description and schema, leaving half the parameters opaque.

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

Purpose4/5

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

States a specific verb (generate code) and resource (runtime type system), and enumerates the output formats with their contents, which is more informative than the bare name. It stops short of positioning itself against nearby siblings like ads_types or ads_dump, so an agent must infer the distinction.

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

Usage Guidelines3/5

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

The format breakdown implies when each mode is useful, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as ads_types for raw type inspection. Usage is only inferable from the fmt enumeration.

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

ads_io_readA
Read-only

Raw process image of the PLC: area 'I' (%IB inputs) or 'Q' (%QB outputs) at a byte offset — what the task actually sees/wrote, independent of symbol names (link checks).

NameRequiredDescriptionDefault
areaYes
portNo
sizeNo
offsetYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context: this reads the raw process image as the task actually sees/wrote it, bypassing symbols. It does not mention port/size behavior or error conditions.

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?

A single dense sentence with the resource front-loaded and area/offset semantics attached efficiently via punctuation. No filler, though the em-dash clause packs several ideas together at the cost of some scannability.

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

Completeness3/5

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

An output schema exists, so return values need not be described. However, for a 4-parameter tool with 0% schema coverage, the description leaves port and size unexplained and offers no guidance on selecting this tool over the many sibling read variants.

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

Parameters3/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 the load. It usefully explains 'area' (I=%IB inputs, Q=%QB outputs) and 'offset' (byte offset), functioning as an implicit enum. It adds nothing for 'port' (default 851) or 'size', leaving half the parameters undocumented.

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

Purpose4/5

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

The description names the specific resource (raw process image of the PLC), the areas I/Q with their %IB/%QB mapping, and the byte-offset addressing. It distinguishes itself from symbol-based reads via 'independent of symbol names,' though it does not differentiate from the close sibling ads_read_raw.

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

Usage Guidelines3/5

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

The parenthetical '(link checks)' hints at the intended use case but there is no explicit when-to-use/when-not guidance or named alternative versus ads_read, ads_read_raw, or ads_read_many. Usage is implied rather than stated.

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

ads_leavesB
Read-only

Enumerate every scalar leaf under a symbol with byte offsets (datatype table): 'MAIN' → all program variables, 'MAIN.arrSteps' → arrSteps[1].nId … With values=true each leaf is decoded from the symbol's bytes, read in bounded pieces (a value that is not expanded: its head only); value_note says why a value is missing or partial.

NameRequiredDescriptionDefault
nameYes
max_leavesNo
with_valuesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already declare a safe read operation, but the description adds real behavioral context: values are read in bounded pieces, non-expanded values return only their head, and value_note explains missing/partial values. This is useful detail beyond what readOnlyHint conveys.

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

Conciseness3/5

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

The purpose is front-loaded, but the sentence is dense with nested parentheses and embedded examples that make it harder to parse than necessary. Acceptable size, but structure could be cleaner.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and the description does cover the with_values/value_note behavior. But with 0% parameter coverage it leaves name and max_leaves undocumented, so it is not fully complete for a 3-parameter tool.

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

Parameters2/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, yet it only addresses with_values behavior and references the output field value_note. The name parameter's addressing semantics and max_leaves (the bound that triggers 'not expanded' behavior) are left unexplained.

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

Purpose4/5

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

The description gives a specific verb ("Enumerate") and resource ("every scalar leaf under a symbol with byte offsets") and illustrates it with concrete examples ('MAIN', 'MAIN.arrSteps'). The leaf-enumeration concept differentiates it from sibling reads like ads_read or ads_list_symbols, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

It implies when to use the tool (enumerate leaves; set values=true to get decoded values), which maps to a plausible workflow. However it never states when to prefer this over ads_read, ads_read_many, or ads_symbol_info, nor any prerequisites or exclusions.

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

ads_list_symbolsB
Read-only

Browse the runtime symbol table. pattern is fnmatch ('MAIN.', 'valve'; bare text is wrapped in ''). type_filter substring-matches the type ('ST_', 'BOOL', 'FB_'). flag filters by symbol flag: PERSISTENT, READONLY, STATIC, ATTRIBUTES … compact=true returns 'name : type' strings only (one fifth of the tokens).

NameRequiredDescriptionDefault
flagNo
limitNo
offsetNo
compactNo
patternNo*
refreshNo
type_filterNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that compact mode returns a token-reduced format (one fifth of the tokens), which is useful behavioral context beyond annotations. However, refresh parameter behavior and pagination are not described.

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?

Dense but well-structured, front-loading the purpose then covering parameters with concrete examples. Every sentence adds value. Slightly terse but not wasteful.

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

Completeness3/5

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

With 7 parameters, 0% schema coverage, and no output schema, the description covers the key parameters well but omits limit, offset, and refresh semantics. An agent might not know default pagination behavior or what refresh does. Adequate but incomplete for a 7-param tool.

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

Parameters4/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 compensate. It explains pattern (fnmatch with examples and bare-text wrapping), type_filter (substring match with examples), flag (accepted values), and compact (format and token savings). This meaningfully clarifies the most important parameters, though limit, offset, and refresh are left undocumented.

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

Purpose4/5

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

States a specific verb+resource: 'Browse the runtime symbol table.' Clear what it does. It doesn't explicitly differentiate from siblings like ads_symbol_info or ads_discover, but the tool name and description are distinct enough.

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

Usage Guidelines2/5

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

No when-to-use guidance or mention of alternatives. An agent must infer that this is for enumerating symbols vs ads_symbol_info which likely gets details for one symbol. No exclusions or routing.

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

ads_pingC
Read-only

ADS round-trip time statistics to the target (router/route/network health).

NameRequiredDescriptionDefault
portNo
countNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this measures round-trip time and relates to router/route/network health, but says nothing about blocking behavior, timeouts, how count affects duration, or rate limits.

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?

A single compact sentence with no padding, front-loaded on the tool's subject. Slightly awkward phrasing ('statistics to the target') costs it the top score.

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

Completeness3/5

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

An output schema exists, so return values needn't be explained, and annotations cover safety. Still missing are parameter meaning (port/count) and any usage guidance, which are needed for correct invocation even on a simple two-parameter tool.

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

Parameters2/5

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

Schema description coverage is 0% and the description never explains the two parameters. It implies repeated measurement (count) and a target port, but neither is stated or given format/semantics, so it fails to compensate for the empty schema descriptions.

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

Purpose3/5

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

The description names the resource (ADS target) and the measurement (round-trip time statistics), plus the diagnostic domain (router/route/network health). However, it uses no explicit verb and reads more like a description of the output than of an action, so it is only vaguely distinguishable from siblings like ads_status or ads_routes.

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

Usage Guidelines2/5

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

The parenthetical hints at a diagnostic use case, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many ads_* siblings. The agent is left to infer that this is a connectivity/latency probe.

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

ads_plc_stateA
Destructive

PLC runtime control via ADS: run | stop | reset. 'reset' is a cold reset (all non-persistent data lost). Control-class: confirmation in guarded mode.

NameRequiredDescriptionDefault
actionYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, but the description adds real beyond-annotation context: 'reset' is a cold reset that loses all non-persistent data, and 'Control-class: confirmation in guarded mode' signals the confirm_token requirement. This is meaningful disclosure of what gets destroyed and what authorization is needed.

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?

Three compact sentences, front-loaded with the tool's function and immediately followed by the critical destructive-action caveat. The pipe-list action notation is efficient; there is essentially no filler.

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

Completeness3/5

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

An output schema exists so return values need not be described, and the destructive semantics are covered. The gap is the confirm_token workflow: the agent is told confirmation exists in guarded mode but not how to obtain or use the token (e.g., via the sibling tc_request_confirmation), leaving invocation incomplete for write operations.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry parameter meaning; it does partially compensate by enumerating the accepted action values (run | stop | reset), which the schema omits. However confirm_token is only obliquely referenced via "confirmation in guarded mode" and its format/obtaining procedure is unexplained.

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

Purpose4/5

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

States a specific verb+resource ("PLC runtime control via ADS") and enumerates the concrete actions run | stop | reset, so the agent knows exactly the domain of effect. It does not explicitly differentiate itself from adjacent siblings like ads_system_mode or xae_restart_twincat, leaving some disambiguation to be inferred from the name.

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

Usage Guidelines3/5

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

The description implies its use case (runtime state control) and adds the important prerequisite that confirmation is required in guarded mode, but it never states when to prefer this over ads_system_mode or tc_set_mode, nor any exclusions. Usage is implied rather than explicitly guided.

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

ads_readA
Read-only

Read one symbol with type-aware decoding. Structs/FB instances/arrays of structs decode into a nested tree (datatype table); TIME/DATE/DT/TOD get readable text; enums get names. Trees larger than max_chars are summarised (member names + sizes) — use ads_leaves or ads_dump for the full content.

NameRequiredDescriptionDefault
nameYes
max_charsNo
max_membersNo
expand_structNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond that by disclosing decoding behavior: structs/FBs become a nested datatype table, TIME/DATE get readable text, enums get names, and oversized trees are truncated to member names plus sizes.

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?

Three dense sentences with the core behavior front-loaded, followed by decode specifics and the truncation escape hatch. No filler, though the output-format detail is arguably more than needed given an output schema exists.

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

Completeness3/5

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

Return-value rendering is well explained (and an output schema exists anyway), and safety is covered by annotations. However, with three of four parameters undocumented at 0% schema coverage, the definition is not complete enough for an agent to tune the call confidently.

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

Parameters2/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, yet only max_chars is given meaning (the truncation threshold). max_members, expand_struct, and the name format are entirely undocumented in both schema and description.

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

Purpose4/5

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

States a specific verb and resource ('Read one symbol') with a distinguishing qualifier ('type-aware decoding'). The 'one symbol' phrasing implicitly separates it from ads_read_many, and 'type-aware' implies a difference from ads_read_raw, though neither sibling is named directly.

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 an explicit routing rule: when the decoded tree exceeds max_chars it is summarised, so use ads_leaves or ads_dump instead. This is clear conditional guidance, but it does not cover when to prefer ads_read over ads_read_raw or ads_read_many.

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

ads_read_manyB
Read-only

Read several symbols in one ADS sum-command. Returns {name: value | {error}}.

NameRequiredDescriptionDefault
namesYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real context beyond that — a single batched round trip and per-name error results rather than an all-or-nothing failure — but says nothing about connection requirements or limits on batch size.

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?

Two sentences, front-loaded with the action and mechanism, no filler. The return-shape notation '{name: value | {error}}' is terse to the point of being slightly cryptic, and it partly restates what the output schema already defines.

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

Completeness3/5

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

An output schema exists, so return values need not be re-explained (the description does so anyway). What is missing for correct invocation is the symbol-name format and the connection precondition implied by sibling ads_connect; for a one-parameter batch read that leaves a visible gap.

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

Parameters3/5

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

One parameter ('names') with 0% schema description coverage, so the description must compensate. It conveys that the array holds symbols and roughly what comes back, but never clarifies the expected symbol path format (e.g. 'MAIN.bVar'), which is the main thing an agent would get wrong.

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

Purpose4/5

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

States a specific verb and resource (read several symbols) plus the mechanism (one ADS sum-command), which distinguishes it from the singular ads_read without needing the schema. It does not, however, name the sibling it replaces the way a 5-level description would.

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

Usage Guidelines3/5

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

The batching intent is implied by 'several symbols in one' command, so an agent can infer this is the multi-read variant of ads_read. But there is no explicit when-to-use statement, no mention of ads_read_raw or ads_io_read as alternatives, and no prerequisites (e.g. an active ads_connect) despite ads_connect being a sibling.

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

ads_read_rawC
Read-only

Raw ADS read by index group/offset on any port (hex + little-endian uint).

NameRequiredDescriptionDefault
portNo
sizeYes
ams_net_idNo
index_groupYes
index_offsetYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that reads are raw, address-based, usable on any port, and mentions hex/little-endian uint output, but it does not clarify that parenthetical or disclose connection requirements or error behavior.

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?

A single front-loaded sentence with no padding. The parenthetical is terse but cryptic, slightly reducing clarity rather than adding useful structure.

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

Completeness2/5

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

Although output schema exists and annotations cover safety, the description is too thin for a five-parameter raw-read tool. It omits meaning for size and ams_net_id and gives no sibling comparison or usage context.

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

Parameters2/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 explain parameters. It names index_group, index_offset, and port, but says nothing about required size or optional ams_net_id, leaving two of five parameters undocumented.

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

Purpose4/5

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

States a specific verb and resource: 'Raw ADS read' by index group/offset on any port. This implicitly distinguishes it from higher-level reads like ads_read, but it never names or explicitly contrasts with any sibling tool, so it falls short of a 5.

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

Usage Guidelines2/5

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

Provides no when-to-use guidance, no alternatives, and no exclusions. An agent learns what the tool does, but not when to choose it over ads_read, ads_read_many, or ads_io_read.

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

ads_routesB
Read-only

Local static ADS routes (parsed from StaticRoutes.xml on this PC).

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description contributes the useful detail that results are parsed from a local config file rather than queried live from the PLC, which explains why results are static. It says nothing about staleness, refresh behavior, or result volume, so it adds moderate value only.

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?

A single short sentence with zero filler, and the most important qualifier ('local static') is front-loaded. It is arguably too terse — no verb and no leading description of intent — which keeps it just below top marks.

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

Completeness3/5

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

Given zero parameters, an existing output schema, and annotations covering the safety profile, the description is close to sufficient. It still leaves open how this relates to ads_add_route_to_plc and ads_discover (static file view vs. live routing table) and whether the file is re-parsed on each call.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies the tool needs no arguments by scoping itself to 'this PC'.

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

Purpose4/5

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

The description names a specific resource (local static ADS routes) and discloses its provenance (StaticRoutes.xml on this PC), which distinguishes it from the write-oriented sibling ads_add_route_to_plc. It lacks an explicit verb (list/get/read), but the noun phrase is unambiguous enough that an agent knows what it retrieves.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all: no statement of when to call this versus ads_add_route_to_plc, ads_discover, or ads_status, and no preconditions (e.g., whether the ADS connection must be live or whether 'static' excludes dynamically discovered routes).

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

ads_statusA
Read-only

Composite status: connection, PLC runtime state, TwinCAT system mode (RUN/CONFIG), device name/version. With port=N returns only the ADS state of that port (852 PLC2, 500 NC, 10000 system service, 65535 EtherCAT master 1).

NameRequiredDescriptionDefault
portNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: what the composite contains and how the single-port mode differs, including a mapping of well-known port numbers to their services.

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

Conciseness5/5

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

Two sentences, front-loaded with the composite behavior, then the port override with concrete examples. No filler, and each clause adds usable 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 an output schema present, return-value documentation is unnecessary, and annotations cover the read-only nature. The description covers the composite/single-port duality and port semantics adequately, though it omits guidance on when to prefer this over the dedicated sibling status tools.

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

Parameters4/5

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

Schema coverage is 0% on the single port parameter, so the description must compensate, and it largely does: default null yields the composite, a supplied port yields only that port's ADS state, and example values (852 PLC2, 500 NC, 10000 system service, 65535 EtherCAT master 1) clarify intended input.

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

Purpose4/5

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

States a specific verb+resource (composite ADS status) and enumerates the fields returned (connection, PLC runtime state, TwinCAT system mode, device name/version). It does not, however, differentiate itself from siblings like ads_plc_state or ads_system_mode despite naming overlapping data.

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

Usage Guidelines3/5

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

Usage is implied: call with no port for the composite, call with port=N for a single-port ADS state. There is no explicit when-not guidance and no named alternative among the many status siblings (ads_plc_state, ads_system_mode, ads_ping), leaving routing to inference.

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

ads_symbol_infoB
Read-only

Type, size, index group/offset, flags (READONLY, PERSISTENT …) and comment of one symbol.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

readOnlyHint=true and destructiveHint=false already establish this as a safe read, so the description's burden is lower. It adds the field-level content (flags like READONLY, PERSISTENT), which is useful context, but says nothing about needing an active ADS connection or behavior on unknown symbols.

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?

One tight sentence with the resource and returned fields front-loaded; nothing is wasted. It reads as a fragment rather than a sentence, but that costs little.

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

Completeness3/5

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

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. What is missing is the connection prerequisite and the required format of the symbol identifier, both of which an agent needs to call this correctly.

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

Parameters3/5

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

Schema coverage is 0% and the single 'name' parameter is undocumented. 'of one symbol' implies the argument identifies a single symbol rather than a pattern, which adds marginal meaning, but no symbol-path syntax (e.g. qualified path) is given.

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

Purpose4/5

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

The description names a specific resource (one symbol) and enumerates the exact metadata returned (type, size, index group/offset, flags, comment), which separates it from ads_list_symbols (listing) and ads_read (values). It lacks an explicit verb, but the noun-phrase form is unambiguous.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of the many alternatives in this large sibling set (ads_list_symbols, ads_leaves, ads_types, ads_read). The agent must infer that this is for a single symbol's metadata.

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

ads_system_modeA
Destructive

Switch TwinCAT on the target between 'run' and 'config' mode (restarts the runtime, I/O goes down). Destructive-class. Waits (≤20 s) until the target reports the requested mode and returns before/after; reached=false when it did not get there (license / configuration error).

NameRequiredDescriptionDefault
actionYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the runtime restart, that I/O goes down, the ≤20 s wait behavior, the before/after return, and the reached=false failure condition tied to license/configuration errors. These are concrete operational traits an agent needs and none are in the structured fields.

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

Conciseness5/5

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

Two dense sentences, front-loaded with the core action and immediately followed by the destructive consequences. Every clause earns its place with no filler.

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?

For a destructive mode-switch tool, the description covers the essential behavior (restart, I/O loss, wait, failure signal), and the output schema handles return values. The main gap is the unexplained confirm_token parameter, which is a meaningful omission for a destructive-class operation.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry parameter meaning. It clarifies the valid 'action' values ('run'/'config'), but the confirm_token parameter is never mentioned, leaving half the parameters undocumented in both schema and description.

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

Purpose4/5

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

States a specific verb (Switch) and resource (TwinCAT run/config mode) with the exact values involved, so an agent immediately knows what it does. It does not distinguish itself from the nearby sibling tc_set_mode, which appears to overlap, so it falls short of full sibling differentiation.

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

Usage Guidelines3/5

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

Usage is implied by the operational context (restarts the runtime, I/O goes down) but there is no explicit statement of when to choose this over alternatives such as tc_set_mode or xae_restart_twincat. The destructive framing hints at caution but gives no when-not-to-use exclusion.

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

ads_task_statsB
Read-only

PLC task timing (TwinCAT_SystemInfoVarList._TaskInfo[n]): cycle time, last/min/max/mean execution time over samples, load %, cycle-time-exceeded counter delta — the FB's cost on the real-time task.

NameRequiredDescriptionDefault
samplesNo
task_indexNo
interval_msNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context beyond that — the underlying SystemInfoVarList source and that timing is averaged over `samples` — but says nothing about how sampling blocks, cost of the read, or any permissions.

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?

A single dense sentence, front-loaded with the resource and source path, followed by the metric list. Every clause is informative, though the em-dash tail slightly overloads one sentence.

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

Completeness3/5

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

An output schema exists so return values need no explanation, and read-only annotations cover safety. However, with 0% schema coverage the three parameters are not fully described, which is a real gap for an agent trying to tune sampling behavior.

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

Parameters2/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 burden, yet it only mentions `samples` (execution time over `samples`) and hints at `task_index` via the [n] notation. `interval_ms` is never explained, leaving a third of the parameters undocumented in both places.

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

Purpose4/5

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

States a specific resource (PLC task timing) and enumerates exactly what it returns: cycle time, last/min/max/mean execution time, load %, and exceeded-counter delta. The parenthetical source path and the 'FB's cost on the real-time task' framing make the intent concrete, though it does not name or contrast a sibling profiling tool.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: measuring a function block's real-time cost suggests a profiling context, but there is no when-to-use, when-not, or alternative (e.g. wf_fb_profile, rec_stats) named. An agent must infer the scenario.

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

ads_typesB
Read-only

Runtime datatype table: describe one type (members with offsets/sizes, array bounds, enum literals, attributes) or list types matching a pattern.

NameRequiredDescriptionDefault
limitNo
patternNo
type_nameNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds some behavioral value by enumerating the data returned (offsets, sizes, bounds, enum literals, attributes), but says nothing about scope limits, connection requirements, or behavior when a type/pattern matches nothing.

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?

A single dense sentence, front-loaded with the resource and then the two operating modes. Nothing is padded, though the parenthetical detail list pushes it toward a run-on.

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

Completeness3/5

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

An output schema exists, so return-value explanation is not required, and the read-only annotations cover safety. Still, with three undocumented parameters (limit, pattern, type_name all at 0% schema coverage), the description should say more about parameter meaning and defaulting to be fully actionable.

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

Parameters3/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 burden. It effectively disambiguates type_name (single type) from pattern (matching list), but leaves 'limit' entirely unexplained and gives no syntax for pattern (glob vs. regex) or expected type-name format, so it only partially compensates.

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

Purpose4/5

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

The description names a specific resource ('Runtime datatype table') and two distinct operations (describe one type vs. list types matching a pattern), plus what a description contains (members with offsets/sizes, array bounds, enum literals, attributes). It is clear enough to distinguish from symbol/read siblings, though it never names an alternative such as ads_symbol_info or ads_list_symbols.

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

Usage Guidelines3/5

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

The two modes ('describe one type' vs 'list types matching a pattern') imply which parameter to use, giving implicit usage guidance. There is no explicit when-to-use/when-not-to-use statement and no routing to a sibling tool, so an agent must infer the selection.

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

ads_wait_untilA
Read-only

Block until symbol value (==, !=, >, >=, <, <=) or timeout. Uses an ADS change notification, so it returns as soon as the runtime sees the condition (met_at_plc_ms = PLC-relative timestamp of that sample); falls back to polling every interval_ms when notifications are unavailable. Returns met/value/elapsed.

NameRequiredDescriptionDefault
opYes
nameYes
valueYes
timeout_msNo
interval_msNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the readOnly/destructive annotations by disclosing the blocking nature, the notification-driven fast path, the polling fallback at interval_ms, the meaning of met_at_plc_ms, and the returned fields. This is exactly the behavioral context an agent needs for a long-running blocking call.

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 blocking behavior is front-loaded and the fallback/timestamp details are packed into one dense but readable passage with no filler. The parenthetical heavy structure is slightly harder to scan than ideal, but nothing is wasted.

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 an output schema present, the description is not obliged to detail return values, yet it still names them briefly. It covers mechanism, fallback, and timeout, and only omits prerequisites such as whether a connection (ads_connect) must exist first.

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

Parameters3/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 the load, and it does so only partially: it enumerates the legal comparison operators for 'op' and explains interval_ms as the polling cadence when notifications are unavailable. It never explains what 'name' expects (symbol path form) or what types 'value' accepts, leaving two of five parameters undefined.

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 description gives a specific verb (Block/waits until) plus the resource and the exact predicate form ('symbol <op> value'), and the blocking semantics cleanly distinguish it from non-blocking siblings like ads_read, ads_watch, and test_expect.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent can infer you call this to wait for a PLC condition and that a timeout bounds the wait. There is no explicit when-not guidance and no mention of alternatives such as ads_watch (non-blocking observation) or test_expect for assertions.

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

ads_watchA
Read-only

Trace symbols for duration_ms. Uses ADS notifications (PLC-timestamped, every change the runtime sees at its task cycle — not 50 ms polling from this PC): change_only=true records changes, false one sample per interval_ms. Falls back to polling when notifications are unavailable (method field says which). Caps: 60 s, 5000 rows. The wait happens off the ADS workers, so writes issued concurrently land during the watch — a client that sends calls one after another still sees them after it; for stimulus→response use test_response, or rec_start + the write + rec_stop.

NameRequiredDescriptionDefault
namesYes
change_onlyNo
duration_msNo
interval_msNo

Output Schema

NameRequiredDescription

No output parameters

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 read-only annotations: notification-based (PLC-timestamped, task-cycle) vs fallback polling, the 'method' field indicating which path ran, hard caps of 60 s / 5000 rows, and the off-worker wait semantics. These are exactly the behavioral traits an agent needs and none are in the annotations.

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?

Purpose is front-loaded and every clause carries information, but the single dense paragraph with dashes, parentheses and a trailing three-use-case list is harder to scan than it needs to be. Efficient, if a bit overloaded.

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?

An output schema exists so return values need not be described, and the description covers the behavioral gaps that remain (caps, notification vs polling, concurrency semantics, alternatives). Nothing an agent needs to invoke this correctly is missing.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the load, and it does: change_only's true/false semantics, interval_ms's 'one sample per interval', and duration_ms's 60 s cap are all explained. Only 'names' is left undefined, though its meaning is self-evident.

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+resource+scope: 'Trace symbols for duration_ms', which is distinct from point-read siblings like ads_read/ads_read_many and from ads_wait_until. Combined with the notification/polling explanation, an agent can tell exactly what class of operation this is.

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 concrete usage semantics (change_only=true records changes, false is one sample per interval_ms) and explicitly routes a specific case to alternatives: 'for stimulus→response use test_response, or rec_start + the write + rec_stop'. It does not, however, directly frame when to prefer this over plain ads_read/ads_wait_until for a simple timed capture.

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

ads_writeB
Destructive

Write a symbol on the running PLC. Accepts JSON scalars, lists for arrays, and literals like 'T#1s500ms', 'D#2026-10-15', '16#FF'. Returns before/after. Gated: readonly=never; guarded=write_allowlist; full=denylist only.

NameRequiredDescriptionDefault
nameYes
valueYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds meaningful context: 'Returns before/after' and the gating rule ('readonly=never; guarded=write_allowlist; full=denylist only') tell the agent how writes are permitted in each mode. It stops short of warning about irreversibility or confirming a write actually took effect.

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?

Three dense sentences, front-loaded with the core action, then the value formats, then the gating rule. No wasted words, though the accepted-literal list could be more tightly framed.

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

Completeness3/5

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

An output schema exists, so return values needn't be spelled out, yet the description still notes 'Returns before/after'. For a destructive single-write tool with 0% param coverage, it covers value formats and permission gating adequately but leaves the name parameter and cross-tool routing unaddressed.

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

Parameters3/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 the load. It does explain the value parameter's accepted forms (scalars, lists, literals like 'T#1s500ms', 'D#2026-10-15', '16#FF'), which is genuinely additive, but the required 'name' parameter (the symbol identifier) is never explained.

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

Purpose4/5

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

States a specific verb and resource ('Write a symbol on the running PLC') with the target context ('running'). It is clearly a single-symbol write, which implicitly separates it from ads_write_many and ads_write_raw, but it never names those siblings so the agent must infer the distinction.

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

Usage Guidelines2/5

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

There is no explicit when-to-use/when-not guidance and no routing to alternatives such as ads_write_many for multiple symbols or ads_read to check current values. The 'Gated' clause describes permission modes rather than selection context, so usage must be inferred.

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

ads_write_manyA
Destructive

Write several symbols ({name: value}) together. Every symbol is gated (allow/deny list) and pre-checked (type, range, enum name, array/string length, CONSTANT, pointer/interface) BEFORE anything is written — one refusal → nothing is written and every problem is listed. Then ONE ADS sum-write: the runtime applies all values between the same two task cycles (method says if it had to fall back to one-by-one). Per-item before/written/read_back; applied/failed/not_attempted if the PLC rejects one.

NameRequiredDescriptionDefault
valuesYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior5/5

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

The description discloses behavior well beyond the annotations: pre-write gating (allow/deny list plus type/range/enum/length/CONSTANT/pointer checks), atomic all-or-nothing refusal with every problem listed, a single sum-write falling back to one-by-one, and per-item applied/failed/not_attempted reporting on PLC rejection. This is exactly the mutation-side context an agent needs and annotations do not provide.

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?

Three dense sentences, front-loaded with the core action, then validation semantics, then write/failure semantics. Every clause carries information, though the validation parenthetical is heavy and could be tighter.

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 an atomic batch-mutation tool with an output schema present, the description covers validation, atomicity, fallback, and partial-failure reporting, which is everything an agent needs to call and interpret it. Return-value detail is legitimately left to the output schema.

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

Parameters4/5

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

Schema coverage is 0% for the single free-form 'values' object, so the description must carry the load. It supplies the {name: value} map shape and, via the validation list, hints that values may be scalars, enums, arrays/strings, or pointers, which is meaningful added semantics. It stops short of per-type syntax or size limits.

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

Purpose4/5

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

States a specific verb (write) and scope (several symbols together as a {name: value} map), which implicitly contrasts with the single-symbol ads_write/ads_read siblings. It does not name an alternative tool explicitly, so the differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

Usage is implied: use this for batched writes where you want all-or-nothing semantics, versus one-by-one. There is no explicit 'use X instead when Y' routing to ads_write, ads_write_raw, or ads_write_many's read counterpart, so the agent must infer the choice from context.

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

ads_write_rawA
Destructive

Raw ADS write by index group/offset — PLC runtime ports (851-859) only. Every symbol whose memory overlaps the written range is checked against the write allow/deny lists; the raw target itself is 'raw://'.

NameRequiredDescriptionDefault
portNo
hex_dataYes
ams_net_idNo
index_groupYes
index_offsetYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already flag destructive=true and readOnly=false, but the description adds non-obvious behavior: every symbol whose memory overlaps the written range is validated against write allow/deny lists, and the raw target is named as 'raw:<port>/<igrp hex>/<ioffs hex>'. That safety-check disclosure is genuinely useful context beyond the annotations, though auth requirements and post-write state are not covered.

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?

Two compact sentences with the core action and port restriction front-loaded and no filler. The trailing 'raw:<port>/<igrp hex>/<ioffs hex>' fragment is a bit dense and could be clearer, but overall it is efficient.

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

Completeness3/5

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

An output schema exists so return values need not be explained, and the destructive/allow-deny context is present. Still, for a raw memory-write tool with 0% schema coverage, the description omits the hex_data format, the ams_net_id parameter's purpose, and what happens when an overlapping symbol is denied, leaving real gaps for correct invocation.

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

Parameters3/5

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

Schema description coverage is 0% across 5 parameters, so the description must carry the load. It does clarify what index_group/index_offset mean (encoded as igrp/ioffs hex in the target string) and bounds the port parameter to 851-859, but it says nothing about hex_data's expected format or the role of ams_net_id, leaving the two most easily misused parameters undocumented.

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

Purpose4/5

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

States a specific verb+resource: a raw ADS write addressed by index group/offset, with the scope restricted to PLC runtime ports 851-859. It implicitly separates itself from the symbol-based ads_write/ads_write_many by emphasizing 'raw' and index-group addressing, but never names a sibling, so it falls short of a 5.

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

Usage Guidelines3/5

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

'PLC runtime ports (851-859) only' is a real domain constraint that tells the agent when the tool applies. However, there is no explicit guidance on when to pick ads_write_raw over ads_write, ads_write_many, or ads_read_raw, so usage is only implied rather than directed.

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

exp_abortA
Idempotent

Stop a running experiment after the current step; recordings are closed, factor values restored.

NameRequiredDescriptionDefault
nameYes
reasonNorequested

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare the safety profile (write, idempotent, non-destructive), and the description usefully adds the side effects the agent could not otherwise know: recordings are closed and factor values are restored. It does not confirm the idempotent behavior or describe auth requirements, so it falls short of a 5.

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

Conciseness5/5

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

A single front-loaded sentence with the verb first and the two side effects appended; no filler or redundant restatement of the name.

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

Completeness3/5

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

With an output schema present, return values need no explanation, and the annotations plus the side-effect sentence cover safety and effect. However, the complete absence of parameter documentation leaves a real gap for a mutation tool that takes an argument.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters, so the description carries the full burden, yet it mentions neither 'name' nor 'reason'. The agent gets no help on what to pass, and the 'reason' default of 'requested' is never explained.

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 description states a specific verb and resource ('Stop a running experiment') plus the effect, which cleanly separates it from exp_run, exp_status, and exp_list in the sibling set. An agent can identify the action without opening the schema.

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

Usage Guidelines3/5

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

The phrase 'after the current step' gives an implied condition of use, but no alternative tool is named and there is no explicit when-to-use or when-not-to-use guidance relative to exp_run or exp_status. Usage must be inferred.

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

exp_compareB
Read-only

Two experiments with the same levels side by side: metric deltas and whether their 95 % CIs separate (the before/after question with error bars).

NameRequiredDescriptionDefault
aYes
bYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already establish this as a safe read (readOnlyHint=true, destructiveHint=false). The description adds genuine behavioral context by disclosing what is computed (metric deltas, CI separation), but says nothing about what happens when the two experiments do not share levels or how results are scoped.

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?

One sentence, front-loaded with the core operation and no filler. The parenthetical is slightly dense but still earns its place by clarifying the comparison's purpose.

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

Completeness3/5

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

An output schema exists, so return values need not be explained here. However, with 0% parameter coverage the definition leaves the two required inputs and the 'same levels' precondition undefined, which is a real gap for an agent trying to invoke it.

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

Parameters2/5

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

Schema description coverage is 0% and the two parameters are opaque single letters ('a', 'b'). The description lets the agent infer they are experiments, but adds no format, identifier convention, or ordering semantics, so the agent must guess what to pass.

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

Purpose4/5

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

States a specific operation (side-by-side comparison of two experiments) and the concrete output (metric deltas and whether 95% CIs separate). It is reasonably distinguishable from exp_evaluate/exp_report by describing the two-experiment, error-bar framing, though it never names a sibling.

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

Usage Guidelines3/5

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

Usage is implied by 'Two experiments with the same levels' and the parenthetical 'before/after question', which hints at when it applies, but there is no explicit guidance on when to prefer this over exp_evaluate, exp_runs, or the analogous rec_compare/snap_compare.

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

exp_evaluateB
Read-only

Metrics per level with 95 % CIs and the criteria verdicts (pass / fail / inconclusive with the run count that would settle it). Deterministic from runs.jsonl; rerunnable by anyone.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond that by disclosing that results are deterministic from runs.jsonl and that any user can rerun it, which tells an agent the output is stable and reproducible.

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?

Two tight sentences with no filler, and the behavioral constraint (determinism, rerunnability) is front-loaded. The only weakness is that the opening sentence leads with outputs instead of the action.

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

Completeness3/5

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

An output schema exists, so return values need not be re-explained. However, the unexplained 'name' parameter and the total absence of usage routing leave gaps for a tool sitting in a dense family of exp_* siblings.

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

Parameters2/5

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

The single required parameter 'name' has 0% schema description coverage and is never mentioned in the description. An agent cannot tell whether 'name' is the experiment name, a file, or something else, so the description fails to compensate for the gap.

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

Purpose3/5

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

The description details what the tool returns (metrics per level, CIs, verdicts) rather than stating the action, leaving the verb to be inferred from the name 'exp_evaluate'. It does not distinguish this from siblings like exp_report or exp_compare, which likely also surface experiment results. The purpose lands as vague rather than a clear verb+resource statement.

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

Usage Guidelines2/5

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

There is no guidance on when to call this versus exp_report, exp_compare, or exp_runs, nor any prerequisites (e.g., whether an experiment must have been run first). The only contextual hint is 'rerunnable by anyone', which touches idempotence but not selection.

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

exp_getB
Read-only

Spec, status and run summary of one experiment.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the content returned (spec/status/run summary); it says nothing about error behavior or whether the experiment must exist, which is acceptable given annotations but not generous.

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?

A single front-loaded noun phrase with zero filler; appropriately sized for a trivial getter, though the fragmentary style borders on under-specification rather than true economy.

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

Completeness3/5

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

With an output schema present, return values need not be described, and the read-only annotations cover the safety profile. Still missing is any disambiguation from exp_list/exp_status/exp_runs and any hint about the 'name' parameter, leaving the definition minimally viable.

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

Parameters2/5

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

Schema description coverage is 0% — the single 'name' parameter has no description. The tool description never clarifies whether 'name' is an experiment name, an ID, or a path, so it fails to compensate for the documentation gap.

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

Purpose4/5

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

The phrase names the resource (one experiment) and enumerates the returned content (spec, status, run summary), and 'one experiment' is enough to distinguish it from exp_list. However it lacks an explicit verb and makes no reference to overlapping siblings such as exp_status or exp_runs.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus exp_list, exp_status, or exp_runs, even though those siblings clearly overlap. The agent must infer selection criteria on its own.

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

exp_listC
Read-only

Experiments on disk with run counts, state and whether a report exists.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds only that it reads from disk and what metadata is attached, but since an output schema exists, these details are redundant and it says nothing about pagination, ordering, or authentication needs.

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

Conciseness3/5

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

The single noun-phrase fragment is very short and contains no fluff, but it lacks a subject and verb, making it less clear than a well-formed sentence. It is not front-loaded with an action verb.

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

Completeness2/5

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

Given the tool is a simple read-only list with no parameters and a full output schema, the description still falls short by not stating the list action or any usage context. An agent could misread it as returning a single experiment rather than a collection.

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

Parameters4/5

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. Baseline of 4 applies.

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

Purpose3/5

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

The description names the resource (experiments on disk) and the data included (run counts, state, report existence), but it is a noun phrase that never states the list action. An agent must infer 'list' from the tool name rather than the description, and no sibling differentiation is provided.

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

Usage Guidelines1/5

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

No guidance on when to use this tool versus alternatives. It does not mention when to call exp_list versus exp_get, exp_runs, or other experiment-related siblings, nor any prerequisites.

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

exp_reportA
Idempotent

Write <experiments_dir>//report.md and report.html: identity (machine, TwinCAT version, project, git state, safety mode), criteria table, metrics per level, charts (primary measure per run; per-level mean/CI), run table, the spec, the audit log of writes during the run, and the interpretation — stored separately and labelled as not computed. interpretation= saves a new one (author=agent|operator|). firmware_check=true runs proj_vs_runtime first.

NameRequiredDescriptionDefault
fmtNoboth
nameYes
authorNoagent
firmware_checkNo
interpretationNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description goes beyond them by disclosing the two files written, that 'interpretation= saves a new one' with an author attribution scheme, and that firmware_check triggers proj_vs_runtime as a side effect. The audit-log content also signals that writes are tracked. Missing only details like overwrite behavior for existing reports.

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

Conciseness3/5

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

The verb and target paths are front-loaded, which is good, but the body is a long run-on list that conflates artifact sections with parameter behavior. Every clause carries information, yet the density could be structured more readably.

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?

An output schema exists, so return values need no explanation, and the description covers the substantive behavior an agent needs: what files are produced, that the interpretation is stored separately and labelled as not computed, and the firmware_check side effect. The unexplained fmt parameter and the lack of explicit alternative-tool routing are the remaining gaps.

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

Parameters3/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 compensate. It explains interpretation (saves a new one; author=agent|operator|<name>), author, and firmware_check, but never mentions what fmt='both' controls and only implies that name is the experiment directory. Two of five parameters remain unexplained, so it adds real but incomplete value.

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

Purpose4/5

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

The description opens with a specific verb+resource: 'Write <experiments_dir>/<name>/report.md and report.html', so the agent knows it produces report artifacts for a named experiment. It enumerates the artifact contents (identity, criteria table, metrics, charts, run table, spec, audit log, interpretation), which further distinguishes it from siblings like exp_evaluate or exp_compare that analyze rather than render. It stops short of explicitly naming a sibling contrast, so a 4 rather than 5.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: after a run, this is the tool that emits the report. The description does give conditional behavior ('firmware_check=true runs proj_vs_runtime first'), which hints at when the extra check matters, but there is no explicit guidance on when to prefer exp_report over exp_evaluate, exp_compare, or exp_get.

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

exp_runA
Destructive

Run an experiment in the background: per level × repetition → preconditions → factor values written → snapshot → capture profile started → stimulus → start acknowledged (done_when must go false) → done_when → settle → stop → measures → runs.jsonl. Factor values are read first and restored at the end or on abort (read back and checked). Every write is re-checked against the server guard, pinned to the machine the experiment started on, and audited with symbol and value; a refusal, a target change or a timed-out write stops the experiment. dry_run resolves every symbol, coerces condition values (enum names → ints) and prints the plan without writing. Starting is control-class: in guarded mode it asks once (elicitation / confirm_token); in full mode it does not. Only one experiment may run at a time.

NameRequiredDescriptionDefault
nameYes
resumeNo
dry_runNo
max_runsNo
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior5/5

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

Annotations only declare destructive=true and readOnly=false; the description adds substantial behavioral context beyond that: factor values are read first and restored on abort (read back and checked), every write is re-checked against a server guard, pinned to the starting machine, and audited with symbol/value, and a refusal/target change/timed-out write aborts the experiment. It also discloses the control-class confirmation flow (elicitation/confirm_token) and the single-experiment concurrency limit. This is exactly the extra context annotations cannot carry.

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

Conciseness3/5

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

Information-dense but structured poorly: the opening sentence is a long arrow-delimited pipeline that is hard to parse and not obviously the highest-value content for selection. The behavioral safety details are valuable but buried mid-paragraph. Every sentence does carry meaning, so it is not padded, just densely and unfront-loadedly written.

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?

An output schema exists, so return-value explanation is not needed. For a complex, destructive background runner the description covers the pipeline, safety/audit behavior, abort conditions, dry_run semantics, and confirmation flow. The main gap is undocumented parameters (resume, max_runs, name), which slightly under-serves correct invocation.

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

Parameters3/5

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

Schema description coverage is 0% across 5 parameters, so the description must carry the burden. It explains dry_run well (resolves symbols, coerces enum names to ints, prints plan without writing) and clarifies confirm_token's role in guarded mode. But name, resume, and max_runs get no explanation at all, leaving three of five parameters undocumented.

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

Purpose4/5

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

The description opens with a clear verb+resource ('Run an experiment in the background') and then specifies the exact execution pipeline (preconditions → factor values → snapshot → stimulus → ... → runs.jsonl). This distinguishes it from siblings like exp_validate, exp_status, exp_runs and exp_abort, which clearly handle other phases. The core purpose is unambiguous, though the pipeline detail crowds the framing.

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

Usage Guidelines3/5

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

Usage is implied through the described dry_run resolution/planning mode and the note that 'Only one experiment may run at a time,' plus the guarded-vs-full mode confirmation behavior. However, it never explicitly states when to prefer this over exp_validate or exp_save, nor routes the agent to exp_abort/exp_status for follow-up. Adequate but not directive.

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

exp_runsD
Read-only

Run records: level, status, measures, recording ids, duration, error.

NameRequiredDescriptionDefault
nameYes
last_nNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

D1.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that: no pagination behavior for last_n, no defaulting semantics, no scoping or ordering. It contributes essentially nothing beyond the annotations.

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

Conciseness2/5

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

Terse to the point of under-specification: a single sentence fragment with no verb. It is short but not because every element earned its place – it omits the core action while listing fields that the existing output schema already covers.

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

Completeness2/5

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

An output schema exists, so return values need not be re-explained, yet the description spends its only line enumerating them. For a required-name query tool with weak usage and parameter coverage, the description is inadequate on the dimensions that matter.

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

Parameters1/5

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

Schema description coverage is 0% and the description does not mention either parameter. The 'name' (required) identifier and 'last_n' (default 100) window are entirely unexplained in prose; the listed tokens are output fields, not parameters, so they provide no compensating meaning.

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

Purpose2/5

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

The description 'Run records: level, status, measures, recording ids, duration, error' essentially restates the tool name and enumerates fields rather than stating what the tool does. There is no verb or action ('list', 'retrieve runs for an experiment'), and no differentiation from siblings like exp_list or exp_get. It reads as a tautological field list.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no alternatives named despite many exp_* siblings (exp_list, exp_get, exp_run, exp_status). An agent must guess whether this lists, reads, or aggregates runs.

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

exp_saveB
Idempotent

Save an experiment spec (YAML or JSON) under <experiments_dir>//spec.yaml. Runs already recorded for that name are kept; resume picks up where they stopped.

NameRequiredDescriptionDefault
specYes
replaceNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior4/5

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

Annotations establish the safety profile (not read-only, idempotent, not destructive), and the description adds real value beyond them: recorded runs for that name are preserved and resume continues from where they stopped. This behavior about existing data is not derivable from the annotations or schema.

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?

Two tight sentences with no padding, and the core action plus destination path are front-loaded. The resume clause is the only slightly tangential addition, but it is useful behavioral context rather than waste.

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

Completeness3/5

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

An output schema exists so return values need not be described, and the key persistence/resume behavior is covered. However, the unexplained `replace` parameter and the absence of any usage routing leave gaps for a spec-writing tool.

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

Parameters2/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 parameter burden. It clarifies that spec may be YAML or JSON, but says nothing about the `replace` boolean (default true) — whether it replaces the spec, the runs, or the directory, leaving a mutation-relevant flag undefined.

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

Purpose4/5

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

The description gives a specific verb (Save) and resource (experiment spec in YAML or JSON) plus the exact destination path <experiments_dir>/<name>/spec.yaml. It is clearly distinguishable from read/run siblings, though it does not name an alternative tool explicitly.

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

Usage Guidelines3/5

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

Usage is implied by the save/resume framing but there is no explicit when-to-use vs alternatives guidance (e.g. vs exp_template, exp_validate, or exp_run). The resume note hints at context but the agent must infer the selection conditions.

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

exp_statusA
Read-only

Live state of a running experiment: planned/done/failed, current level, ETA, last error, live recording ids. For an experiment from an earlier session, the persisted status.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. Beyond that, the description discloses the live-versus-persisted behavior depending on session age, which is non-obvious context an agent could not get from the schema or annotations.

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

Conciseness5/5

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

Two sentences, no waste, and the primary behaviour (live state of a running experiment) is front-loaded before the earlier-session caveat. Every clause carries 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?

For a read-only status tool with annotations covering safety and an output schema covering return shape, the description supplies the remaining essentials: what state is reported and how older experiments behave. Only the parameter's identity is left unaddressed.

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

Parameters2/5

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

Schema description coverage is 0% and the only parameter is a bare 'name' string with no explanation in either schema or description. With a single parameter the ambiguity is limited, but the description contributes nothing about what name identifies (experiment vs run), so it fails to compensate for the coverage gap.

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

Purpose4/5

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

States a specific resource (experiment) and what is returned: the live state of a running experiment, enumerated as planned/done/failed, level, ETA, last error, recording ids. This clearly separates it from exp_list and exp_get in intent, though it never names a sibling to sharpen the boundary.

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

Usage Guidelines3/5

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

It draws a useful internal distinction between a currently running experiment (live state) and one from an earlier session (persisted status), which is genuine usage guidance. However it never routes the agent to alternatives such as exp_get or exp_runs, so the choice among experiment tools is left to inference.

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

exp_templateB
Read-only

A complete example experiment spec to edit (YAML text + the same as JSON): factors × levels, runs per level, preconditions, start/done conditions, measures (last/latency/pulses/settle/ dwell/edges/expr…), metrics (mean/std/cpk/p95), criteria, writes_allowed. kind: dosing_fill.

NameRequiredDescriptionDefault
kindNodosing_fill

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered structurally. The description adds content context by enumerating what the template contains (factors, levels, runs, preconditions, measures, metrics, criteria, writes_allowed), which is useful but does not disclose behavioral traits like whether the returned spec is meant to be edited in place or re-saved.

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?

One front-loaded sentence states the resource and then enumerates its contents; the enumeration is dense but each item earns its place by telling the agent what the template will include. Slightly run-on but not padded.

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?

An output schema exists, so return values need no explanation, and the tool is a simple one-parameter template provider. The description covers the template's content scope, leaving only the minor gap of not confirming how the template is consumed relative to siblings.

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

Parameters3/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 the burden for the single 'kind' parameter. It partially compensates by naming 'kind: dosing_fill', but it only echoes the schema's default value and never explains what the parameter controls or what other kinds exist.

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

Purpose3/5

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

The description states the tool provides a complete example experiment spec for editing, which is a clear resource, but it uses a noun phrase ('A complete example experiment spec to edit') rather than an action verb, leaving the agent to infer that this returns/creates a template. It also does not distinguish itself from siblings like exp_get or exp_list, so the agent cannot tell from the description alone why it would pick the template over an actual experiment spec.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The agent must infer that this is the starting point before building a real spec, but nothing in the text states that context.

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

exp_validateA
Read-only

Validate a spec (YAML/JSON text, a dict, or a saved experiment by name): structure, measures, metrics, criteria, writes_allowed vs what the spec writes, the server guard's view of each write, symbol resolution on the connected PLC, planned run count and a duration estimate.

NameRequiredDescriptionDefault
nameNo
specNo
resolve_symbolsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantive context: it discloses that it inspects the server guard's view of each write and performs symbol resolution against the connected PLC, which tells the agent this check depends on a live PLC connection.

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?

A single dense sentence with the verb and resource front-loaded, followed by an enumerated list of checks. No filler, though the long comma-separated list is slightly heavy to parse.

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 an output schema present, return values need no explanation, and annotations cover the safety profile. The description adequately covers input forms and validation scope for an agent to invoke it correctly.

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

Parameters4/5

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

Despite 0% schema description coverage, the description compensates well by explaining that 'spec' can be YAML/JSON text, a dict, or a saved experiment by name, and by noting symbol resolution on the PLC (the resolve_symbols toggle). Only resolve_symbols' exact semantics remain implicit.

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 (Validate) and resource (spec), then enumerates exactly what is checked: structure, measures, metrics, criteria, write guards, symbol resolution, run count, duration. This clearly distinguishes it from siblings like exp_run and exp_evaluate.

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

Usage Guidelines3/5

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

The verb 'validate' implies a pre-run check and the enumerated checks reinforce that context, but the description never explicitly says when to use this versus exp_run or exp_evaluate, nor does it name any alternative. Usage is implied rather than stated.

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

hmi_bindingsB
Read-only

Which HMI files/controls bind a PLC symbol (fnmatch on the symbol path).

NameRequiredDescriptionDefault
kindNo
limitNo
patternNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

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

Annotations already establish read-only, non-destructive behavior. The description adds useful behavioral context by disclosing that matching uses fnmatch on the symbol path. It does not mention limit or pagination behavior, but a 3 is appropriate with safety already covered.

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

Conciseness5/5

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

A single front-loaded sentence with no wasted words. It is appropriately terse for a lookup tool.

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

Completeness2/5

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

An output schema exists and annotations cover safety, so return values need not be explained. However, for a three-parameter tool with 0% schema description coverage, the description is inadequate and provides no routing among many HMI/project siblings.

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

Parameters2/5

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

Schema description coverage is 0% for all three parameters. The description hints that pattern uses fnmatch against the symbol path, but leaves kind and limit completely undocumented, so it only partially compensates for the schema gap.

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

Purpose4/5

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

States a specific resource (HMI files/controls) and relation (bind a PLC symbol), making the query identifiable. However, it does not distinguish itself from HMI siblings such as hmi_scan or hmi_vs_runtime.

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

Usage Guidelines2/5

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

No explicit when-to-use guidance, prerequisites, or alternatives are provided. The interrogative phrasing implies you use it to find bindings, but there are no conditions or exclusions.

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

hmi_scanA
Read-only

Index HMI symbol bindings: TE2000 .view/.content/.usercontrol/.json (%s%PLC1.X%/s%) and TF1800 .TcVIS (VisualElemMember paths -> kind 'tcvis'; ST input-action assignments -> kind 'tcvis_write'). root defaults to project.hmi_root, else the project root (which is where .TcVIS files live).

NameRequiredDescriptionDefault
rootNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: the root fallback chain (project.hmi_root, else project root) and the fact that .TcVIS files are what live at the fallback location, plus the kind values emitted for each source type.

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?

Two dense sentences, front-loaded with the purpose and file scope, followed by the root default. Technical shorthand like '%s%PLC1.X%/s%' is compact rather than wasteful, though it slightly obscures readability.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the scan inputs and kinds are covered. What is missing is whether the index is persisted for later tools (e.g. hmi_bindings), whether the scan is incremental, and whether the project must be open — meaningful gaps for an indexing operation.

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

Parameters4/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 for the single 'root' parameter, and it does so well by spelling out the default resolution order. It does not clarify what forms of path are accepted (relative vs absolute), which keeps it short of a 5.

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

Purpose4/5

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

The description states a specific verb ('Index') and resource ('HMI symbol bindings'), then enumerates exactly which file formats are covered (TE2000 .view/.content/.usercontrol/.json and TF1800 .TcVIS) and the kind labels produced. It does not, however, distinguish itself from the sibling tools hmi_bindings or hmi_vs_runtime, which an agent would plausibly confuse it with.

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

Usage Guidelines2/5

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

There is no explicit statement of when to run this scan versus alternatives such as hmi_bindings, nor any prerequisite or exclusion. Usage must be inferred from the file-format enumeration, which is implied context at best.

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

hmi_vs_runtimeB
Read-only

Broken HMI bindings: symbols bound in the HMI that do not exist on the running PLC (and, with check_source, whether the source declares them), plus declared variables with no HMI.

NameRequiredDescriptionDefault
check_sourceNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses exactly what categories of mismatch are reported (broken bindings vs orphan declared variables) and that check_source extends the analysis to source declarations. It stops short of describing output shape, but an output schema exists.

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?

A single sentence, front-loaded with the key concept ('Broken HMI bindings'), with no filler. The parenthetical and comma-plus clause make it dense and slightly awkward to parse, but the compactness is appropriate and every clause carries information.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the safety profile is in annotations. What's missing is disambiguation from the many HMI/PLC-comparison siblings and any guidance on preconditions or scope, leaving the definition adequate but with clear gaps for a heavily populated sibling set.

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

Parameters3/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 the burden for the single boolean parameter. The parenthetical '(and, with check_source, whether the source declares them)' gives a partial semantics hint for check_source, but it doesn't clarify the default-on behavior or the cost/tradeoff of enabling it. Partial compensation only.

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

Purpose4/5

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

The description states a specific diagnostic purpose: identifying HMI-bound symbols that don't exist on the running PLC plus declared variables with no HMI. It is concrete about what it reports. However, it does not distinguish itself from close siblings like hmi_bindings, hmi_scan, or proj_vs_runtime, leaving the agent to guess which to use.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no alternative tool is named or excluded. The only usage hint is the parenthetical describing what check_source adds, which is a parameter note rather than usage context. An agent cannot tell from this description when to prefer this over hmi_bindings.

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

hw_diagA
Read-only

A diagnosis message by its text id as the diagnosis history shows it (object 0x10F3; '#x4101', '0x4101'): message text, description, causes and remedies, class, reaction, reset — from the device's own catalogue when device is given, else every distinct message with that id and the device types / modules that use it.

NameRequiredDescriptionDefault
codeYes
deviceNo
revisionNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), so the description is not burdened with safety disclosure; it adds the conditional sourcing behavior (per-device catalogue vs. aggregated cross-device results) and enumerates what the message carries.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is one sprawling sentence with stacked parentheticals and em-dashes, and the opening clause is a fragment ('A diagnosis message by its text id...'), which slows parsing of an otherwise compact definition.

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

Completeness3/5

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

An output schema exists, so the field list is largely redundant and return-shape detail is not required; read-only annotations cover the safety profile. The gap is the unexplained `revision` parameter, which an agent cannot resolve from any structured field.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry the params. It explains `code` (accepted id formats) and `device` (per-device catalogue vs. aggregate view), but `revision` is never mentioned and remains fully undocumented.

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

Purpose4/5

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

States a specific resource (a hardware diagnosis message, object 0x10F3) retrieved by its text id, and gives concrete id formats ('#x4101', '0x4101'). It does not name or contrast any sibling (hw_lookup, hw_search, hw_object), so differentiation is left to inference.

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

Usage Guidelines3/5

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

It implies two usage modes via a parameter condition: pass `device` to read that device's own catalogue, omit it to get every distinct message plus the device types/modules that use it. There is no explicit when-to-use-this-vs-alternatives guidance or mention of prerequisites.

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

hw_lookupA
Read-only

EtherCAT device data from the ESI index (index\esi.db: the ESI files in the knowledge folder's manuals
and TwinCAT's ESI folders): name, product code, revisions, E-bus current, mailbox, DC modes, sync managers, PDOs with every entry (index, subindex, bit length, type; gaps marked), the predefined PDO assignments, slots of modular devices with their modules, the CoE object list, the diagnosis catalogue size, the ESI file(s). query = type / order code ('EL3356-0010'), part of a name, or a product code ('#x07D83052', '0x07D83052'; a number is read as a decimal product code and as digits of a type or name — read_as). revision: '#x…' as shown, '0x…' or decimal. detail: 'newest' (default) = all of that for the newest revision of each type (or of revision), other revisions as one line each; 'summary' = counts only; 'full' = everything for every revision. Nothing found: note says what is not there — a revision of an indexed device (revisions_available), or the device (then: add its ESI file). One CoE object with sub-indices, defaults and enum texts: hw_object; full-text: hw_search; a diagnosis text id: hw_diag. The index's first build starts by itself (minutes); until it is there the answer says so. source: the index the answer came from (state, built; state_note when it is not current). manuals names the indexed PDF manuals that mention the product, with pages (the twincat-docs skill reads them).

NameRequiredDescriptionDefault
limitNo
queryYes
detailNonewest
revisionNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already identify this as a safe read-only operation, and the description adds meaningful behavioral context beyond that. It discloses the first-build delay, the source/state reporting, not-found behavior with revisions_available, and manual references with pages.

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 and dense, but the complexity of the tool justifies most of the detail, and the core purpose is front-loaded. It could be structured more readably, but little of the text appears to be pure filler.

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?

Given the tool's complexity and the presence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers the data domain, query modes, fallback behavior, index-build state, source reporting, and sibling routing.

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

Parameters4/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 parameter meaning. It thoroughly explains query formats, revision formats, and detail modes, but it does not mention the limit parameter at all, leaving one of the four parameters undocumented.

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 description states a specific resource and scope: EtherCAT device data from the ESI index, with a detailed list of what is returned. It clearly distinguishes this lookup from sibling tools such as hw_object, hw_search, and hw_diag.

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

Usage Guidelines5/5

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

It explicitly names the alternatives and the conditions that select them: use hw_object for one CoE object, hw_search for full-text lookup, and hw_diag for a diagnosis text id. It also explains the detail modes, which helps the agent choose how to query.

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

hw_moduleB
Read-only

A module of a modular device (AX8000, EP/EL with slots, TSC …) by its ModuleIdent as hw_lookup's slots give it: PDOs, CoE objects, diagnosis messages. With device, the module that device's slot means (hw_lookup's rule: the device's own file, then the module file paired with it by name, then the only one), else every module with that ident.

NameRequiredDescriptionDefault
identYes
deviceNo
revisionNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this is a lookup keyed by ModuleIdent returning PDOs, CoE objects and diagnosis messages, plus the device-resolution rule, but says nothing about ambiguity handling or rate limits beyond that.

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

Conciseness3/5

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

Two sentences, front-loaded with the resource and key, so the important information comes first. However, the parenthetical jargon and the run-on second clause about device resolution make it harder to parse than it needs to be.

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

Completeness3/5

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

For a read-only lookup with an output schema present (so return values need no elaboration), the description is adequate on ident and device but silent on `revision` and on behavior when multiple modules match. Complete enough to invoke, but with visible gaps.

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

Parameters3/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 burden. It explains `ident` (the ModuleIdent as hw_lookup's slots give it) and gives a detailed resolution rule for `device`, but `revision` goes entirely unexplained, leaving one of three parameters undocumented.

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

Purpose4/5

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

The description names the resource (a module of a modular device, e.g. AX8000/EP/EL) and the identifying key (ModuleIdent), plus what it returns (PDOs, CoE objects, diagnosis messages). This is specific, but the verb is implicit ('is a module') and the phrasing is dense jargon rather than a clean action statement, so it falls short of a 5.

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

Usage Guidelines3/5

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

It gives a conditional rule for the optional `device` parameter (device's own file, then the paired module file by name, then the only one), which is genuine usage context. However, it never says when to prefer this tool over hw_lookup/hw_object/hw_diag or what happens if ident is unmatched, so guidance is implied rather than explicit.

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

hw_objectA
Read-only

One CoE object of a device from its ESI (newest revision unless revision): every sub-index with type, bit size and offset, access, PDO mapping, backup/setting flags, the default (decoded from DefaultData, enum text when there is one), min/max, unit code, enumeration texts; array elements one by one. index: '#x8000' or '0x8000' (4 hex digits alone are read as hex); one sub-index in CoE notation '8000:11' (the sub-index in hex, as Beckhoff's manuals write it: 8000:11 = sub-index 17) → sub and subitems with just that one. device: the exact type ('EL3356-0010').

NameRequiredDescriptionDefault
indexYes
deviceYes
revisionNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish that this is a read-only, non-destructive operation. The description adds useful behavioral context: it defaults to the newest revision unless revision is supplied, returns sub-index details, and changes shape with sub/subitems for a single CoE sub-index.

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 purpose is front-loaded and the dense semicolon-separated format is information-rich with little waste. It is slightly repetitive around enum/enumeration text and could be structured more readably.

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?

An output schema exists, so return values do not need full explanation in the description. The description still provides enough object-detail context and parameter guidance for an agent to invoke the tool correctly, with only minor revision-format ambiguity remaining.

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

Parameters4/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 parameter meaning. It thoroughly documents index formats and the exact device type, though it only briefly says 'newest revision unless revision' without explaining accepted revision formats.

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

Purpose4/5

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

The description clearly identifies the resource as one CoE object of a device from its ESI and lists the detailed contents returned. It does not explicitly differentiate itself from sibling tools such as hw_module or hw_lookup, so it stops short of a 5.

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

Usage Guidelines2/5

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

It explains parameter notation and the default revision behavior, but it does not state when to use this tool versus alternatives or when not to use it. There is no routing guidance among the many hardware-related siblings.

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

infosys_booksA
Read-only

List the Infosys books (documentation sets) of the Help Viewer package installed with TwinCAT, with page counts — offline, one index of every book. pattern is a glob on the slug ('tcplclib_*', 'json'); category: plc-library | function-tf | engineering-te | twincat-system | hardware | other. TwinCAT 2 books are excluded.

NameRequiredDescriptionDefault
limitNo
patternNo
categoryNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish the safe read-only profile (readOnlyHint=true, destructiveHint=false). The description adds meaningful behavior beyond that: the enumeration is offline, results include page counts, and TwinCAT 2 books are filtered out — useful scope context that the annotations do not convey.

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 definition is front-loaded, leading with the verb and resource before pivoting to parameter hints. It is dense and information-rich, though the em-dash construction and inline parameter notes make it slightly less scannable than it could be.

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 an output schema present, return values need not be described, and the description still notes the page-count field and scope exclusions. Combined with pattern/category guidance, an agent has nearly everything needed; only the 'limit' parameter's effect is unexplained.

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

Parameters4/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 parameter meaning, and it does for two of three params: 'pattern is a glob on the slug' with concrete examples ('tcplclib_*', '*json*'), and category with its full set of valid values. Only 'limit' is left undocumented, which is a minor gap against the otherwise strong compensation.

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?

Specific verb 'List' plus a precise resource ('Infosys books (documentation sets) of the Help Viewer package installed with TwinCAT') and scope ('offline, one index of every book, with page counts'). This clearly differentiates it from siblings like infosys_search, infosys_get_page, and infosys_index, which retrieve content rather than enumerate books.

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

Usage Guidelines3/5

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

The description gives strong scoping signals — 'offline' and 'TwinCAT 2 books are excluded' — which imply when the tool applies. However, it never explicitly states when to choose this over alternatives such as infosys_index or infosys_search, so usage is only inferred rather than stated.

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

infosys_declarationA
Read-only

Declaration of a library symbol as data: kind, inputs/outputs/in_out (name, type, default, description from the page's table), struct members, enum values, return type, EXTENDS / IMPLEMENTS, methods (name, definition location, description) and properties (type, access, initial value) of an FB, plus the ST declaration text and the page URL. The thing to call before writing code against an FB you have not used before. A name documented by different pages (two libraries, two methods of one name) is refused as ambiguous with the candidates — pass library=; one page in several books is one answer (same_page_in); also_in names the other libraries. A member as '.' (FB_WG_ComboFilter.Call): the page below that FB in the Help Viewer contents (Beckhoff titles a method page with its bare name); parent names the FB of a member. The twincat-docs skill's docs_declaration resolves names by the same rule.

NameRequiredDescriptionDefault
symbolYes
libraryNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: ambiguous names are 'refused as ambiguous with the candidates', library= disambiguates, same_page_in and also_in are returned for cross-book cases, and member resolution follows the Help Viewer contents hierarchy. This is rich transparency for a read-only retrieval tool.

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

Conciseness3/5

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

The description is front-loaded with the return-field list, but it is long and dense, with run-on sentences and parenthetical asides. The final sentence about the twincat-docs skill's docs_declaration resolving names by the same rule is likely extraneous for an agent invoking this tool, and the member-resolution explanation could be more structured.

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?

Given the output schema exists, the description need not explain return values in full, but it still lists them helpfully. Annotations cover read-only safety. The description covers ambiguity handling, member syntax, and the purpose of the library parameter. It lacks guidance on finding a symbol name when unknown (e.g., using infosys_search_symbols) or on behavior when the symbol is not found, but it is otherwise complete for a two-parameter read-only lookup.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate for undocumented parameters. It explains the library parameter's role in resolving ambiguity and shows that symbol can take a member form like '<FB>.<name>' (FB_WG_ComboFilter.Call). However, it does not describe the plain symbol format, case sensitivity, or other parameter details, so compensation is partial.

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

Purpose4/5

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

The description states a specific verb and resource: 'Declaration of a library symbol as data' and enumerates the returned fields (kind, inputs/outputs/in_out, struct members, enum values, return type, EXTENDS/IMPLEMENTS, methods, properties, ST declaration, page URL). It is clear what the tool does, but it does not explicitly contrast with sibling tools like infosys_get_page or infosys_search_symbols, so sibling differentiation is implied rather than stated.

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?

It provides a clear trigger: 'The thing to call before writing code against an FB you have not used before.' It also explains how to handle ambiguous names via the library parameter. However, it does not name alternatives such as infosys_search_symbols for finding a symbol first, nor does it specify when not to use this tool.

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

infosys_get_pageA
Read-only

A documentation page as Markdown (headings, tables, fenced code), read from the local Help Viewer package — any page in it, indexed or not; doc version + breadcrumb included. ref: full Infosys URL, 'book/pageid', a bare page id, or a symbol name ('ADSREAD'). Offline. Use max_chars to keep it short.

NameRequiredDescriptionDefault
refYes
offsetNoskipped first: the next page is offset=<next_offset>
refreshNo
sectionNo
max_charsNocharacters shown, 200-60000; read on with section= or offset=

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare this as a safe read-only operation, and the description adds meaningful context: offline access, Markdown output structure, inclusion of doc version and breadcrumb, and coverage of unindexed pages. It does not fully explain pagination or truncation behavior beyond mentioning max_chars.

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

Conciseness5/5

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

The description is compact and front-loaded, naming the resource and output format first, then ref formats and practical limits. Every sentence and fragment carries useful information without repetition.

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

Completeness3/5

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

The presence of an output schema and read-only annotations reduces the burden, and the description covers the core ref and max_chars behavior. Still, for a five-parameter tool with 40% schema coverage, the omission of section, refresh, and offset semantics leaves important invocation details incomplete.

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

Parameters3/5

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

Schema description coverage is only 40%, and the description compensates partially by explaining accepted ref formats and the purpose of max_chars. However, it leaves offset, refresh, and section unexplained, so an agent must infer their behavior from sparse schema text.

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

Purpose4/5

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

The description states a specific verb and resource: retrieving a documentation page as Markdown from the local Help Viewer package. It adds useful scope detail (any page, indexed or not; version and breadcrumb included) but does not explicitly differentiate itself from sibling tools such as infosys_search or infosys_declaration.

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

Usage Guidelines3/5

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

Usage is implied through accepted ref formats and the offline nature of the tool, but there is no explicit guidance on when to choose this over infosys_search or how to use search first to discover a ref. The max_chars note is parameter guidance rather than a when-to-use rule.

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

infosys_indexD
Read-only

The local Help Viewer index holds every book and is built as a whole (the first time by itself, later only with kb_rebuild(index='infosys') once the user approves) — this tool changes nothing here and says so; kb_status / tc_doctor show the index state.

NameRequiredDescriptionDefault
bookYes
forceNo
max_pagesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

D1.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description merely restates it ('this tool changes nothing here'). It adds no detail on what the tool returns, what 'force' or 'max_pages' would cause, or any rate/approval constraints specific to this call.

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

Conciseness2/5

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

It is a single run-on sentence stitched together with em-dashes and parentheticals, so the key point is not front-loaded. The content is simultaneously long-winded and under-specifying, which is the opposite of efficient concision.

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

Completeness2/5

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

An output schema exists so return values need not be explained, but for a tool with a required 'book' parameter plus 'force'/'max_pages' the description omits any account of what the call does or how those parameters behave. It is not complete enough for an agent to invoke the tool correctly.

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

Parameters1/5

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

Schema description coverage is 0% and all three parameters (book, force, max_pages) are undocumented in both schema and description. The description mentions no parameter at all and does not compensate for the coverage gap, leaving 'force' and 'max_pages' entirely opaque.

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

Purpose2/5

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

The description never states what infosys_index actually does. It describes the Help Viewer index being built as a whole and asserts the tool 'changes nothing here,' which is closer to a disclaimer than a purpose statement. An agent cannot tell from this text what action calling infosys_index performs, even though the name implies indexing.

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

Usage Guidelines2/5

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

It names kb_rebuild(index='infosys') as the tool that later builds the index and points to kb_status / tc_doctor for state, but it never says when to call infosys_index itself, nor what the alternatives are for the same purpose. Guidance is about neighboring tools, not this one.

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

infosys_search_codeA
Read-only

Search the code examples of the indexed pages for a fragment — a call pattern, an attribute, a constant (case-insensitive substring of the code as written; non-breaking spaces count as spaces). language: one that occurs in the index (an unknown one is refused with the list), '' / 'none' = samples without a label. limit 1..50; total_matches says how many there are. ignore_spacing=true also matches when only the spacing around punctuation differs. Returns the matching lines with context and the page URL.

NameRequiredDescriptionDefault
limitNoresults shown, 1-50
queryYes
languageNo
ignore_spacingNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and non-destructive, so safety is covered. The description adds genuinely new behavior: unknown language values are rejected with the list of valid ones, total_matches reports the unshown count, results include matching lines with context plus the page URL, and non-breaking spaces are normalized to spaces.

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?

It is densely packed but nearly every clause carries parameter or return semantics; nothing is boilerplate. The single long run-on sentence with semicolons makes it slightly harder to scan than a bulleted or front-loaded layout would.

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?

With four parameters, an output schema, and full read-only annotations, the definition covers the search semantics, the sentinel values, the refusal path, the limits, and the shape of the returned lines. An agent could invoke it correctly and interpret total_matches without further information.

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 coverage is only 25% (only limit is documented in-schema), so the description must carry the load and does: it defines query as a case-insensitive substring of code as written including the non-breaking-space normalization, defines language membership and the '' / 'none' sentinel, restates the 1..50 limit with total_matches semantics, and explains ignore_spacing as punctuation-adjacent spacing tolerance.

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

Purpose4/5

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

The description uses a specific verb and resource ('Search the code examples of the indexed pages for a fragment') and enumerates the fragment kinds (call pattern, attribute, constant), which distinguishes it from the generic infosys_search and infosys_search_symbols. It never names those siblings explicitly, so the differentiation is left to inference.

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?

It gives clear operating context: substring matching is case-insensitive over code as written, an unknown language is refused with the valid list, '' / 'none' selects unlabeled samples, and limit is bounded 1..50. What is missing is an explicit statement of when to prefer this over infosys_search_symbols or infosys_search.

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

infosys_search_symbolsA
Read-only

Find library symbols (function blocks, functions, structs, enums, aliases, interfaces, GVLs) by name fragment in the local Help Viewer index; exact > prefix > contains. kind: FunctionBlock | Function | Program | Method | Property | Action | Enum | Struct | Union | Alias | Interface | GlobalVariable | Library. library: 'Tc2_System' or the book slug. Offline; while the index is still being built the answer says so.

NameRequiredDescriptionDefault
kindNo
limitNoresults shown, 1-50
queryYes
libraryNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuine behavioral context beyond that by disclosing match precedence (exact > prefix > contains), that the search is offline, and that results will report when the index is still being built. It stops short of describing result shape or truncation behavior, but the output schema covers return values.

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

Conciseness5/5

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

Three compact sentences/semicolon clauses, front-loaded with purpose then matching rules then parameter values. The long kind enumeration is dense but is the minimum needed to convey the accepted values, so nothing is wasted.

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?

For a four-parameter read-only search tool with an output schema, the description covers purpose, matching semantics, filter vocabularies, and the offline/index-building edge case. It leaves only minor things unsaid, such as default limit behavior and what an empty result implies.

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

Parameters4/5

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

Schema coverage is only 25%, with just `limit` described, so the description must compensate and does: it enumerates the accepted `kind` values exhaustively and gives `library` examples ('Tc2_System' or the book slug), plus the fragment-matching semantics of `query`. Minor gap: it does not clarify that null kind/library means no filtering.

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

Purpose4/5

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

States a specific verb and resource: find library symbols (function blocks, functions, structs, enums, aliases, interfaces, GVLs) by name fragment in the local Help Viewer index. This is clear enough to separate it from generic doc search siblings like infosys_search, but the description never names an alternative tool, so the differentiation is implied rather than asserted.

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

Usage Guidelines3/5

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

Usage is implied by the resource scope ('library symbols in the local Help Viewer index'), and the offline/index-building caveat is useful context. However, there is no explicit when-to-use versus infosys_search, infosys_search_code, infosys_declaration, or proj_resolve_symbol, so the agent must infer routing.

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

ipc_delete_fileC
Destructive

Delete a file on the target IPC. Destructive-class.

NameRequiredDescriptionDefault
pathYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior2/5

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

The annotations already declare destructiveHint=true and idempotentHint=false, and the 'Destructive-class.' sentence merely restates the destructiveHint annotation rather than adding context. It omits what actually happens on delete, whether confirm_token is required for safety, or any auth/reversibility detail.

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?

Two short, front-loaded sentences with the action stated first and no filler. The second sentence is largely redundant with the annotations, but the structure is otherwise efficient.

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

Completeness2/5

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

For a destructive mutation tool with 0% parameter documentation and an unexplained confirm_token safety workflow, the description is far too thin. The existing output schema removes the need to describe return values, but the invocation preconditions remain undisclosed.

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

Parameters2/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 compensate, yet it mentions neither 'path' nor 'confirm_token'. The confirm_token parameter is especially opaque — its purpose and the conditions under which it must be supplied are documented nowhere.

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

Purpose4/5

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

States a specific verb (delete) and resource (file) scoped to the target IPC, clearly distinguishing it from ipc_read_file/ipc_write_file/ipc_list_dir. It doesn't explicitly name a sibling alternative, but the operation is unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this versus alternatives, no prerequisites, and crucially no explanation of the confirm_token workflow despite a sibling tc_request_confirmation and a required path. An agent gets only 'this deletes' with no operational context.

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

ipc_eventlogA
Destructive

Windows event log of the target (Windows 7/10/11 IPCs): runs wevtutil on the IPC via the System Service, reads the result back and deletes the temp file. Also lists the event providers registered on the target whose name contains 'TwinCAT' or 'Beckhoff', so a provider that does not exist there (the default name differs between TwinCAT builds) is reported as such instead of an empty result. Not available on Windows CE / TC-BSD targets. Destructive-class because it starts a process on the IPC: confirm with tc_request_confirmation(action='ipc_eventlog', target=).

NameRequiredDescriptionDefault
logNoApplication
countNo
providerNoTwinCAT System Service
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and non-readOnly, but the description goes further: it discloses that it runs wevtutil through the System Service, reads back a temp file and deletes it, that it starts a process on the IPC (the reason for the destructive class), and that the confirmation token is required. That is meaningful behavioral context beyond the structured flags.

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-loads what the tool does and the key caveat, with every sentence carrying information. It is a little dense and the provider sentence is convoluted, but nothing is padding.

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?

For a destructive, process-spawning tool with an output schema present, the description covers the safety workflow, platform exclusions, and the surprising provider-listing side effect. Only the per-parameter meanings (count, confirm_token) remain thin.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry the parameter burden, and it only partially does: 'target=<log>' implies the log-name parameter and the TwinCAT/Beckhoff discussion implies the provider parameter, but 'count' and 'confirm_token' semantics are never explained. Partial compensation only.

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+resource: it reads the Windows event log of the target IPC (via wevtutil) and additionally enumerates TwinCAT/Beckhoff event providers. This distinguishes it clearly from the other ipc_* siblings (file/dir/process/reboot) which do different things.

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

Usage Guidelines5/5

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

Explicitly states the when-not ('Not available on Windows CE / TC-BSD targets') and prescribes the required pre-step (confirm with tc_request_confirmation(action='ipc_eventlog', target=<log>)). It also explains why the provider-listing behavior exists, so the agent knows what to expect.

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

ipc_list_dirA
Read-only

List files on the target matching a Win32 pattern. Prefer 'boot:*' (the live boot folder on any target OS; the result names the absolute folder in resolved_pattern) over a hard-coded 'C:\TwinCAT\3.1\Boot*', which is the stale legacy folder on 3.1.4026. Other prefixes: see ipc_read_file.

NameRequiredDescriptionDefault
patternYes
max_entriesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it notes the result names the absolute folder in resolved_pattern and warns that the hard-coded legacy path is stale on 3.1.4026. It does not discuss permissions, rate limits, or other operational traits, but the additions are meaningful.

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

Conciseness5/5

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

The description is front-loaded and dense, with three sentences that each earn their place. The first states the operation, the second gives the key pattern preference and result detail, and the third routes other prefixes to a sibling. There is no filler.

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 an output schema available, the description need not explain return values, and the annotations cover safety. It provides strong guidance for the critical pattern parameter and points to a sibling for other prefixes. The only notable gap is the unmentioned max_entries parameter, but its default makes this a minor omission.

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

Parameters3/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 parameter meaning. It thoroughly explains the required 'pattern' parameter, including Win32 matching, preferred values, and where to look for other prefixes. However, it entirely omits the optional 'max_entries' parameter, leaving partial compensation for a two-parameter 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 description states a specific verb and resource: 'List files on the target matching a Win32 pattern.' It also distinguishes itself from the sibling ipc_read_file by directing other prefixes there. An agent can identify the tool's function and key alternative without opening either 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?

It gives clear context for pattern selection, advising 'boot:*' over the hard-coded legacy path, and names the alternative sibling ipc_read_file for other prefixes. However, it does not explicitly state when to use this tool versus other file-related tools in general, so it falls short of full when/when-not guidance.

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

ipc_read_fileA
Read-only

Read a file from the target IPC's file system over ADS (no share needed). Binary → base64. Prefer the OS-independent prefixes, which the target resolves itself: 'boot:' (the live TwinCAT boot folder — C:\ProgramData\Beckhoff\TwinCAT\3.1\Boot on 3.1.4026, \Hard Disk\TwinCAT\3.1\Boot on CE7), 'bootprj:', 'bootdata:', 'target:', 'config:', 'install:', 'user1:'..'user9:'. On 4026 the old absolute C:\TwinCAT\3.1\Boot still exists but is a stale legacy copy (e.g. a CurrentConfig.xml from years ago) — do not draw conclusions from it.

NameRequiredDescriptionDefault
pathYes
as_textNo
encodingNoutf-8
max_bytesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds real substance beyond that — ADS transport with no share requirement, binary-to-base64 conversion, target-resolved path prefixes, and a warning that the legacy C:\TwinCAT\3.1\Boot path is stale. It stops short of covering error behavior or the max_bytes truncation semantics.

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 action and transport before diving into prefix details, and every clause is informative. The stale-legacy-path caution is long, but it earns its place by preventing a common misinterpretation.

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?

An output schema exists so return values need no explanation, and annotations cover safety. The path semantics are thoroughly covered for the complex TwinCAT target layout; only as_text/encoding/max_bytes semantics are missing, a minor gap for a read tool.

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

Parameters3/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 four parameters. It thoroughly documents the 'path' parameter via prefix guidance and hints at 'as_text' via 'Binary → base64', but leaves 'encoding' and 'max_bytes' entirely unexplained. Partial compensation only.

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

Purpose4/5

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

Specific verb+resource: 'Read a file from the target IPC's file system over ADS (no share needed)'. The transport detail and 'Binary → base64' make the operation unambiguous. It does not explicitly name the sibling proj_read_file, but the 'target IPC's file system' scoping distinguishes it well enough.

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

Usage Guidelines3/5

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

The prefix guidance ('Prefer the OS-independent prefixes...') is strong invocation advice, but the description never states when to use this tool versus alternatives like proj_read_file or how it relates to ipc_list_dir. Usage is implied through path conventions rather than explicit selection criteria.

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

ipc_rebootC
Destructive

Reboot (or shut down) the target IPC via the System Service. Destructive-class.

NameRequiredDescriptionDefault
delay_sNo
confirm_tokenNo
shutdown_onlyNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is fully covered by structured data. The description's 'Destructive-class' merely repeats that annotation and adds only the minor context that the operation goes through the System Service. It does not explain what gets destroyed, whether confirm_token is required, what delay_s does, or any permissions/auth needs.

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 very short and front-loads the action and target in the first clause. The trailing 'Destructive-class.' is redundant with the destructiveHint annotation, so that fragment does not fully earn its place, but overall it is not bloated.

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

Completeness2/5

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

For a destructive 3-parameter tool, the description leaves major gaps: no parameter semantics for confirm_token or delay_s, no usage guidance, and no alternatives to consider. Annotations and the output schema cover safety and return values, but the description still fails to give the agent enough to invoke the tool correctly with confirmation and delay options.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should carry the full burden of explaining the three parameters, but it does not. The phrase '(or shut down)' faintly hints at shutdown_only, yet delay_s and confirm_token receive no explanation at all, leaving critical semantics undocumented. This is inadequate for a destructive operation with a likely confirmation parameter.

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

Purpose4/5

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

The description states a specific verb+resource: 'Reboot (or shut down) the target IPC via the System Service.' This is clear and distinguishes the operation from passive reads and TwinCAT runtime restarts by specifying the IPC target and System Service channel. However, it does not explicitly name or contrast with sibling tools like xae_restart_twincat or tc_set_mode, so the sibling differentiation is only implicit.

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

Usage Guidelines2/5

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

The description offers no when-to-use guidance, no prerequisites, and no alternatives. 'Destructive-class' signals caution but does not help the agent decide between this and other restart or shutdown tools. Usage is only implied by the tool name and purpose.

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

ipc_start_processC
Destructive

Start a process on the target IPC (NT_StartProcess equivalent). Destructive-class.

NameRequiredDescriptionDefault
pathYes
directoryNo
command_lineNo
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior2/5

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

The 'Destructive-class' tag merely restates the destructiveHint=true annotation already provided, adding no new behavioral context. Critical details an agent needs before launching a process on a remote IPC — whether a confirm_token must be obtained first, what permissions are required, and what happens to the returned process handle — are absent.

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?

Two compact sentences with the action front-loaded and no filler. It is efficient, though the terseness borders on being a stub for a destructive multi-parameter tool.

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

Completeness2/5

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

For a destructive process-launch operation with four undocumented parameters and a confirmation token, the description is far too thin. The output schema covers return values, but the missing confirmation/permission model and parameter meanings leave an agent unable to invoke this safely.

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

Parameters2/5

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

Schema description coverage is 0% for four parameters, so the description carries the full documentation burden and delivers almost nothing. It never explains path, directory, command_line, or the all-important confirm_token, leaving the agent to guess at defaults and confirmation semantics.

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

Purpose4/5

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

States a specific verb and resource ('Start a process on the target IPC') and adds a domain mapping ('NT_StartProcess equivalent'), so the action is unambiguous. However, it does nothing to distinguish itself from the many sibling ipc_* tools (ipc_reboot, ipc_write_file, ipc_delete_file) or to signal how it relates to the tc_* safety tooling.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus alternatives, and no mention of the prerequisite workflow implied by the sibling tc_request_confirmation / tc_safety_status tools. The presence of a confirm_token parameter suggests gating, but the description gives no guidance on obtaining or passing it.

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

ipc_write_fileC
Destructive

Write a file on the target IPC (text or base64). Control-class.

NameRequiredDescriptionDefault
pathYes
textNo
appendNo
base64_dataNo
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered structurally. The description adds essentially nothing behavioral: it does not say it overwrites existing content, does not explain the 'Control-class' designation, and does not describe the confirm_token confirmation flow implied by the schema.

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

Conciseness3/5

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

Two short fragments that are front-loaded with the core action. However, 'Control-class' occupies space without conveying usable meaning, so the brevity is under-specification rather than true conciseness.

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

Completeness2/5

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

An output schema exists, so return values need no explanation, but for a destructive control-class write with 5 undocumented parameters and an unexplained confirm_token, the description leaves major gaps an agent needs before invoking it safely.

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

Parameters2/5

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

Schema description coverage is 0% across 5 parameters. The description only touches text vs base64, mapping loosely to two params, and says nothing about append, path semantics, or confirm_token. It does not compensate for the total lack of parameter documentation.

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

Purpose4/5

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

States a specific verb and resource (write a file on the target IPC) and notes the text vs base64 modes, which distinguishes it from siblings like ipc_read_file and ipc_delete_file. The trailing 'Control-class' label is unexplained jargon that slightly clouds an otherwise clear purpose.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as ads_write, ipc_read_file, or ipc_delete_file. It hints that text or base64 can be supplied but gives no context, prerequisites, or exclusions.

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

kb_add_projectA
Idempotent

Index a project folder for kb_search (cross-project pattern search) — ONLY a folder the user named. Reads .TcPOU/.TcDUT/.TcGVL/.TcIO beneath it into the knowledge database; nothing is indexed by default. Refused: the plugin's folders, the knowledge folder, a folder inside or around one already indexed (its units would be there twice). The answer names the files that could not be read (parse_errors) and the files no PLC project compiles (not_in_project). Refused in readonly mode; audited (N127).

NameRequiredDescriptionDefault
pathYes
labelNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations, which only say non-readonly, idempotent, non-destructive: the description discloses which file types are read (.TcPOU/.TcDUT/.TcGVL/.TcIO), that duplicate-unit indexing is blocked, that the response surfaces parse_errors and not_in_project, and that the action is audited (N127). This is the kind of write-side context annotations cannot convey.

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 core action and its consumer, then terse clause-by-clause constraints. Dense but every clause carries information; the parenthetical N127 reference is the only mildly opaque bit.

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?

For an indexing mutation with an output schema, the description covers read scope, refusal conditions, error reporting and audit trail, which is nearly everything an agent needs. The one hole is the undocumented `label` parameter.

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

Parameters2/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 parameter meaning, yet it only implies that `path` is a project folder. The `label` parameter is never mentioned anywhere in the description or schema, leaving an agent to guess its purpose.

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 ('Index a project folder') and names the downstream consumer ('for kb_search (cross-project pattern search)'), which distinguishes it from kb_reindex, kb_rebuild and kb_remove_project. The scope ('nothing is indexed by default') further pins down what the call does.

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

Usage Guidelines5/5

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

Explicit precondition: 'ONLY a folder the user named', plus an enumerated refusal list — plugin folders, the knowledge folder, and folders overlapping an already-indexed one. It also states the readonly-mode refusal, so an agent knows exactly when the call will fail.

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

kb_rebuildA
Idempotent

Rebuild one index of the knowledge folder from its source on this PC — ONLY with the user's approval (docs/KNOWLEDGE_BASE.md rule 6: the user is asked, or pass the confirm_token of tc_request_confirmation(action='kb_rebuild', args={'index': …})). index: 'infosys' (the Help Viewer package, the plugin's extractor, in its own process — minutes; the current index stays in use until the new one is complete and then replaces it), 'manuals' (the PDFs in manuals, in its own process), 'esi' (the ESI files in manuals\ and TwinCAT's ESI folders → index\esi.db, in its own process — minutes; the current index stays in use until the new one is complete). Without force an index that is complete and current is left as it is. Nothing is deleted. kb_status / tc_doctor show the progress.

NameRequiredDescriptionDefault
forceNo
indexYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (idempotent, non-destructive), the description discloses duration ('minutes'), process isolation ('in its own process'), the atomic-swap semantics ('the current index stays in use until the new one is complete and then replaces it'), the output location (index\esi.db), the safety guarantee ('Nothing is deleted') and how to monitor progress (kb_status / tc_doctor). That is substantial context the annotations cannot carry.

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 most important constraints — the rebuild scope and the approval requirement — are front-loaded, and every clause carries information. It loses a point for the repetitive 'in its own process' phrasing across all three index variants and for cramming everything into one dense paragraph with nested parentheses rather than a short list.

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 multi-step, approval-gated maintenance operation this covers the full agent workflow: permission gating, per-index behavior, no-op conditions, side-effect safety, progress monitoring, and where the artifact lands. An output schema exists, so return values need not be described.

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 does: it enumerates the three valid index values with per-value semantics ('infosys' Help Viewer package, 'manuals' PDFs, 'esi' ESI files and TwinCAT ESI folders), explains force's effect on skip-if-current behavior, and explains confirm_token's origin. No parameter is left ambiguous.

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

Purpose4/5

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

The opening clause gives a specific verb and resource — 'Rebuild one index of the knowledge folder from its source on this PC' — plus the scope ('one index'), so an agent knows exactly what is being acted on. It stops short of a 5 because the sibling kb_reindex is never named or contrasted, leaving the boundary between 'rebuild' and 'reindex' to inference.

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

Usage Guidelines5/5

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

It states an explicit precondition ('ONLY with the user's approval'), cites the governing rule (docs/KNOWLEDGE_BASE.md rule 6) and the exact confirmation mechanism to satisfy it (tc_request_confirmation(action='kb_rebuild', ...)). It also tells the agent when the tool is a no-op ('Without force an index that is complete and current is left as it is'), which is genuine when/when-not guidance.

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

kb_reindexA
Idempotent

Re-index one project folder (or every changed one) after edits. Refused in readonly mode; audited (N127).

NameRequiredDescriptionDefault
pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond that: it is refused in readonly mode and is audited (N127), both of which affect how the agent should approach the call. It does not describe interruption safety or how 'changed' folders are detected, but the annotations lower the burden.

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

Conciseness5/5

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

The description is two tightly written sentences with no wasted text. The main operation is front-loaded, followed by the readonly restriction and audit note.

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?

This is a low-complexity tool with one optional parameter, an output schema, and informative annotations. The description covers the core operation, scope, precondition, and audit side effect. Remaining gaps—path format and the distinction from kb_rebuild—are minor but non-trivial.

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

Parameters3/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 compensate for the single optional 'path' parameter. It implies that passing a path targets one project folder and omitting it re-indexes every changed folder, which is valuable. It does not explicitly name the parameter or specify path format, leaving clear gaps.

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

Purpose4/5

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

The description states a specific verb and resource: 'Re-index one project folder (or every changed one) after edits.' This clearly identifies the operation and its scope. It does not distinguish itself from the sibling kb_rebuild, leaving the agent to infer the difference between incremental re-indexing and a full rebuild.

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

Usage Guidelines3/5

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

'After edits' implies the trigger condition, and 'Refused in readonly mode' gives one explicit exclusion. However, there is no explicit guidance on when to use this instead of kb_rebuild or other KB tools, so the agent must infer the alternative.

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

kb_remove_projectA
Idempotent

Remove a project folder from the knowledge base (index entries only; the files are untouched). Refused in readonly mode; audited (N127).

NameRequiredDescriptionDefault
pathYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations: it clarifies that only index entries are removed and files are untouched (the reason destructiveHint=false is safe), states a precondition (readonly-mode refusal), and discloses audit logging. That covers blast radius, permission/mode requirements, and traceability in one sentence.

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

Conciseness5/5

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

Two short sentences, front-loaded with the action and the crucial 'files untouched' qualifier before the secondary operational notes. No filler.

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 an output schema present and only one parameter, the description covers enough to call safely: blast radius, mode precondition, and auditing. The remaining gap is path-format expectations and no-op behavior for a path not present in the index.

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

Parameters3/5

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

Schema description coverage is 0% for the single 'path' parameter, so the description bears the burden and only implicitly indicates it is a project-folder path. It doesn't state format (absolute vs. relative, case sensitivity) or behavior when the path isn't indexed.

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

Purpose4/5

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

States a specific verb and resource ('Remove a project folder from the knowledge base') plus a scope-defining parenthetical that separates it from file deletion ('index entries only; the files are untouched'). It doesn't name the sibling to prefer for the alternative operation (e.g. kb_reindex/kb_add_project), but the resource is unambiguous.

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

Usage Guidelines3/5

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

The usage context is implied by the resource name, and 'Refused in readonly mode' gives one precondition. There is no explicit when-to-use guidance versus siblings such as kb_reindex or kb_rebuild, which also change index state.

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

kb_set_locationA
Idempotent

Choose the folder for the knowledge database — ONLY with a path the user gave you (or use_fallback=true once the user agreed to D:\TwinCAT-MCP\knowledge; not both). The folder is checked: a folder (not a file, not a drive root) on a local fixed drive (no network share / mapped drive / USB), not inside OneDrive/Dropbox/Google Drive/iCloud/Box, not inside the plugin folder, writable, >= 1 GB free — a failing condition is named and nothing is changed. An existing database is never moved or deleted. Without arguments it returns the current location (and changes nothing). A change is refused in readonly mode and audited, as every EDIT tool (N127).

NameRequiredDescriptionDefault
pathNo
use_fallbackNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by listing the full validation gauntlet (not a file/drive root, local fixed drive, no network/USB/cloud-sync paths, writable, >=1 GB free), the fail-safe 'nothing is changed', the guarantee that an existing database is never moved or deleted, and the readonly-mode refusal plus auditing. This is consistent with destructiveHint=false.

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 action and its primary constraint, and the validation list is compact. The heavy parenthetical packing and the internal reference 'N127' add density that a cold agent cannot decode.

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 two-optional-parameter mutation tool with an output schema available, everything an agent needs is present: usage gating, validation rules, failure semantics, mutation safety, and the no-arg read behavior. Return values need not be described since an output schema exists.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the parameter meaning — and it largely does: it explains path constraints in detail and defines use_fallback's target directory, its prerequisite (user agreement), and mutual exclusion with path. It is somewhat dense and run-on, but the semantics are meaningfully richer than the bare 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?

States a specific verb and resource — choose the folder for the knowledge database — and also discloses the no-argument read behavior (returns current location). No sibling tool performs this action, so an agent can distinguish it from kb_status, kb_reindex, or kb_rebuild without opening schemas.

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

Usage Guidelines5/5

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

Explicitly constrains invocation: use ONLY a path the user provided, or use_fallback=true after the user agreed to D:\TwinCAT-MCP\knowledge, and 'not both'. This is a genuine when/how condition rather than an implied usage.

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

kb_statusA
Read-only

Knowledge base (layout and rules: docs/KNOWLEDGE_BASE.md): where it is (or the question to ask the user if no folder was chosen yet), the project folders indexed for kb_search, the ESI index for hw_lookup — and under docs the documentation indexes the infosys_* tools and the twincat-docs skill read: index\infosys-.db (the one Infosys index) and index\manuals.db (PDF manuals, with the PDFs not in it yet), the SOPs, and the command that runs the skill's script on this folder. Each index: complete, or rebuild_needed / outdated (in use as it is until the user approves kb_rebuild), or a build running / interrupted. layout lists files the plugin no longer reads (never deleted by it) with their size.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior5/5

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

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds rich behavioral context: it explains index states (complete, rebuild_needed, outdated, build running/interrupted), notes that outdated indexes remain in use until the user approves kb_rebuild, and states that layout lists files the plugin no longer reads but never deletes. It also mentions the fallback behavior of returning a question to ask the user when no folder was chosen yet.

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

Conciseness3/5

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

The description is a single dense paragraph with nested parentheses, backtick paths, and many clauses. It is front-loaded with the purpose, but the amount of detail and lack of structural separation make it harder to scan than necessary, especially since an output schema already exists.

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?

Given the tool's complexity and the presence of an output schema, the description is complete enough for an agent to understand what status information is available. It covers location, indexed folders, multiple index types, index health states, layout details, and user-approval behavior, leaving no obvious contextual gap for invoking the tool correctly.

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

Parameters4/5

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

The tool has zero parameters, and the description does not need to explain any input parameters. The baseline score for a zero-parameter tool is 4, as the schema and description align without requiring additional parameter semantics.

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

Purpose4/5

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

The description identifies a specific resource (Knowledge base) and enumerates what the status covers: location, indexed project folders, ESI index, documentation indexes, SOPs, index states, and layout. It distinguishes this tool from siblings like kb_search and hw_lookup by making clear it reports status rather than performing search or rebuild actions. However, it never states a direct verb like 'reports' or 'returns' and relies on implication.

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

Usage Guidelines3/5

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

Usage is implied through the mention of index states and the need for user approval before kb_rebuild, but there is no explicit statement of when to call kb_status versus alternatives such as kb_search or kb_rebuild. The description provides context that helps an agent infer its role as a status-inspection tool, but no clear when-to-use or when-not-to-use guidance.

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

proj_call_graphA
Read-only

Call graph from a program/FB: FB instances it invokes, functions and methods it calls, recursively to depth (what runs when this POU runs).

NameRequiredDescriptionDefault
rootYes
depthNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the traversal is recursive and bounded by a depth limit, and it enumerates what kinds of callees appear (FB instances, functions, methods). It does not mention cost growth or truncation behavior at deep depths.

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?

A single tightly written sentence with the resource and output front-loaded and the depth constraint and use case appended. No filler; the trailing parenthetical is slightly redundant but earns its place by signaling intent.

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?

For a read-only, two-parameter query tool with an output schema already defining the return shape, the description covers what is computed and how deep it goes. The only material gap is the accepted format for `root` and the absence of any alternative-tool routing.

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

Parameters3/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 burden. It explains the semantics of `depth` (recursion bound) well, but it never clarifies what `root` must be – a POU name, a qualified symbol path, or something else – which is the required parameter. Partial compensation only.

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

Purpose4/5

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

The description names the resource precisely (a POU – program or function block) and the artifact produced (a call graph of invoked FB instances, functions and methods), which is distinct from sibling tools like proj_references or proj_interface. It does not explicitly name a sibling it is contrasted with, so it stops short of a 5.

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

Usage Guidelines3/5

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

The parenthetical 'what runs when this POU runs' implies the use case (static understanding of runtime reachability), but there is no explicit when-to-use statement and no guidance on when proj_references or proj_interface would be the better choice. Usage is inferable rather than stated.

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

proj_changedA
Read-only

Units whose source differs from a git revision (default: uncommitted work) plus untracked files — 'what did I change?'; pair with proj_vs_runtime for 'is it deployed?'.

NameRequiredDescriptionDefault
sinceNoHEAD

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered, and the description adds value beyond them: the default baseline is uncommitted work, and untracked files are included in the result set. It does not describe result shape, but the output schema exists to carry that.

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

Conciseness5/5

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

A single tight sentence with the core definition front-loaded and the sibling disambiguation appended. No filler, no repetition of the tool name.

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 one-parameter read-only tool with an output schema, the description covers scope, default behavior, untracked-file inclusion, and the alternative tool. Nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry parameter meaning — and it partially does by explaining that the default corresponds to uncommitted work. However, it never clarifies what forms the 'since' argument accepts (commit SHA, branch, tag), which is the one thing an agent needs to vary it.

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 concrete resource and predicate: units whose source differs from a git revision, plus untracked files. It also names the sibling it is distinct from (proj_vs_runtime), so an agent can separate 'what did I change' from 'is it deployed' without opening schemas.

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?

Provides explicit selection context ('what did I change?') and routes to the alternative (proj_vs_runtime) for the deployment question. It stops short of stating when not to use it, but the intended scenario is unambiguous.

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

proj_get_codeB
Read-only

Source of an object ('FB_Valve', 'FB_Valve.Open', 'MAIN'): declaration/implementation with file line numbers, parsed VAR declarations, sub-items.

NameRequiredDescriptionDefault
nameYes
partNoboth
with_line_numbersNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the content returned (parsed VAR declarations, sub-items, line numbers), but since an output schema exists, this is redundant, and it says nothing about auth requirements or limitations. Adds modest value on top of the annotations.

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?

A single, dense sentence that front-loads the resource and packs in return-content details and name-format examples without filler. Slightly example-heavy but no wasted prose.

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

Completeness3/5

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

An output schema is present, so return values needn't be described, yet the description partly does so. The main gap is usage context and parameter guidance for a 0%-coverage schema; for a simple read-only getter with annotations, it is adequate but not complete.

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

Parameters3/5

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

Schema coverage is 0%, so the description carries the burden. It gives concrete examples for the required 'name' parameter ('FB_Valve', 'FB_Valve.Open') and its mention of 'declaration/implementation' and 'line numbers' loosely maps to the 'part' and 'with_line_numbers' parameters, but neither parameter is explicitly explained or its allowed values enumerated.

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

Purpose4/5

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

The description clearly states the tool returns the source (declaration/implementation) of a named object, with concrete examples like 'FB_Valve' and 'MAIN'. An agent can tell this fetches code rather than listing projects or reading raw files. It doesn't explicitly contrast with siblings like proj_read_file or proj_variables, but the verb+resource is specific.

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

Usage Guidelines2/5

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

No guidance on when to use this versus alternatives such as proj_read_file (raw file access), proj_variables, or proj_interface. The description states what is returned but never when to reach for it or what it is not suited for.

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

proj_interfaceB
Read-only

Public interface of an FB/program: inputs/outputs/in-out with types and comments, methods (access, signature), properties (get/set), actions, extends/implements.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value by disclosing the exact return shape (methods, properties, actions, inheritance), but says nothing about failure modes when a name is not matched, or whether inherited members are included.

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?

A single front-loaded sentence that leads with the resource and then lists returned categories compactly. The colon-plus-list structure is efficient, though the dense enumeration of return contents partially duplicates what the output schema already provides.

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

Completeness3/5

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

An output schema exists, so the description need not explain return values, and annotations cover safety, leaving the definition mostly self-sufficient. The unresolved gap is the 'name' argument's expected form, which is the one thing an agent must get right to call the tool successfully.

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

Parameters2/5

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

Schema description coverage is 0% for the single 'name' parameter. The description only implies the name refers to an FB/program; it never states the expected format (bare POU name vs. namespace-qualified path) or whether it must already exist in the project. With a low-coverage schema, the description should compensate and does so only minimally.

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

Purpose4/5

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

The description names a specific resource (the public interface of an FB/program) and enumerates exactly what is returned: inputs/outputs/in-out with types and comments, methods with access and signature, properties with get/set, actions, extends/implements. An agent can distinguish it from proj_get_code or proj_variables. However, it never names a sibling tool explicitly, so differentiation is inferential rather than stated.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance, and no alternatives are named despite the crowded proj_* family (proj_get_code, proj_variables, proj_references, proj_call_graph). Usage is only implied by the resource being described.

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

proj_librariesA
Read-only

Library versions (K3): every library reference of each PLC project — the version it asks for, the version it effectively resolves to on this PC ('*' = newest installed) and what is installed in TwinCAT's library repository. Flags a pinned version that is not installed. Reads the .plcproj and folder names only.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), yet the description adds real value beyond them: it defines the '*' marker semantic, states that resolved versions are evaluated against 'this PC', and discloses the inspection scope ('reads the .plcproj and folder names only'), which tells the agent the operation is cheap and non-invasive. No mention of ordering/pagination or failure behavior, keeping it short of a 5.

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?

Three tight sentences, front-loaded with the subject ('Library versions (K3)') then the detail, then scope constraints. The parenthetical marker definition is compact and earns its place. Slight density of parentheticals keeps it from a 5, but there is no wasted prose.

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?

A read-only, zero-parameter reporting tool with an output schema on file. The description supplies the only things the structured data cannot: what the returned fields mean (requested vs resolved vs installed) and the '*' convention, so an agent needs nothing further to call it correctly.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. The description implicitly confirms a no-argument, whole-project sweep ('every library reference of each PLC project'), which is consistent with the empty schema and leaves nothing ambiguous for the agent.

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 ('Library versions... every library reference of each PLC project') and enumerates the three distinct data points it reports: requested version, resolved version, and installed version. The scope note 'Reads the .plcproj and folder names only' cleanly separates it from heavier project-inspection siblings like proj_read_file or proj_scan.

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

Usage Guidelines3/5

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

Usage is implied by 'Flags a pinned version that is not installed' — an agent can infer this is the tool for diagnosing missing/pinned library mismatches. However, no sibling alternative is named (e.g. proj_references) and there is no explicit when-to-use vs when-not-to-use statement, so context must be inferred.

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

proj_lintA
Read-only

Static checks over one object or the whole project: unused locals, naming prefixes (override map via prefixes), undocumented VAR_INPUT/OUTPUT, TODO markers, REAL compared with =, VAR_INPUT assigned inside an FB, empty methods, GVL/ENUM without qualified_only, magic numbers, FB_init/FB_exit without SUPER^; OOP/safety: interface_contract (every member of each IMPLEMENTS interface present with matching signature — info, not error, when the interface or a base lives in a library), extends_cycle, abstract_instantiation, shadowed_member (method input/local hides an FB member), unsigned_loop (BY -1 or TO n-1 on an unsigned counter), new_delete (__NEW without __DELETE, target lacking enable_dynamic_creation). Deterministic and offline; the compiler (xae_build + xae_diagnostics) stays the authority. rules= subset to run.

NameRequiredDescriptionDefault
nameNo
rulesNo
prefixesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the added value here is the operational context: the analysis is deterministic and offline, and interface_contract results are downgraded to info rather than error when the interface or base lives in a library. That severity nuance is genuinely useful and is not derivable from annotations or schema.

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 core purpose is front-loaded in the first clause, and the long rule inventory is dense but each named rule helps an agent judge whether this tool will surface what it needs. The parenthetical and semicolon-heavy structure makes it read as a spec dump rather than a summary, costing some scannability.

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?

An output schema exists, so return-format detail is unnecessary, and the description covers scope, rule coverage, determinism, and the compiler-authority caveat. The remaining hole is the undocumented semantics of the `prefixes` map and the null/whole-project behavior of `name`, which an agent needs to call it correctly.

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

Parameters3/5

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

Schema description coverage is 0%, so the description has to carry all three parameters. It explains `rules` as a subset filter and gestures at `prefixes` as an 'override map', but never states the map's key/value shape (naming category to prefix list), and `name` is only implied by 'one object or the whole project' with no note that null means whole project. It partially compensates for the coverage gap without fully closing it.

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 ('static checks over one object or the whole project') and then enumerates the exact rule classes it fires, from unused locals to FB_init SUPER^. It also draws the boundary against the authoritative sibling analyzers (xae_build + xae_diagnostics), so an agent can place it among the proj_* tools 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?

'Deterministic and offline; the compiler (xae_build + xae_diagnostics) stays the authority' gives a clear when-to-use posture versus the build-based tools, and 'rules= subset to run' tells the agent how to narrow scope. It does not state sequencing (e.g., run before committing or before xae_build) or exclusions, so it stops short of explicit when-not guidance.

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

proj_listC
Read-only

List indexed objects. kind: PROGRAM | FUNCTION_BLOCK | FUNCTION | STRUCT | ENUM | UNION | ALIAS | GVL | INTERFACE | METHOD | PROPERTY | ACTION (case-insensitive).

NameRequiredDescriptionDefault
kindNo
limitNo
patternNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that kind values are case-insensitive; it says nothing about default limit behavior, pagination, or what 'indexed' implies (e.g., staleness vs. the live project). With annotations carrying the safety burden, this is a modest but real contribution.

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?

Two compact sentences with the primary action front-loaded and no filler. It errs toward under-specification rather than verbosity, but structurally it is tight and easy to parse.

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

Completeness2/5

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

An output schema exists, so return values need not be described. However, for a filtering/list tool with three parameters and 0% schema description coverage, leaving `pattern` and `limit` semantics undocumented is a significant completeness gap, and there is no guidance on result scope or relationship to sibling listers.

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

Parameters2/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 compensate, and it only partially does. It documents the value domain for `kind` (and usefully notes case-insensitivity), but `pattern` and `limit` — including the 500 default and what kind of matching `pattern` performs — are left completely unexplained in both schema and description.

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

Purpose4/5

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

States a specific verb+resource ('List indexed objects') and enumerates the domain of object kinds the tool operates over, which is genuinely helpful. It does not, however, distinguish itself from near-neighbors like proj_search, proj_scan, or ads_list_symbols, so an agent still has to infer which of these listing tools is correct.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all — no indication of when to prefer this over proj_search, proj_scan, or proj_references, and no prerequisites or scope notes. The agent gets a definition of the tool but no routing information.

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

proj_read_fileC
Read-only

Raw text of a project file (relative to project root or absolute).

NameRequiredDescriptionDefault
pathYes
max_charsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the path-resolution note but says nothing about the max_chars truncation behavior, error handling for missing files, or encoding, leaving the main non-obvious behavior undisclosed.

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?

A single tight sentence with the returned content front-loaded and zero filler. It is efficient, though the extreme brevity contributes to the gaps noted in the other dimensions.

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

Completeness2/5

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

An output schema exists so return values needn't be described. However, for a two-parameter tool with 0% schema coverage, omitting any mention of max_chars and its truncation semantics leaves the definition materially incomplete for correct invocation.

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

Parameters2/5

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

Schema coverage is 0%, so the description must carry parameter meaning. It clarifies the 'path' parameter (relative to project root or absolute), which is genuine added value, but the 'max_chars' parameter is completely absent from the description, leaving half the parameters undocumented.

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

Purpose4/5

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

The description names the resource (project file) and the returned form (raw text), and the parenthetical scoping 'relative to project root or absolute' tells the agent this differs from parsed-code siblings like proj_get_code. It is a noun phrase with no explicit verb, so the action is only implied, but the intent is unambiguous.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no routing to alternatives. With siblings like ipc_read_file and proj_get_code in the same space, the agent is left to infer why it would pick this tool over those.

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

proj_referencesC
Read-only

Where a type/object is instantiated (variables of that type) and mentioned.

NameRequiredDescriptionDefault
nameYes
max_hitsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that: no mention of search scope (whole project? single POU?), how results are bounded, or whether the lookup is exact or approximate.

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

Conciseness3/5

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

It is a single short fragment with no waste, so it is concise. But the terseness comes at the cost of under-specification rather than economy, and there is no structural front-loading of scope or constraints.

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

Completeness2/5

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

An output schema exists, so return values need not be described. Still, for a code-intelligence lookup with 0% parameter coverage and no scope or usage guidance, the definition is too thin for an agent to invoke it reliably.

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

Parameters2/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 compensate, and it does not. Neither 'name' (fully-qualified symbol? simple identifier?) nor 'max_hits' (default 200, truncation behavior) is explained anywhere.

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

Purpose3/5

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

The description does convey the concept of finding usages of a type/object ('where ... is instantiated ... and mentioned'), which is a find-references operation. However, it is a noun-phrase fragment with no verb and no differentiation from siblings like proj_search, proj_resolve_symbol, proj_variables, or proj_call_graph, so an agent cannot readily tell which lookup tool to pick.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., whether the project must be loaded/scanned first). Usage is only weakly implied by the fragment itself.

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

proj_resolve_symbolA
Read-only

Map an ADS symbol path (MAIN.fbFill.fbValve.bOpen) to the file:line where each hop is declared, following variable types through FB/STRUCT definitions. Hops inside a library type (Tc2_Standard.CTU.CV) are completed from the runtime's datatype table when the target is reachable. A first name declared in several PLC projects (MAIN in Plc1 and Plc2) is the one of the PLC project on the connected ADS port (AmsPort in the .tsproj).

NameRequiredDescriptionDefault
symbolYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavior: it follows variable types through FB/STRUCT definitions, resolves library-type hops from the runtime datatype table when reachable, and disambiguates duplicate first names by the connected ADS port. These are meaningful operational details not present in the annotations or schema.

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 front-loaded with the core mapping operation and then adds relevant caveats about library types and duplicate names. It is dense but each sentence contributes useful information; the unusual line breaks are cosmetic rather than wasteful.

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?

Given the tool's complexity, read-only annotations, and existing output schema, the description provides enough operational context for correct invocation. It does omit explicit sibling guidance and error/edge-case behavior when a symbol is not reachable, which keeps it from being fully complete.

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

Parameters4/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 parameter meaning. It provides a concrete symbol-path example (MAIN.fbFill.fbValve.bOpen) and explains the duplicate-name behavior tied to the ADS port, which gives useful semantics beyond the bare 'symbol' string field.

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

Purpose4/5

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

The description states a specific verb and resource: mapping an ADS symbol path to the file:line where each hop is declared, including FB/STRUCT traversal. It clearly distinguishes this from generic search tools by emphasizing per-hop declaration resolution, but it does not explicitly name or compare itself with siblings such as infosys_declaration or ads_symbol_info.

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

Usage Guidelines2/5

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

The description explains what the tool does but gives no explicit when-to-use, when-not-to-use, or named alternatives. An agent can infer that it is for declaration-file lookup, but there is no guidance on choosing it over sibling tools like proj_search, infosys_search_symbols, or ads_symbol_info.

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

proj_scanB
Read-only

Index the project tree (.sln/.tsproj/.plcproj/.TcPOU/.TcDUT/.TcGVL/.TcIO). incremental=true re-indexes only files whose mtime changed (fast after XAE saves).

NameRequiredDescriptionDefault
rootNo
incrementalNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: incremental mode re-indexes only files whose mtime changed. It does not disclose re-index cost, whether the index persists across calls, or whether a full scan is needed on first use.

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?

Two tight sentences, front-loaded with the core action and followed by the incremental-mode detail. Nothing is padded, though the parenthetical file-type list is dense and the second sentence could be clearer about what triggers the mtime check.

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

Completeness3/5

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

An output schema exists, so return structure need not be explained. However, for a tool with an unexplained optional root parameter and many proj_* siblings, the description omits whether scanning is a prerequisite step and how it relates to proj_list/proj_search, leaving meaningful gaps.

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

Parameters3/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 the load. It does explain incremental well ('re-indexes only files whose mtime changed'), but the root parameter is never mentioned, and its null default leaves it unclear whether null means the currently open solution or the working directory.

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

Purpose4/5

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

States a specific verb and resource ('Index the project tree') and enumerates the artifact types it covers (.sln/.tsproj/.plcproj/.TcPOU/.TcDUT/.TcGVL/.TcIO), so the agent knows exactly what is being parsed. It does not however distinguish itself from siblings like proj_list, proj_search, or proj_changed, leaving the agent to infer the relationship.

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

Usage Guidelines3/5

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

The note that incremental=true is 'fast after XAE saves' implies when the incremental mode is appropriate, which is useful situational guidance. There is no explicit statement of when to run proj_scan versus proj_search/proj_get_code, nor whether a scan is a prerequisite for those tools.

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

proj_set_codeA
Idempotent

Write declaration/implementation back into the .TcPOU/.TcDUT/.TcGVL file (keeps the rest of the XML byte-identical, writes a .bak, drops the object's stale ). Use when XAE is closed or for batch edits; otherwise prefer xae_pou_set. Written also while the attached XAE has the project open — the result then says what that means (xae_open).

NameRequiredDescriptionDefault
nameYes
declarationNo
strip_lineidsNo
implementationNo
regenerate_lineidsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already establish readOnly=false, idempotent=true, and destructive=false, but the description adds important side effects beyond that: preserving the rest of the XML byte-identically, writing a .bak file, dropping stale <LineIds>, and reporting xae_open when the attached XAE has the project open. These are exactly the behavioral details an agent needs before invoking a file mutation.

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 key purpose is stated first, followed by side effects and sibling routing, so the structure is front-loaded. The parenthetical side-effect list is dense but still earns its place; the only minor weakness is that the final sentence about XAE-open behavior is slightly awkward.

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

Completeness3/5

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

An output schema exists, so return values do not need full explanation in the description. However, for a 5-parameter mutation with 0% schema description coverage, the missing parameter semantics leave a meaningful gap despite strong behavioral disclosure.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only partially compensates by mentioning declaration/implementation and stale <LineIds>. It does not explain the required name parameter, the optional null behavior, or the distinction between strip_lineids and regenerate_lineids, leaving several parameters undocumented in both places.

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 description names a specific mutation verb and resource: writing declaration/implementation back into .TcPOU/.TcDUT/.TcGVL files. It also distinguishes the tool from xae_pou_set by saying when that sibling is preferred, so an agent can identify the tool without opening the schema.

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

Usage Guidelines5/5

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

It gives explicit routing guidance: use when XAE is closed or for batch edits, otherwise prefer xae_pou_set. This names both the qualifying condition and the alternative tool directly.

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

proj_validate_xmlA
Idempotent

Structural validation of .TcPOU/.TcDUT/.TcGVL files: XML well-formedness, Name/Id, GUID format + project-wide uniqueness, Declaration/Implementation presence, property accessor VAR blocks, LineIds vs implementation line counts, EOF newline. fix=true applies safe fixes (.bak written); regenerate_lineids rebuilds LineIds blocks.

NameRequiredDescriptionDefault
fixNo
nameNo
regenerate_lineidsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare mutation (readOnlyHint=false), non-destructive behavior (destructiveHint=false), and idempotency (idempotentHint=true). The description adds concrete mutation context: fix=true applies safe fixes with .bak written, and regenerate_lineids rebuilds LineIds blocks. It could state whether regenerate_lineids also writes backups, but it adds meaningful detail beyond annotations.

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

Conciseness5/5

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

One dense sentence enumerates the validation checks, followed by a second sentence covering the two mutation flags. The purpose is front-loaded and no word appears wasted.

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?

For a multi-check validation tool with an output schema and annotations, the description covers validation scope and primary flags adequately. It leaves unclear how name selects files and whether regenerate_lineids creates backups, but those gaps are minor given structured fields cover return values and safety.

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

Parameters3/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 parameter meaning. It explains fix=true and regenerate_lineids behavior well, but the name parameter is never mentioned, leaving one of three parameters unexplained. Partial compensation for low coverage.

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 (structural validation) and resource (.TcPOU/.TcDUT/.TcGVL files), then enumerates the exact checks (XML well-formedness, GUID uniqueness, LineIds, EOF newline, etc.). This is specific enough to distinguish it from code-oriented siblings like proj_lint or proj_scan, even though it does not name them.

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

Usage Guidelines2/5

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

No when-to-use guidance, prerequisites, or named alternatives are provided; it only describes capabilities. An agent must infer that this is the tool for structural XML checks on those file types, with nothing telling it whether to prefer proj_lint or when validation is appropriate.

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

proj_variablesA
Read-only

Every variable the project source declares, flattened to runtime instance paths by walking programs and GVLs through FB/STRUCT definitions (MAIN.fbFill.fbValve.bOpen …). scope = one program/GVL/FB to walk instead of all. Library-typed variables stay as one item with their type. A name declared in several PLC projects is walked in the PLC project on the connected ADS port (the .tsproj's AmsPort); pin another with '@'.

NameRequiredDescriptionDefault
scopeNo
max_arrayNo
max_itemsNo
include_tempNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description still adds real behavioral context: how the walk traverses FB/STRUCT nesting, that library-typed variables are collapsed to a single item, and how duplicate names across PLC projects resolve against the connected ADS port. It omits output-size/truncation behavior tied to max_items and max_array, which would have completed the picture.

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 core definition in the first sentence, followed by scope and then the collision-resolution edge case. Dense but every sentence carries information; the awkward line wrapping slightly hurts readability but wastes nothing.

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 an output schema present, return-value explanation is unnecessary, and annotations cover the safety profile. The description covers the semantics an agent needs to call this correctly — what gets flattened, how scope narrows it, and how name collisions resolve — leaving only the three numeric/boolean knobs undocumented.

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

Parameters3/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. It explains `scope` well (single program/GVL/FB, or 'PLCproject@name' pinning), but says nothing about `max_array`, `max_items`, or `include_temp`, all of which are non-obvious (array expansion cap, item cap, temp variable inclusion). Partial compensation only.

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

Purpose4/5

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

States a precise verb and resource: enumerate every variable declared in project source, flattened to runtime instance paths by walking programs/GVLs through FB/STRUCT definitions. The example path (MAIN.fbFill.fbValve.bOpen) plus the note about library-typed variables makes the output shape unmistakable. It never names a sibling (e.g. ads_list_symbols, proj_get_code), so differentiation is implicit rather than explicit.

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

Usage Guidelines3/5

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

Usage is implied through the parameters: 'scope = one program/GVL/FB to walk instead of all' and the '<PLC project>@<name>' pinning syntax tell an agent how to narrow or disambiguate. But there is no explicit when-to-use/when-not guidance relative to alternatives such as runtime symbol listing or symbol resolution, so the agent must infer the choice.

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

proj_vs_runtimeA
Read-only

Cross-check the source against the running PLC: variables declared in the project but not present online (not compiled / not activated / optimised away) and online variables under the same programs/GVLs that the source does not declare (stale boot project, library internals); roots_not_on_target names a program/GVL of which the target has no symbol at all, with the cause (a GVL nothing references is not linked). Use after a deploy to prove the target runs this source.

NameRequiredDescriptionDefault
scopeNo
max_itemsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond that by explaining the causal categories behind each mismatch (not compiled / not activated / optimised away, stale boot project, library internals) and noting that roots_not_on_target carries a cause, which helps an agent interpret results.

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

Conciseness3/5

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

Purpose is front-loaded, but the first sentence is a long run-on with three nested parentheticals, which slows parsing. Information is dense and largely earns its place, yet could be split for clarity.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and the purpose/usage story is complete. However, for a tool with two undocumented parameters at 0% schema coverage, the description leaves a real gap about how to scope the cross-check.

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

Parameters2/5

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

Schema description coverage is 0% and neither of the two parameters is mentioned in the description. 'scope' (presumably a program/GVL filter) and 'max_items' are left entirely undefined, so an agent gets no guidance on how to narrow the comparison or bound output.

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

Purpose4/5

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

The description names a specific verb ('cross-check') and both resources (source project vs running PLC), and enumerates exactly what discrepancies it surfaces: declared-but-not-online, online-but-not-declared, and roots_not_on_target. It is distinguishable from most siblings, though it never names the obviously related hmi_vs_runtime or ads_list_symbols to sharpen the contrast.

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?

'Use after a deploy to prove the target runs this source' gives a clear triggering context. It stops short of explicit when-not conditions or naming alternative tools (e.g. ads_list_symbols) for related symbol questions.

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

rec_captureA
Idempotent

One call for "record X for N s and give me the stats": starts a recording, waits (≤ 60 s), stops, and returns per-symbol statistics, completeness and the rec_verify verdict (integrity + PLC timeline, plus the optional per-cycle counter) with the file path. For longer or triggered captures use rec_start.

NameRequiredDescriptionDefault
modeNocycle
engineNo
prefixNo
counterNo
secondsNo
symbolsNo
cycle_msNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, which the description does not contradict. Beyond that, the description adds real behavioral detail: the built-in wait capped at 60 s, the returned artifacts (per-symbol statistics, completeness, integrity/PLC timeline verdict, file path), and the optional per-cycle counter — information the annotations cannot convey.

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?

Two sentences, front-loaded with the operation and its return payload, with the routing advice last. Dense but every clause carries information; no filler.

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

Completeness3/5

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

An output schema exists, so return values need not be spelled out, and the description sensibly summarizes them anyway. The gap is parameter-level: five of seven inputs are unexplained, which is a meaningful omission for a tool whose schema gives no guidance.

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

Parameters2/5

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and largely does not. It clarifies only the `counter` parameter ('optional per-cycle `counter`') and implies `seconds` via 'for N s'; mode, engine, prefix, symbols, and cycle_ms remain entirely undocumented in both schema and description.

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 description states a concrete composite operation — start, wait (≤60 s), stop, and return per-symbol stats plus a rec_verify verdict and file path — using a specific verb and resource. It explicitly contrasts itself with the sibling rec_start, so an agent can differentiate without opening either schema.

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

Usage Guidelines5/5

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

It names the alternative (rec_start) and the precise condition that selects it: 'For longer or triggered captures use rec_start.' That routes the agent correctly between the two recording entry points.

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

rec_compareA
Read-only

Before/after comparison of two recordings: per-symbol stat deltas (count, min, max, mean, changes, edges) and pulse width/period deltas for BOOLs — timing regression after a code change.

NameRequiredDescriptionDefault
id_aYes
id_bYes
symbolsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds output-oriented context (stat deltas, pulse deltas) and a use case, but it omits behavioral constraints such as whether recordings must share configuration or any permission/rate-limit considerations.

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

Conciseness5/5

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

The description is a single dense sentence that front-loads the operation, then appends output details and the use case. No filler or repetition is present.

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

Completeness3/5

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

The output schema covers return values and annotations cover the safety profile, so those gaps are not severe. The remaining incompleteness is in parameter semantics and comparison prerequisites, which the description does not address.

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

Parameters2/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 explain the parameters. It does not map id_a/id_b to before/after recordings or clarify that symbols is an optional filter, leaving the parameter meaning largely to inference.

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

Purpose4/5

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

The description states a specific comparison operation over two recordings and enumerates the produced deltas (per-symbol stats, pulse width/period for BOOLs). It clearly differentiates from generic recording tools by focusing on before/after timing regression, though it does not explicitly name sibling alternatives such as snap_compare or exp_compare.

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?

It gives a clear triggering context: timing regression after a code change. However, it does not state when not to use it or point to alternative comparison tools, so the routing guidance is incomplete.

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

rec_deleteA
Destructive

Stop (if running) and delete a recording and its exports from disk. Destructive-class (field report R11): a recording is evidence — guarded mode needs tc_request_confirmation(action='rec_delete', target=); the audit keeps the deleted file's size and SHA-256 so its content stays identifiable.

NameRequiredDescriptionDefault
idYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds rich context beyond them: that it stops a running recording first, that exports are also removed, the confirmation gate required in guarded mode, and that the audit retains size and SHA-256 for identifiability. That is genuine behavioral disclosure an agent needs.

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 action, then the destructive-class and confirmation detail. Every clause adds material information; it is a bit dense but not padded.

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?

For a destructive mutation tool with an output schema present, the description covers scope, side effects, confirmation requirement, and audit retention. The only shortfall is that neither the description nor the schema explains the confirm_token parameter.

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

Parameters3/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 parameter meaning. It references the id (via target=<id>) and the confirmation flow, which maps to confirm_token, but never names or explains confirm_token directly nor its format. Partial compensation leaves a gap.

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 (delete) and resource (a recording and its exports on disk), plus the side behavior 'stop (if running)'. This clearly distinguishes it from the sibling rec_stop, which only halts a recording. An agent can select it without opening the 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?

It specifies the guarded-mode prerequisite explicitly: tc_request_confirmation(action='rec_delete', target=<id>). This gives a clear when-to-use workflow, though it doesn't state when NOT to use it versus alternatives like rec_stop or rec_profile_delete.

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

rec_exportA
Read-only

Export a recording to CSV. csv_wide: one row per PLC sample time, one column per variable and per array element (name[i]); an empty cell means no sample of that variable at that time (fill=true forward-fills — handy for charts, but a cell then no longer means "sampled now"). csv_long: t_ms,symbol,value. Both include plc_filetime (the PLC's own sample timestamp) when available. Default path next to the JSONL. An out_path must be in a folder this server writes to ([server] output_dirs adds more). An existing file — also an earlier export at the default path with other symbols/fill, or of a recording that has grown since — is only replaced with overwrite=true; an identical re-export (same source bytes and parameters) is not refused.

NameRequiredDescriptionDefault
idYes
fmtNocsv_wide
fillNo
symbolsNo
out_pathNo
overwriteNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior5/5

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

With annotations already declaring readOnlyHint and destructiveHint=false, the description still adds substantial behavioral context: default output location, the output_dirs restriction on out_path, that existing files (including earlier exports or grown recordings) are only replaced with overwrite=true, and that an identical re-export is idempotently not refused. The empty-cell/fill semantics and plc_filetime caveat are also behavior, not schema.

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 purpose leads and every subsequent clause carries information, but it is a dense run-on paragraph mixing format semantics, path rules, and overwrite rules with a chatty aside ('handy for charts, but...'). Slightly tighter structure would improve scanability.

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?

For a 6-parameter tool with 0% schema coverage and an output schema (so return values need not be described), the description covers formats, fill behavior, timestamps, path safety, and overwrite/idempotency. The remaining gap is the symbols and id parameters, whose semantics an agent must still infer.

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

Parameters4/5

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

Schema coverage is 0%, so the description carries the burden, and it explains fmt (csv_wide vs csv_long layouts), fill, out_path constraints, and overwrite semantics well beyond the bare schema. It is weaker on 'symbols' (only implied by 'other symbols/fill') and 'id', which are never characterized as a recording identifier.

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 first sentence states a specific verb and resource ('Export a recording to CSV'), which distinguishes it from sibling exporters such as scope_export or ads_export and from rec_read/rec_snapshot. An agent can identify the operation without opening the 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?

It explains the choice between the two formats, when fill=true is helpful (charts) and its pitfall, and the conditions under which out_path/overwrite are needed. It does not, however, name the alternative tools (rec_read, rec_snapshot) for agents who want data without a CSV file.

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

rec_latencyA
Read-only

Edge-to-edge latency in a recording: from each time from_symbol from_op from_value becomes true to the next time to_symbol to_op to_value becomes true (PLC timestamps). E.g. bOpenCmd == TRUE → rFlow > 0.5.

NameRequiredDescriptionDefault
idYes
to_opYes
from_opYes
to_valueYes
max_pairsNo
to_symbolYes
from_valueYes
from_symbolYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context beyond annotations: it defines the measured interval as from the first condition becoming true to the next condition becoming true and specifies PLC timestamps. It does not describe pair limits or no-match behavior, but the core computation is well disclosed.

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

Conciseness5/5

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

Two sentences, front-loaded with the core computation and followed by a compact example. No wasted wording, and the example directly clarifies the parameter syntax.

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

Completeness3/5

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

The core latency logic is clear, and the output schema means return values need not be described. However, the description omits when to use this tool versus recording siblings, does not mention `id` or `max_pairs`, and does not state prerequisites such as an existing recording. These gaps make it only adequately complete at 0% schema description coverage.

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

Parameters4/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 the burden. It explains the `symbol op value` structure for six required condition parameters and gives an example for `==` and `>`. It does not explain `id` or `max_pairs`, but it compensates well for most parameters.

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

Purpose4/5

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

States a specific computation (edge-to-edge latency between two PLC conditions) and gives a concrete example. An agent can distinguish it from raw recording tools, but the description does not explicitly differentiate it from siblings such as rec_pulses or rec_compare.

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

Usage Guidelines2/5

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

Provides no when-to-use guidance, no alternatives, and no prerequisites such as requiring an active recording. Usage is only implied by 'in a recording,' leaving the agent to infer the appropriate scenario.

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

rec_listC
Read-only

Recordings of this session (compact status) and recording files on disk, newest first (paged: limit/offset; on_disk_total says how many exist); a recording with Scope: its scope state.

NameRequiredDescriptionDefault
limitNo
offsetNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: result ordering (newest first), pagination, and the presence of an 'on_disk_total' indicator. It does not, however, say what happens when offset exceeds the result set or how output is shaped, so it adds value but not rich context.

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

Conciseness3/5

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

It is a single compact sentence with no wasted preamble, which is good, but the parenthetical-and-semicolon structure is tangled and the final clause about Scope is not front-loaded or self-explanatory. Density comes at the cost of parseability.

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

Completeness3/5

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

An output schema exists, so return-value detail is not required, and the read-only annotations cover safety. What remains missing for a two-parameter, paged listing tool is basic pagination semantics and the minimal signal of when this list should be used versus the many other rec_* tools, leaving the definition adequate but incomplete.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters, so the description must compensate and largely doesn't: 'paged: limit/offset' merely restates the parameter names without clarifying units, defaults (30/0), maximums, or whether offset counts records or pages. The 'on_disk_total' mention describes an output field, not a parameter.

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

Purpose3/5

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

The description does convey a specific verb-and-resource combination (listing recordings of the current session plus recording files on disk, newest first), but the phrasing is muddled – the trailing clause 'a recording with Scope: its scope state' reads like a fragment and is hard to parse. It never names a sibling (rec_read, rec_status, rec_scan) to distinguish this list operation from them.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no exclusion of alternatives, and no mention of when an agent should prefer rec_list over rec_read, rec_status, or rec_scan. Usage is only inferable from the word 'list', which is the minimum, not guidance.

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

rec_profile_deleteC
Idempotent

Delete a profile and its checklist file.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.5/5.0
Behavior1/5

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

The description states a destructive action ('Delete a profile and its checklist file') while the annotations declare destructiveHint=false, directly contradicting the declared safety profile. No other behavioral context (permissions, irreversibility, whether the profile must be stopped first) is given to offset this.

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?

One short, front-loaded sentence with no filler. It is efficient, though the brevity is partly the cause of the missing usage and parameter detail.

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

Completeness2/5

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

An output schema exists, so return values need not be described, but the description omits essential context for a deletion tool: profile identity semantics, interaction with checklist files, prerequisites, and reverting. Combined with the annotation conflict, it is not sufficient to call the tool safely.

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

Parameters2/5

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

The single 'name' parameter has 0% schema description coverage, so the description must compensate and does not. It never clarifies that 'name' identifies the profile, how it is matched (exact/case-sensitive), or how it relates to the checklist file being removed.

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

Purpose4/5

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

The description names a specific verb (Delete) and resource (a profile and its checklist file), which is clearer than the bare name. However, it does not distinguish itself from the sibling rec_delete (and from rec_profile_save/list/get/start/stop), leaving the agent to infer that this tool only operates on profiles.

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

Usage Guidelines2/5

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

There is no when-to-use, when-not-to-use, or alternative guidance. With siblings like rec_delete and rec_profile_save/get/list present, the description should state whether this is the profile-lifecycle delete versus the recording delete, but it offers nothing.

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

rec_profile_getB
Read-only

One profile in full: every symbol with its mode and cycle, triggers, per-group cost estimate.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful content-shape context (modes, cycles, triggers, cost estimates), but says nothing about behavior such as failure when the profile name is unknown or whether the result is live or from the last recorded run.

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?

A single tight sentence with no filler, front-loaded with the resource. It is a verbless fragment, which is efficient but slightly less scannable than a full clause.

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

Completeness3/5

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

An output schema exists, so return values need not be re-explained, and the safety profile is covered by annotations. However, with the sole parameter undocumented and no routing guidance against the profile siblings, the definition is only adequate for correct invocation.

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

Parameters2/5

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

There is one parameter, 'name', with 0% schema description coverage, and the description never mentions it. The agent must guess whether it is the profile name from rec_profile_list, a file path, or something else.

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

Purpose4/5

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

States a specific resource ('one profile in full') and enumerates what comes back (symbols with mode and cycle, triggers, per-group cost estimate), which separates it from rec_profile_list (collection) and rec_profile_delete (mutation). It is clear what the tool does, though the verb 'get' is only implied by the name rather than stated.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer you call this when you need the full detail of a single named profile rather than a listing. No alternative is named and no prerequisite (e.g., the profile must already exist from rec_profile_save) is stated.

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

rec_profile_listC
Read-only

Saved capture profiles (name, symbol count, modes, source).

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds only the word 'Saved' plus output fields that the output schema already provides. It discloses no ordering, pagination, or auth behavior beyond the safety profile.

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?

One short, front-loaded phrase with no filler, though it is a sentence fragment rather than a complete action statement. It is appropriately sized for a simple zero-param listing tool.

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

Completeness3/5

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

The output schema covers return fields and annotations cover read-only safety, so the description need not explain results. However, it never states the operation or how it differs from adjacent profile tools, which is a meaningful gap for selection.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to clarify; per the rubric this yields a baseline of 4. The parenthetical field list refers to returned data, not inputs.

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

Purpose3/5

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

States the resource ('Saved capture profiles') and the returned fields, but uses a noun phrase with no verb, so it never explicitly says it lists them. An agent can infer the action from the tool name and siblings, but the description itself does not distinguish 'list' from 'get' or 'save'.

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

Usage Guidelines2/5

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

No when-to-use guidance, prerequisites, or alternatives are given. It does not mention rec_profile_get, rec_profile_save, or rec_profile_delete, leaving the agent to infer that this is the unfiltered list operation.

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

rec_profile_saveA
Idempotent

Save a named capture profile. Sources combine: explicit symbols (mode='auto' picks cycle for REAL/TIME, change for BOOL/INT/enum, poll for strings — or give cycle|change|poll), a marked checklist (path, or the name given to rec_scan), and/or {attribute 'tcmcp.record' := 'cycle'} pragmas in the source (from_attributes=true; scope limits to one program). Triggers and the default cycle are stored with the profile. rec_profile_start(name) replays it.

NameRequiredDescriptionDefault
modeNoauto
nameYes
scopeNo
replaceNo
symbolsNo
cycle_msNo
stop_whenNo
duration_sNo
start_whenNo
descriptionNo
from_checklistNo
pre_trigger_msNo
from_attributesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral detail about source combination, mode='auto' selection rules, and that triggers/default cycle are stored, but it omits what happens to an existing profile with the same name when replace defaults to true.

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 front-loaded with the main action and packs a lot of technical detail into one dense paragraph. It is not wasteful, though the parenthetical syntax makes it less scannable than a bulleted breakdown would be.

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

Completeness2/5

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

For a 13-parameter tool with 0% schema description coverage, the description is incomplete: several parameters and the replace/overwrite behavior are not explained. An output schema exists and annotations cover safety, but the description still leaves important invocation details to inference.

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

Parameters2/5

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

Schema description coverage is 0% with 13 parameters, so the description must compensate. It explains mode, symbols, from_checklist, from_attributes, and scope, but leaves replace, duration_s, start_when, stop_when, pre_trigger_ms, description, and cycle_ms (beyond 'default cycle') undocumented.

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: 'Save a named capture profile.' It distinguishes itself from siblings by naming rec_profile_start for replay and rec_scan as a source for checklists, so an agent can tell what this tool is for.

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?

Explains how source selection works and points to rec_scan for checklist names and rec_profile_start for replay. It does not explicitly state when to use this instead of directly starting a recording, but the context is clear enough for selection.

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

rec_profile_startB
Idempotent

Start recording a saved profile: one recording per (mode, cycle_ms) group, all named '/@'. Triggers given here override the profile's. Returns the recording ids; rec_profile_stop(name) stops them together, rec_stats/rec_export work per id. align (default, several groups, no start_when): every group starts on the same PLC cycle — a shared start trigger on the task's cycle counter a moment ahead — and duration_s then counts from that cycle, so all files cover the same window (D29: groups started ≈ 160 ms apart).

NameRequiredDescriptionDefault
nameYes
alignNo
stop_whenNo
duration_sNo
max_eventsNo
start_whenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior4/5

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

Annotations only supply the safety profile (readOnly=false, idempotent=true, destructive=false), so the description earns credit for adding real behavior: triggers supplied here override the profile's, the return value is recording ids, and the align mode coordinates a shared start cycle across groups so all files cover the same window (even citing the D29 ~160 ms observation). It omits failure/edge behavior — e.g. what happens if the profile is unknown or a recording is already running.

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

Conciseness3/5

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

Purpose and the naming/grouping rule are front-loaded, which is good, but the second sentence is a dense run-on whose parenthetical '(default, several groups, no start_when)' is cryptic and does more work than it can bear. Most sentences earn their place, yet the align explanation could be far tighter for the same information.

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

Completeness3/5

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

An output schema exists, so return values needn't be detailed (though it does mention returning ids). The real gap is coverage of a 6-parameter mutation-ish tool at 0% schema description: three parameters and all error/permission behavior are undocumented. Given the tool's complexity, the description is a useful but incomplete operating manual.

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

Parameters2/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 only partly delivers. It explains align (default, meaningful only with several groups and no start_when) and gives duration_s meaning under align, and it references start_when in passing. The required param name, plus stop_when and max_events (default 5,000,000), get no explanation at all, leaving three of six parameters opaque.

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

Purpose4/5

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

States a specific verb+resource ('Start recording a saved profile') and adds distinctive detail: one recording per (mode, cycle_ms) group with the naming pattern '<profile>/<mode>@<cycle>'. An agent can tell this apart from ad-hoc rec_start. It stops short of explicitly contrasting itself with the sibling rec_start, which is the only thing keeping it off a 5.

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

Usage Guidelines3/5

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

It names the complementary tools ('rec_profile_stop(name) stops them together, rec_stats/rec_export work per id'), which routes the agent for follow-up calls and implies the lifecycle. However, it never says when to prefer this over sibling rec_start or rec_capture, nor any prerequisite (e.g. a saved profile must already exist). Usage is implied rather than stated.

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

rec_profile_stopA
Idempotent

Stop every live recording started from this profile; returns per-recording status + stats.

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the scope ('every live recording from this profile') and a return hint, but does not disclose behavior when no live recordings exist or what stats are returned.

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?

A single compact sentence, front-loaded with the verb and scope, then the return hint. No wasted words, though the semicolon clause is slightly compressed.

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 only one parameter, an output schema covering return values, and annotations covering the safety profile, the description supplies the remaining essentials (scope, return hint). It is nearly sufficient, missing only explicit param format and failure behavior.

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

Parameters3/5

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

Schema description coverage is 0% for the single 'name' parameter, so the description carries the burden. 'From this profile' weakly implies name is a profile identifier, adding marginal meaning beyond the bare string schema, but the format/expectation is still not pinned down.

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

Purpose4/5

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

Specific verb ('Stop') + resource ('every live recording started from this profile'), with a scope qualifier that distinguishes it from the plain rec_stop sibling. It stops short of explicitly naming the alternative tool, so the differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

Usage is implied by 'started from this profile' and 'live recording', but there is no explicit when-to-use guidance versus rec_stop or rec_profile_start, and no stated conditions or exclusions.

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

rec_pulsesB
Read-only

Pulse / dwell analysis of one recorded symbol: for BOOL → pulse count, high/low widths, period, frequency, duty (fine-dosing valve pulses); for other types → state timeline with dwell times.

NameRequiredDescriptionDefault
idYes
symbolYes
max_listNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered without the description. The description adds genuine value by explaining the type-dependent output shape (pulse metrics vs. state timeline with dwell times), but says nothing about truncation, pagination, or how max_list affects results.

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 analysis scope is front-loaded in the opening clause, and the type-branched behavior is packed into one sentence with no filler. It is dense and readable, though the single long sentence could be split to make the two output modes easier to scan.

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

Completeness3/5

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

For a read-only analysis tool with an output schema present, the description adequately covers what is returned by symbol type. It is incomplete on inputs and preconditions — the meaning of 'id', the effect of 'max_list', and whether a recording must be active or finished are all left unstated.

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

Parameters2/5

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

Schema description coverage is 0% across three parameters, so the description carries the full burden and fails to meet it: it never explains what 'id' identifies, what 'symbol' must match, or what 'max_list' (default 200) truncates or controls. Only a loose hint that a single symbol is analysed is recoverable.

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

Purpose4/5

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

The description states a specific verb and resource ('Pulse / dwell analysis of one recorded symbol') and even branches the semantics by data type (BOOL → pulse metrics, others → state timeline with dwell times), so an agent knows exactly what it gets. It does not, however, contrast itself against nearby siblings such as rec_read, rec_stats or rec_latency, so differentiation relies on the name alone.

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

Usage Guidelines3/5

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

Usage is only implied: 'of one recorded symbol' hints that a recording must exist and that a symbol must be supplied, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer the recording prerequisite and cannot tell from the text whether this supersedes or complements rec_read/rec_stats.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_readB
Read-only

Read a time window of a recording from its file. wide=true: one row per PLC timestamp with one column per selected symbol; a cell is null when that symbol has no sample at that time — nothing is invented (R4). fill=true repeats the last known value into those cells and lists them per row under "_filled" (handy for 'what else was true when X happened', but a filled cell is not a sample). Works on finished recordings from earlier sessions too.

NameRequiredDescriptionDefault
idYes
fillNo
wideNo
symbolsNo
t_to_msNo
max_rowsNo
t_from_msNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint/destructiveHint; the description goes further by disclosing output shape (one row per PLC timestamp, one column per symbol), the null-cell semantics when a symbol has no sample, and the caution that a filled cell is not a sample. This is meaningful behavior beyond the annotations, though auth/rate/size limits are untouched.

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 core action, then progressively explains wide and fill. The wide/fill sentence is dense but every clause conveys real behavior; little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be explained, and the mode semantics are well covered. But with 7 params at 0% schema coverage, the absence of any documentation for the time-window and symbol-selection parameters leaves gaps an agent must guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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, yet it only explains fill and wide out of 7 parameters. Critical filters like id, symbols, t_from_ms, t_to_ms, and max_rows receive no semantic explanation anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope: "Read a time window of a recording from its file." This clearly separates it from control siblings like rec_start/rec_stop and from rec_export or rec_list. It stops short of explicitly naming an alternative sibling, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It offers contextual guidance for the fill mode ("handy for 'what else was true when X happened'") and notes it works on finished recordings from earlier sessions. However, it never says when to reach for rec_read versus rec_export, rec_capture, rec_snapshot, or ads_read, so the agent must infer the routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_scanA
Read-only

Enumerate the variables that could be recorded and what each would cost. source='runtime' walks the live symbol/datatype tables (every scalar leaf under prefix, or all programs/GVLs); source='project' walks the source declarations (works offline). pattern selects leaves exactly as rec_start does: '*'/'?' wildcards, '[ ]' literal, a leaf matches when it or a parent matches. Returns counts by type and by group (program.instance) with bytes/s estimates at cycle_ms, a suggested mode per leaf, and — when checklist='' — writes ~/.twincat_mcp/profiles/.checklist.csv with a 'select' column to mark (preselect = patterns already marked). Then rec_profile_save(name, from_checklist=name).

NameRequiredDescriptionDefault
showNo
prefixNo
sourceNoruntime
patternNo
cycle_msNo
checklistNo
max_itemsNo
preselectNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, yet the description states the tool 'writes ~/.twincat_mcp/profiles/<name>.checklist.csv' when checklist='<name>'. Creating a file on disk is an environment modification, which directly contradicts the read-only annotation. The description is otherwise rich, but the rubric requires a 1 for an annotation 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?

Purpose and mode selection are front-loaded, and nearly every clause carries new information (match rules, return contents, side effect, next step). The single dense paragraph with em-dashes and parentheticals is harder to parse than it needs to be, which keeps it from a 5.

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?

For an 8-parameter tool it covers return shape (counts by type/group, bytes/s estimates, suggested mode), the conditional file side effect, and the downstream call. An output schema does exist so return values need not be restated. Gaps remain: the show and max_items parameters, and the read-only annotation is not reconciled with the disclosed write.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description has to carry the parameters, and it does for most: source (runtime vs. project semantics), pattern (wildcard syntax identical to rec_start, parent/leaf match rule), cycle_ms (drives the bytes/s estimate), checklist, preselect, and prefix ('every scalar leaf under prefix'). It leaves show and max_items unexplained, so it is strong but not exhaustive.

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 opening sentence names a specific verb and resource ('Enumerate the variables that could be recorded') and immediately explains the two operating modes: runtime symbol-table walk vs. project source-declaration walk. This lets an agent tell it apart from siblings like ads_leaves, proj_variables, and rec_list without opening any 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?

It gives a selection criterion between the two sources ('project' works offline) and a follow-on workflow (write checklist, then rec_profile_save(name, from_checklist=name)). It does not explicitly say when to prefer this over rec_start, rec_list, or ads_leaves, so there is no when-not guidance, but the context provided is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_snapshotC
Read-only

Most recent events of a running (or finished) recording — the live tail.

NameRequiredDescriptionDefault
idYes
last_nNo
symbolsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool works on running or finished recordings and returns a 'live tail,' which is useful context beyond annotations, but it does not cover pagination, rate limits, or output behavior (which the output schema may address).

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 a single front-loaded sentence with no filler or repetition. It is efficiently sized for its content, though the extreme brevity contributes to gaps in parameter and usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one required and two optional parameters with 0% schema description coverage, and the description does not compensate for any of them. The output schema covers return values and annotations cover safety, but the description omits essential input semantics and any usage context, making the definition incomplete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and three parameters (id, last_n, symbols) are present, yet the description mentions none of them. It adds no meaning about the required recording id, the last_n limit, or the symbols filter, leaving every parameter undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope — most recent events of a recording, described as a live tail. It clearly conveys what data the tool returns, but it does not distinguish itself from sibling tools such as rec_read, rec_list, or rec_stats, leaving the agent to infer the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance or comparison to alternatives. The phrase 'running (or finished) recording' and 'live tail' imply a live monitoring context, but the description never says when to choose this over rec_read, rec_list, or rec_status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_startA
Idempotent

Start a continuous real-time recording of online PLC variables (runs in the background until rec_stop, duration_s, max_events or stop_when). Select by explicit symbols (an FB or struct instance expands to all its leaves), prefix ('MAIN.fbFill', 'GVL_Sim.aCh[1]' → every leaf under it) or pattern — the same leaves rec_scan lists for it: ''/'?' wildcards, '[ ]' literal ('GVL_Sim.aCh[1].'), a leaf is recorded when it or one of its parents matches ('*bOpen' → every bOpen). mode: 'cycle' = one PLC-timestamped sample per symbol per cycle_ms (ADS notification, cycle-accurate); 'change' = PLC-timestamped sample only when the value changes (checked every cycle_ms); 'poll' = sum-read every cycle_ms from this PC. Triggers: start_when='MAIN.bStart == TRUE' with pre_trigger_ms keeps the events before the trigger (scope-style); stop_when='MAIN.fbFill.bDone == TRUE'. Events stream to a JSONL file. duration_s is PLC time from the first sample (also while waiting for start_when); post_trigger_s ends the recording that long after the start_when trigger fired (scope-style post-trigger window). Timestamps (cycle/change) are the TwinCAT runtime's own, stored exactly with the raw bytes it sent; neighbouring variables share ONE notification (a block), which is what keeps 1 ms recordings lossless — select whole FBs, structs or arrays rather than hundreds of scattered globals. Any notification that cannot be registered fails the start (allow_partial=true records the rest and lists unsubscribed_symbols). max_delay_ms > 0 lets the runtime batch samples (fewer ADS frames; each sample keeps its own timestamp). cycle mode also records a per-cycle counter as ground truth (cycle_counter='auto' = the matching task's _TaskInfo[n].CycleCount, or your own e.g. 'MAIN.nCycleCount', or null for none) and the header carries a manifest of what was recorded from (AppTimestamp, OnlineChangeCnt, tasks, TwinCAT build, symbol version). A recording is of one program: a download / online change while it runs ends it at the last sample verified against the symbol version (program_changed); nothing sampled from the new program is written. Conditions are levels: a start_when that already holds fires at once — edge_triggers=true fires only when it BECOMES true. A condition may name one element of an array recorded as a whole (GVL_Test.aCounter[1] when GVL_Test.aCounter is recorded). engine (cycle mode): 'native' = the C++ capture service (Beckhoff AdsLib on TcAdsDll: ADS callback → ring → file, no Python on the data path), 'python' = the in-process recorder, None = recorder.engine from the config (default 'auto': native when installed). The response says which engine ran and why. After stopping: rec_verify. also_scope: also run the TwinCAT Scope configuration open in XAE (scope = its name when several are open) — StartRecord now; at rec_stop StopRecord and SaveSVD into /Scope Recordings/.svdx, the CSV .scope.csv exported from that file with Beckhoff's export tool (XAE's ExportCSV only without it, flagged), XAE's ExportCSV of what Scope holds in memory beside it (.scope.xae.csv) with both row counts compared (cross_check — a saved .svdx shorter than memory, or the reverse, is a warning), a signed link file, and the Scope View log's new ERROR / FATAL lines (scope_view_log). A .svdx still being written 15 s after SaveSVD is not exported. What Scope records (channels, sample time) is set in that configuration. With recorder.also_scope = 'ask' (default) and a Scope configuration open, leaving also_scope unset asks the user (prompt, or an error that tells you to ask and call again with true/false). After a recording Scope holds its data until it is disconnected: a recording with Scope then asks to disconnect it first — scope_disconnect=true / false is the user's answer (false: this recording without Scope).

NameRequiredDescriptionDefault
modeNochange
nameNo
scopeNo
engineNo
prefixNo
patternNo
symbolsNo
cycle_msNo
stop_whenNo
also_scopeNo
duration_sNo
max_eventsNo
start_whenNo
max_symbolsNo
max_delay_msNo
allow_partialNo
cycle_counterNoauto
edge_triggersNo
post_trigger_sNo
pre_trigger_msNo
scope_disconnectNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses that recording runs in the background, how it stops, timestamp and notification-block behavior, partial-registration failure, program-change termination, engine selection, and Scope prompting. These are exactly the behavioral traits an agent needs before invoking a stateful recorder.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is front-loaded and the length is partly justified by a 21-parameter tool. However, the remainder is a dense run-on paragraph with extensive secondary details about Scope export files, row counts, and signed link files that are hard to scan and not essential to starting a recording.

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?

Given the output schema and annotations, the description still covers lifecycle, stop conditions, failure modes, engine choice, and the tricky Scope interaction. It is complete enough for an agent to invoke the tool correctly despite its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 21 parameters, so the description must carry the meaning. It explains mode, selection semantics, triggers, timing, batching, partial failure, cycle_counter, engine, and Scope controls, but it omits name and max_symbols entirely, leaving two parameters undocumented.

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 first sentence states a specific verb and resource: start a continuous real-time recording of online PLC variables. It also distinguishes the selection semantics from rec_scan and the lifecycle from rec_stop/rec_verify, so an agent can identify the tool without opening the 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?

The description gives clear operational context: modes, triggers, background lifetime, and the rec_verify follow-up. It names rec_scan and rec_stop, but does not explicitly compare this tool with rec_capture, rec_snapshot, or scope_record, nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_statsA
Read-only

Per-symbol statistics over the whole recording so far: count, first/last, min/max/mean, change count, BOOL rising/falling edges with timestamps, and value runs (state timeline with dwell times). Live (incremental) while complete; recomputed from the file when the ingest had to skip statistics under load, for recordings of earlier sessions, or with exact=true.

NameRequiredDescriptionDefault
idYes
exactNo
symbolsNo
max_runsNo
include_runsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only establish read-only/non-destructive, so the description adds real behavioral context: results are maintained live and incrementally in the normal case, but are recomputed from the recorded file when statistics were skipped under load, for earlier sessions, or when exact=true. That silently doubles as a cost/latency hint. It does not state how expensive the recompute is or whether an active session is required, keeping it short of a 5.

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?

Two dense sentences with no filler, front-loaded with the returned statistics before the execution-mode caveat. The parenthetical 'Live (incremental) while complete' is slightly compressed and takes a second read, but overall it earns its length.

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?

An output schema exists, so the description need not enumerate return values, yet the extra detail on run timelines and edge timestamps is still useful orientation. Combined with the live-vs-recompute semantics, an agent can call it correctly; the only residual gap is the four undocumented parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description bears the full parameter burden. It usefully disambiguates the most confusing parameter (exact=true forces file-based recomputation) and hints at the runs parameters via 'value runs (state timeline with dwell times)', but id, symbols, max_runs, and include_runs are never explained, leaving meaningful gaps.

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 description names a specific verb+resource (per-symbol statistics over the whole recording) and then enumerates exactly which statistics are produced (count, first/last, min/max/mean, change count, BOOL edges, value runs with dwell times). That enumeration distinguishes it from adjacent recording tools like rec_pulses, rec_latency, or rec_read, which return raw samples rather than aggregates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the operational context that decides the mode of computation (live incremental vs file recompute after skipped ingest under load, for earlier sessions, or with exact=true), which implicitly tells the agent when exact=true is worth setting. However, it never states when to prefer this tool over recording siblings (rec_read, rec_pulses, rec_snapshot, rec_compare) or any explicit 'use X instead' exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_statusA
Read-only

Live status of one recording: samples, events, rate, missing_samples (holes in the PLC timeline, cycle mode), completeness, dropped (lost on this PC), backlog, stats_coverage, per-block report, warnings, armed/triggered, last value per symbol; with Scope: scope {state recording | finishing | finished | stop_unknown} (N182; recording with stop_refused: XAE refused StopRecord, rec_stop asks again).

NameRequiredDescriptionDefault
idYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/destructive=false, and the description adds real semantics beyond them: it disambiguates missing_samples (holes in the PLC timeline, cycle mode) from dropped (lost on this PC) and backlog, and spells out the scope state machine (recording | finishing | finished | stop_unknown) including the stop_refused edge case. It stops short of saying whether the call blocks, how expensive it is, or how stale the snapshot may be.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Lead clause is front-loaded and useful, but the rest is one long comma/semicolon-spliced enumeration that reads as a data dump rather than guidance, and much of it duplicates the output schema. It is not padded with fluff, but the structure makes it hard to scan.

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?

A read-only status tool with an output schema, so return-shape explanation is not required — and the field list arguably overlaps gratuitously with that schema. The real remaining gap is provenance of the id and whether the tool is valid against finished recordings; everything else an agent needs to invoke it is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (id) with 0% schema description coverage, and the description never mentions it or how an id is obtained (rec_list/rec_start). The phrase 'one recording' implies the id identifies the recording, which is the entire semantic contribution — marginal, but the schema itself is trivially self-evident for a single string key.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Live status of one recording', then enumerates the concrete data it reports (samples, rate, missing_samples, dropped, backlog, armed/triggered, last value per symbol). It never names which sibling to use instead (rec_stats, rec_read, rec_list), so an agent must still infer the boundary against those, but the scope of what this tool returns is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'live' status suggests polling during an active recording, and the note that 'rec_stop asks again' when state is recording with stop_refused gives one concrete routing hint to a sibling. There is no explicit when-to-use versus rec_stats/rec_read/rec_list, and no statement about whether it works on finished recordings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_stopB
Idempotent

Stop a recording, release the ADS notifications, finalize the file; returns status + stats. With Scope: its part is finished, and Scope (it now holds this recording) is closed, starts a new recording, or keeps the data (pause) — the user is asked (scope_next).

NameRequiredDescriptionDefault
idYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare non-readonly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: ADS notifications are released, the file is finalized, status+stats are returned, and the Scope holder is prompted (scope_next) to close, restart, or pause. The Scope sentence is somewhat garbled, but the side-effect disclosure is real.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core sentence is efficient and front-loaded, but the Scope clause is convoluted and reads as if truncated mid-thought, forcing the agent to parse ambiguous phrasing to understand post-stop behavior.

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?

An output schema exists, so return values ('status + stats') need not be detailed further, and annotations carry the mutation safety profile. The remaining gap is the unexplained 'id' parameter, which leaves the calling contract ambiguous for a one-required-param tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the only parameter, 'id', is never mentioned in the description. An agent cannot tell whether this is a recording id, session id, or profile id without guessing, so the description fails to compensate for the undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource: stop a recording, release ADS notifications, finalize the file. It conveys the effect clearly, though it doesn't distinguish itself from the nearby rec_profile_stop or rec_start siblings by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to call this versus rec_profile_stop, rec_start, or rec_delete. The Scope sentence describes what happens after stopping, not the condition that selects this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rec_verifyA
Read-only

Prove a finished recording. integrity: the file is byte-for-byte what the recorder wrote (sha256 of every line, signed with this install's key) — 'MODIFIED' if anything was edited. timeline (cycle mode): per notification block, holes between the PLC's own sample timestamps. counter (optional): a PLC variable that increments every cycle and was recorded with the rest (your nCycleCount, or TwinCAT_SystemInfoVarList._TaskInfo[1].CycleCount) must step by exactly step per sample — ground truth for 'no sample lost'. verdict PASS only if all checks hold; INCONCLUSIVE when the file is intact but its completeness cannot be shown (a change / poll recording without counter=, or a stop from an older version whose blocks ended apart); FAIL on any loss, a block that never delivered, or symbols not subscribed.

NameRequiredDescriptionDefault
idYes
stepNo
counterNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only/non-destructive safety. The description goes well beyond that: it explains the sha256-signed integrity check and MODIFIED outcome, the per-block timestamp-hole check in cycle mode, the counter ground-truth check, and the full PASS/INCONCLUSIVE/FAIL decision logic including the older-version stop edge case.

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 core purpose, then the three check types, then the verdict rule — a logical order. It is dense and jargon-heavy with long semicolon-joined clauses, but each clause carries distinct verification semantics rather than filler.

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 complex verification tool with an output schema present (so return format needn't be restated), the description covers checks, parameter meaning, and all verdict outcomes. An agent has what it needs to call it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load, and it does for the two non-obvious params: `counter` is defined with concrete example symbols (nCycleCount, TwinCAT_SystemInfoVarList._TaskInfo[1].CycleCount) and `step` is defined as the required per-sample increment. Only the required `id` parameter is left undocumented, which is a minor gap.

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 ('Prove a finished recording') and immediately scopes it to integrity, timeline, and counter verification. An agent can tell this apart from rec_read, rec_compare, or rec_status, which read or diff data rather than proving a recording's soundness.

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?

Makes clear this applies to a *finished* recording and precisely describes the conditions under which a verdict is INCONCLUSIVE vs FAIL, which effectively tells the agent when the tool's answer is meaningful. It does not, however, name an explicit alternative tool or state when not to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scope_exportA
Idempotent

Export a saved TwinCAT Scope recording (.svdx / .svd) to CSV with Beckhoff's TC3ScopeExportTool.exe (command line "svd=<file>" target=<csv> silent; CSV needs no extra licence). Default target: /Scope Recordings/.csv ([scope] export_dir). The CSV is Beckhoff's output, unchanged — channels, time column and alignment of channels with different sample times follow the Scope project's export settings. A signed .provenance.json records the source file and SHA-256, the tool and its SHA-256, and the command. A read-only source (rec_stop seals its .svdx) is exported from a byte-identical writable copy. scope_view_log: the ERROR lines the Scope View logs (TcScopeView.log and its numbered siblings, TcScopeView_1.log …) got during the export.

NameRequiredDescriptionDefault
svdYes
targetNo
overwriteNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false. The description adds genuinely useful context beyond them: a signed <csv>.provenance.json side file is written, read-only sources are handled via a copy, and CSV content/layout comes from the Scope project settings. However it never says what happens when the target already exists, which is the key write-behaviour question for a non-destructive but writing tool.

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 core action and the command line are front-loaded and the provenance/error notes are informative rather than filler. It is dense with parentheticals and log-file digressions, which slightly slows scanning, but no sentence is wasted.

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?

An output schema exists so return values need not be described, and the description covers the tool invocation, output location, side effects and error retrieval. The one real hole is overwrite behaviour on an existing target, which matters for a tool that writes files.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. It explains svd and the target default resolution (<recordings>/Scope Recordings/<name>.csv, [scope] export_dir), but never mentions the overwrite parameter at all, leaving one of three parameters undocumented in both places.

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 (export), a specific resource (saved TwinCAT Scope recording .svdx/.svd) and the concrete output format (CSV via TC3ScopeExportTool.exe). That clearly separates it from scope_record, scope_list and rec_export in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains operational context – a sealed read-only source is exported from a byte-identical writable copy, and errors are found via scope_view_log – but it never says when to pick this over rec_export, rec_read or ads_export. Usage is implied by the resource type rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scope_listB
Read-only

TwinCAT Scope configurations in the solution open in XAE (TwinCAT Measurement projects). Their channels, sample time and record time are what scope_record / rec_start(also_scope=true) record.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds useful context that these are TwinCAT Measurement projects and ties them to the recorder tools, but discloses nothing about return format, pagination, or scoping behavior beyond what annotations and the output schema provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no obvious filler, but the first sentence is a noun phrase describing the resource rather than a front-loaded action statement, and the second's parenthetical (also_scope=true) is dense. It is acceptably sized but not optimally structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only list tool with an output schema (so return values need not be explained), the description is roughly adequate. Its main gap is that it never plainly states that it lists/enumerates the configurations, leaving the core operation unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline 4 condition. There is no parameter semantics burden for the description to carry.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (TwinCAT Scope configurations in the solution open in XAE / TwinCAT Measurement projects) but never states the action. The name implies 'list', yet the text describes what the resource is rather than what the tool does with it, leaving the agent to infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implicitly connects scope_list to sibling tools by noting that the channels, sample time and record time are what scope_record / rec_start(also_scope=true) record, hinting at a discovery-then-record workflow. However, it never explicitly states when to call scope_list or when not to, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scope_recordB
Idempotent

Drive a Scope configuration open in XAE (Automation Interface IMeasurementScope): action = start | stop | disconnect (Scope discards what it holds and is back in Config — needed before it records again; asks for the user's confirmation unless what it holds is a recording the plugin saved) | new (disconnect, then start) | save (SaveSVD → /Scope Recordings/-.svdx, or path=.svdx; the .csv exported from that file with Beckhoff's export tool — XAE's ExportCSV only without it, flagged, and never over an existing CSV; XAE's ExportCSV of the in-memory data beside it, .xae.csv, row counts compared in cross_check; the Scope View log's new ERROR / FATAL lines). scope = its name when several are open. Affects only the Scope recording, not the PLC. One Scope, one owner (N189): while a recording's Scope part has Scope, its rec_stop / rec_delete stop and save it — start / stop / save / disconnect / new here are refused; a Scope recording started here owns Scope until action='stop'.

NameRequiredDescriptionDefault
pathNo
scopeNo
actionYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description contains rich side-effect detail, but it contradicts the annotations. idempotentHint=true conflicts with save producing timestamped .svdx files and new restarting the recording, and destructiveHint=false conflicts with disconnect discarding what the Scope holds unless it was previously saved. That is an annotation contradiction, so this dimension must score 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and action list are front-loaded, and much of the length is justified by the tool's complexity. However, the save behavior is written as a dense semicolon-and-parenthesis run-on, making the definition harder to parse than necessary.

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?

For a complex stateful Scope tool with an output schema, the description covers ownership, refusal conditions, save artifacts, and PLC isolation well. The main gaps are confirm_token semantics and reconciliation with the annotations, which prevent a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 parameter semantics. It defines action values well, explains scope selection by name, and mentions path=<file>.svdx for save, but it never explains confirm_token. It compensates substantially but incompletely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Drive a Scope configuration open in XAE') and enumerates the action modes start/stop/disconnect/new/save. It also states the tool affects only the Scope recording, not the PLC. It is clear, but it does not explicitly distinguish itself from sibling scope tools such as scope_status, scope_list, or scope_export.

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?

Usage is mostly explicit: disconnect is needed before recording again, ownership rules refuse start/stop/save/disconnect/new while another recording owns Scope, and rec_stop/rec_delete are named as the alternative stop/save path in that case. It lacks an explicit comparison with scope_export/status/list, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scope_statusB
Read-only

TwinCAT Scope on this PC: where TC3ScopeExportTool.exe is (TE130x Scope View / TF3300 Scope Server) and the default export folder.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what specifically is reported (tool path and default export folder), but omits any notes on behavior such as when the default folder is unset or what happens if Scope is not installed.

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?

A single, front-loaded sentence with no filler; the key noun (TC3ScopeExportTool.exe location) comes first. The stray line break mid-sentence is a minor formatting blemish but does not hurt readability.

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 input params, a read-only annotation, and an output schema present, the description needs only to explain what the tool is for, which it does adequately by naming the two returned facts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and the exact facts returned: the location of TC3ScopeExportTool.exe and the default export folder, scoped to 'this PC'. It is clear what the tool reports, though it does not distinguish itself from siblings like scope_export, scope_list, or scope_record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus alternatives. An agent could infer it is a diagnostic/location lookup, but no explicit when-to-use, prerequisites, or sibling routing is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snap_applyA
Destructive

Write a saved snapshot back to the PLC (recipe / parameter restore). dry_run lists the differences only. Every differing symbol is gated like ads_write.

NameRequiredDescriptionDefault
nameYes
dry_runNo
symbolsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a destructive, non-read-only write. The description adds useful context: dry_run lists differences only, and every differing symbol is gated like ads_write. It does not expand on what that gating entails, but it meaningfully supplements the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler, front-loading the action and resource before the dry_run and gating notes. Every sentence adds distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, preview behavior, and per-symbol safety gating, and an output schema exists for return values. However, with no schema parameter descriptions, the omission of the symbols parameter leaves a substantial gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 parameter meaning. It clarifies dry_run ('lists the differences only') and implies that 'name' is the target snapshot, but it never mentions the symbols parameter or its scope-limiting role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Write') and resource ('saved snapshot back to the PLC'), with the clarifying use case 'recipe / parameter restore'. It clearly distinguishes this from saving or comparing snapshots, though it does not explicitly name sibling alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The restoration use case is implied by '(recipe / parameter restore)' and dry_run is presented as the difference-listing mode. However, there is no explicit guidance on when to prefer this over snap_compare or ads_write, nor any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snap_compareB
Read-only

Diff snapshot a against b (another snapshot or 'live'), numeric tolerance applies.

NameRequiredDescriptionDefault
aYes
bNolive
symbolsNo
toleranceNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and destructiveHint=false, and the description is consistent with a read-only comparison. It adds useful context that 'b' may be 'live' (comparing against running values) and that a numeric tolerance applies, but says nothing about how the diff is reported or whether tolerance affects matching vs. output.

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?

A single compact sentence, front-loaded with the core action and immediately naming the alternative operand values. No wasted words, though the parenthetical slightly crowds the tolerance clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a 4-parameter tool with 0% schema description coverage, the undefined 'symbols' parameter and the unspecified tolerance semantics/default leave the agent short of full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden. It explains 'a' and 'b' (including the 'live' sentinel) and mentions tolerance as numeric, but the 'symbols' filter parameter is entirely undocumented in both schema and description, leaving a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Diff') and resource (snapshot), and clarifies the second operand can be another snapshot or 'live'. It is clear without needing the schema, though it does not explicitly distinguish itself from sibling comparison tools like rec_compare or exp_compare.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus rec_compare/exp_compare, no prerequisites (does snapshot 'a' need to exist? is 'live' a running PLC?), and no exclusions. The agent must infer usage entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snap_listC
Read-only

Saved snapshots.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

C2.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the bar is lower. The description still adds nothing: no scope of the listing (all snapshots, per-project, per-session), no ordering, and no mention that it is a non-mutating enumeration.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two words are not concision here but under-specification; nothing meaningful is front-loaded because nothing meaningful is said. A single sentence stating it lists saved snapshots and their scope would cost little and add much.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Even so, an agent cannot tell from this fragment what set of snapshots is returned, which is essential for using snap_list correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter semantics for the description to clarify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Saved snapshots." is a bare noun phrase that restates the resource in the tool name rather than stating a verb. It never says the tool lists or enumerates snapshots, and it does not distinguish snap_list from snap_save, snap_compare, or snap_apply.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, no mention of when to prefer snap_compare or snap_apply instead. The agent is left to infer everything from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snap_saveB
Idempotent

Save a named snapshot of live values (expanded like rec_start) for regression comparison — parameters, recipes, whole FB instances before/after a change.

NameRequiredDescriptionDefault
nameYes
prefixNo
patternNo
symbolsNo
max_symbolsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the mutating-but-non-destructive, idempotent profile, so the bar is lower. The description usefully adds that values are 'expanded like rec_start' and scoped to parameters/recipes/FB instances, but omits what happens on a name collision, where snapshots are persisted, and any size limits implied by max_symbols.

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?

A single dense sentence with the verb and the regression-comparison rationale front-loaded; little waste, though the parenthetical 'expanded like rec_start' assumes sibling knowledge.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values needn't be explained, and annotations cover the safety profile. However, with 5 undocumented parameters and no collision/persistence semantics, the definition leaves meaningful gaps for a tool that creates stored state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 5 parameters, so the description carries the full burden — yet it never mentions name, prefix, pattern, symbols, or max_symbols. The phrases 'parameters, recipes, whole FB instances' gesture at selectable scope but give no mapping to the selector parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Save a named snapshot of live values') with the purpose (regression comparison) and the scope of captured data. It does not explicitly name its siblings snap_compare/snap_list/snap_apply, so an agent must infer the routing rather than read it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'for regression comparison ... before/after a change' phrase implies when it is used, but there is no explicit when-not guidance and no named alternative (e.g. snap_compare for the comparison step, rec_snapshot for the recording equivalent).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_allow_writeA
Idempotent

Add (or remove) a write allow-list pattern for THIS session only — the in-session alternative to editing twincat_mcp.toml and reconnecting. fnmatch, case-insensitive: 'GVL_Test.*', 'MAIN.fbDispense.rSetpoint'. Control-class: needs a confirmation (prompt or confirm_token from tc_request_confirmation(action='tc_allow_write', target=''), or target='-' to remove). The deny list still wins; the change is audited and lost at the next server start.

NameRequiredDescriptionDefault
removeNo
patternYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: the change is session-scoped and lost at next server start, it is audited, the deny list still wins, and it requires confirmation via prompt or confirm_token from tc_request_confirmation. These are exactly the behavioral traits annotations don't cover.

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?

Dense and front-loaded, with the scope and purpose stated first and the operational caveats following. Every sentence carries information, though the parenthetical confirmation sentence is somewhat packed.

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 session-scoped config-mutating tool, it covers scope, persistence, audit, safety interaction (deny list), and the confirmation requirement; an output schema exists so return values need no explanation.

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?

With 0% schema coverage the description carries the full burden and largely does: it explains the pattern syntax (fnmatch, case-insensitive) with concrete examples and identifies the confirm_token source. The only soft spot is the 'target=...<pattern>' removal phrasing, which is slightly conflated with the separate 'remove' boolean.

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 (add/remove a write allow-list pattern) plus an explicit scope ('THIS session only') and frames it against the config-editing alternative. An agent can distinguish it from the many ads_write/xae_* siblings without opening the 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 when-to-use context (in-session alternative to editing twincat_mcp.toml and reconnecting) and the precondition (control-class, needs confirmation). It does not name an explicit when-not-to-use or a sibling tool, so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_audit_tailB
Read-only

Last n audit records (mutating calls, confirmations, mode changes).

NameRequiredDescriptionDefault
nNo

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value by naming the record categories included (mutating calls, confirmations, mode changes), but says nothing about ordering, time window, or how many records actually exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single brief sentence with no filler, and the scope ('last n') is front-loaded ahead of the clarifying parenthetical. Nothing needs trimming.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. For a one-parameter read tool this is close to complete, with only ordering and record-availability behavior left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema only exposes 'n' as an untitled integer with default 50. The description partially compensates by tying 'n' to the number of audit records returned, but adds no bounds, units, or behavior when n exceeds available records.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource (audit records) and its scope ('last n'), and enumerates the record kinds it returns (mutating calls, confirmations, mode changes). That makes the tool's output distinguishable from siblings like tc_safety_status or tcunit_results, though the verb is implicit ('Last n audit records') rather than a clean action phrase.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. An agent must infer from the name and the parenthetical that this is for inspecting recent audit/safety-related activity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_doctorA
Read-only

Environment check: platform, pyads/router, local AMS NetId, XAE ProgIDs in the registry, running XAE shells, project root, safety mode, whether a confirmation prompt can reach the user in this session (elicitation: the negotiated MCP revision and the client's declared capability). Run this first. Starts with a one-line summary; verbose=true adds the full loaded configuration.

NameRequiredDescriptionDefault
verboseNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral detail: what the check reports, that output begins with a one-line summary, and that verbose=true expands the loaded configuration. It does not contradict the annotations.

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 front-loaded with the purpose and scope, then states the usage directive, then describes output behavior. The enumerated checks are dense but each item is relevant to a diagnostic tool; there is little wasted text, though the long parenthetical makes it slightly heavy.

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 read-only diagnostic tool with an output schema, an agent needs to know what is checked, why to run it first, and how verbosity affects output. The description supplies all of that, and the output schema handles the return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 parameter meaning. It does this for the single parameter by explaining that verbose=true adds the full loaded configuration, whereas the default returns only the one-line summary.

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 description names a specific diagnostic resource, 'Environment check', and enumerates the exact environment aspects it inspects: platform, pyads/router, AMS NetId, XAE ProgIDs, running shells, project root, safety mode, and elicitation capability. Combined with 'Run this first', an agent can distinguish this aggregate readiness check from all the narrower operation-specific siblings.

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 with 'Run this first', telling the agent when to invoke it relative to other tools. It does not state when not to use it or name alternative diagnostics, but for a first-run environment check that omission is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_reload_configA
Idempotent

Re-read twincat_mcp.toml (and TCMCP_* env) without a restart. Applies: safety allow/deny lists, confirm_destructive, confirm_ttl_s, docs settings, naming prefixes, dialog rules, tcunit result path. Reports — but does not apply — changes that need a restart: ads target/port, solution path, project root, mode/max_mode (use tc_set_mode).

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare a non-read-only, idempotent, non-destructive operation; the description goes beyond that by splitting settings into those applied live versus those merely reported pending a restart. This is exactly the kind of nuance annotations cannot express. It does not cover failure behavior (e.g. malformed toml), keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads verb and resource, then lists affected settings compactly and finishes with the deferred settings plus the alternative tool. No sentence is filler.

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?

With an output schema present, zero parameters, and annotations covering the safety profile, the description supplies the remaining needed context: what is reloaded, what takes effect immediately, and what is deliberately deferred.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. Nothing in the description contradicts the empty argument 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?

States a specific verb and resource ('Re-read twincat_mcp.toml (and TCMCP_* env)') plus the key constraint 'without a restart'. It also enumerates the setting classes it affects, which distinguishes it clearly from restart-oriented siblings like xae_restart_twincat.

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?

Explicitly names what it does not apply and routes the agent to the alternative ('mode/max_mode (use tc_set_mode)'), and the 'without a restart' framing implies the trigger condition. It stops short of a fully explicit when/when-not statement, but the alternative routing is present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_request_confirmationA
Read-only

Issue a single-use confirm_token for a control/destructive tool: action = the tool's exact name. Easiest: pass the tool's own arguments as args (e.g. action='xae_plc', args={'action': 'login', 'plc_project_path': 'TIPC^Plc^Plc Project'}) — the server computes the target the tool will check, the same way the tool does. A target given by hand must equal it (a partial one — 'login', 'PLC.Login' — is completed); the error names the right one. Targets: xae_deploy / xae_restart_twincat / xae_activate_configuration / tcunit_run: the XAE target NetId; xae_plc: ':@'; xae_command: '@'; xae_boot_project: the plc_project_path (with '@' when activate_after_generate); xae_tree_delete: '<parent_path>^'; xae_library_add: ':'; xae_library_remove: ':' + ' ()' and ', ' when given; xae_placeholder_add: ':'; xae_placeholder_resolve: ':=' + ', ' when given; xae_placeholder_freeze: ':' ('*' for all); xae_link: ' -> ' (paths as normalised: '^', TIID) + ' [offsets /, bit]' for a part; xae_unlink: ' -> ', or ' -> (all )'; xae_links_import: ':<sha256 of the XML text, 16 hex> over <sha256 of the table now, 16 hex> (+ -)' — the dry run's confirm_target; xae_target: the new NetId; xae_dialog_resolve: ':'; ads_plc_state / ads_system_mode: the action (run, stop, reset / run, config); ads_connect: the NetId, or 'local'; ads_add_route_to_plc: the PLC's IP address; ipc_write_file / ipc_delete_file / ipc_start_process: the remote path; ipc_eventlog: the log name; ipc_reboot: the literal 'target'; rec_delete: the recording id; tc_set_mode: the mode; tc_allow_write: the pattern ('-pattern' to remove); exp_run: the experiment name; kb_rebuild: the index: 'infosys', 'manuals' or 'esi'.

NameRequiredDescriptionDefault
argsNo
actionYes
targetNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true and destructiveHint=false already declaring the safety profile, the description still adds real behavior: the token is single-use, the server recomputes the target exactly as the target tool would, partial targets are auto-completed, and a mismatch returns an error naming the correct target. Missing are token lifetime/TTL and session binding, which matter for a short-lived credential.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded correctly, and nearly every clause carries necessary target-format information that has no other home given 0% schema coverage. However, the target enumeration is delivered as one dense run-on paragraph of em-dashes and parentheticals rather than a scannable list, making it hard for an agent to locate the single format it needs for a given action.

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?

An output schema exists, so the returned token's shape need not be described, and all three parameters are documented exhaustively for a 3-param tool. The remaining gap is workflow-level: the description never states how long the token is valid or where the caller must place it on the subsequent call.

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 does: 'action' is defined as the tool's exact name, 'args' as the target tool's own arguments (with a worked example), and 'target' gets a per-action format specification for roughly thirty actions, including the construction rules for composite targets. This is far more than the bare string/object types in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause gives a specific verb and resource: 'Issue a single-use confirm_token for a control/destructive tool.' That is unmistakably different from every sibling (which are the tools that consume the token). It stops short of naming a sibling or stating the full call sequence (obtain token, then invoke target tool), which keeps it from a 5.

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 enumerated target list effectively states when the tool is needed — it names the exact control/destructive tools (xae_deploy, ipc_reboot, ads_plc_state, exp_run, kb_rebuild, etc.) that require a token. It also gives a preferred usage path ('Easiest: pass the tool's own arguments as args') versus the manual alternative. It never says what happens if you skip confirmation or how the returned token is then supplied, so it is not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_safety_statusA
Read-only

Current safety mode (and where it came from), ceiling, allow/deny lists, pending confirmation tokens.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds which pieces of safety state are surfaced (origin of the mode, pending tokens), which is useful context beyond the annotations, but it says nothing about freshness, whether the lists are effective or configured values, or how pending tokens are represented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence, front-loaded with the primary subject and then the enumerated contents. No filler, no redundancy with the title or schema.

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 an output schema present, the description need not explain return values, and it correctly limits itself to naming the state being reported. For a no-argument read tool this is close to sufficient; only the absence of any routing guidance keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema-based baseline of 4 applies. There are no argument semantics for the description to clarify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (safety status) and enumerates exactly what it exposes: mode and its origin, ceiling, allow/deny lists, pending confirmation tokens. An agent can tell this is a read/report tool rather than the mutating siblings tc_set_mode or tc_allow_write, though the noun-phrase form leaves the verb implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance at all: nothing tells the agent to call this before tc_allow_write or tc_request_confirmation, nor how it relates to tc_doctor or tc_set_mode. The agent must infer the workflow context entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_session_reportB
Read-only

Markdown handover of this session: mode changes, writes, deploys and other mutating calls from the audit log, recordings, snapshots and dumps produced. Written to ~/.twincat_mcp/reports/.md (or out_path).

NameRequiredDescriptionDefault
inlineNo
out_pathNo
overwriteNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true / destructiveHint=false, so the safety profile is carried structurally; the description adds real value beyond that by naming the aggregation sources (audit log, recordings, snapshots, dumps) and the output artifact/path. It does not explain what inline vs file output yields, nor that overwrite=true can replace an existing file, and it discloses a filesystem write that sits uneasily next to readOnlyHint=true.

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?

Two tight sentences, front-loaded with what the report contains, then where it lands. Little waste; only the parenthetical '(or out_path)' is slightly cryptic without schema context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no prose, and the description covers report contents and destination. However, for a 3-parameter tool the meaning of inline and overwrite (and the overwrite risk) is missing, so the definition is not quite complete enough to invoke confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for three parameters, so the description must compensate, but it only gestures at out_path ('or out_path'). The inline and overwrite parameters are undocumented in both the schema and the description, leaving the agent to guess what inline returns and what overwrite destroys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: a Markdown handover report of 'this session', with contents enumerated (mode changes, writes, deploys, mutating calls, recordings, snapshots, dumps). This is distinguishable from siblings like tc_audit_tail (raw tail), exp_report, or rec_export, though the description never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the word 'handover' – the agent can infer it is an end-of-session summarization step, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. tc_audit_tail for raw entries). No prerequisites or ordering guidance are given despite a large sibling surface.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tc_set_modeA
Idempotent

Switch safety mode: readonly | guarded | full. Lowering is free. Escalating (guarded→full, readonly→guarded) is capped at max_mode AND needs a confirmation (prompt or confirm_token) — an agent must not be able to widen its own permissions silently.

NameRequiredDescriptionDefault
modeYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare idempotent/not-destructive/not-readonly; the description adds the substantive policy that escalation is capped at max_mode and must be confirmed so an agent cannot silently widen its own permissions. It stops short of stating failure behavior when the cap is hit or what the tool returns on a refused escalation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight clauses with the mode enumeration front-loaded and the escalation rule immediately after; no filler sentences and nothing repeated from the schema.

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?

An output schema exists so return values need not be described. The description covers mode values, the lowering/escalation asymmetry, the max_mode ceiling and the confirmation requirement — sufficient to call it correctly — with only minor gaps around denial behavior and token acquisition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the mode property has no enum, so the description's inline enumeration 'readonly | guarded | full' is essential and does real work. It also explains confirm_token's role (confirmation on escalation), though it never says how to obtain one or its format.

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 (Switch) and resource (safety mode) and enumerates the three valid states (readonly | guarded | full), which no sibling tool offers — tc_safety_status reads status and tc_allow_write is a different control surface. An agent can tell this apart from every sibling without opening the 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 when-conditions: lowering is free, escalating requires confirmation via prompt or confirm_token and is bounded by max_mode. It does not, however, point to the sibling that produces the confirmation (e.g. tc_request_confirmation) or explain what to do when escalation is refused.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tcunit_resultsB
Read-only

Parse a TcUnit xUnit result into a pass/fail summary. Source: the file on the target over ADS (default: configured remote path), a local file, or raw XML text.

NameRequiredDescriptionDefault
xml_textNo
local_pathNo
remote_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the bar is lower. The description usefully adds that a remote source is read 'over ADS' and that remote_path is the default, but it omits precedence rules when multiple sources are supplied and any ADS-connection prerequisites.

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?

Two tight sentences with the core action front-loaded and the source enumeration second; no filler. The source list is compressed into a single clause, which is efficient though slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and annotations cover the safety profile. However, for a 3-parameter tool with 0% schema coverage and no required params, the definition does not resolve what happens if no source is given or how competing sources are prioritized.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 parameter meaning. It maps all three parameters to their sources (raw XML text, local file, file on target over ADS) and identifies remote_path as the default, but leaves precedence and mutual exclusivity between xml_text/local_path/remote_path unstated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Parse') plus resource ('TcUnit xUnit result') and the concrete output ('pass/fail summary'), which is more precise than the bare name. It does not explicitly differentiate itself from the sibling tcunit_run (which presumably executes tests) or tcunit_scaffold, so an agent must infer the read/parse vs run distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells you what inputs are acceptable and that the remote path is the default, which implicitly frames when to use it (after a run, when you already have a result artifact). It gives no explicit when-to-use versus tcunit_run or guidance for choosing among the three sources, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tcunit_runA
Destructive

Full TcUnit cycle: save (checked) → build → boot project autostart+generate → activate → restart → delete old result → wait for the xUnit file on the target → parse. Destructive-class (it activates a configuration on the target): tc_request_confirmation(action='tcunit_run', target=). plc_project_path from xae_plc_projects. TcUnit writes the result file only with its library parameter GVL_Param_TcUnit.xUnitEnablePublish = TRUE (default FALSE): the run is refused before anything is activated when the project source says FALSE, and stops waiting when the PLC reports FALSE (D40).

NameRequiredDescriptionDefault
timeout_sNo
disable_ioNo
save_firstNo
skip_buildNo
confirm_tokenNo
plc_project_pathYes
remote_result_pathNo
allow_target_mismatchNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is known; the description adds substantial context beyond that: it activates a configuration on the target, requires a confirmation token, is refused before activation when GVL_Param_TcUnit.xUnitEnablePublish=FALSE, and stops waiting when the PLC reports FALSE (D40). That is real operational detail the annotations do not carry.

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 pipeline is front-loaded in the first sentence and the safety/prerequisite caveats follow in priority order. It is dense and jargon-heavy ('boot project autostart+generate', 'D40') but every clause carries information; little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, the description rightly does not explain return values and instead covers prerequisites, confirmation, and failure mode. However, for an 8-parameter destructive tool at 0% schema coverage, the undocumented optional flags leave the definition short of complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 8 parameters and the description only addresses two of them indirectly: plc_project_path's origin and the confirm_token flow. It says nothing about disable_io, save_first, skip_build, timeout_s, remote_result_path, or allow_target_mismatch, so an agent must guess at the majority of the parameter surface from bare titles and defaults.

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?

It enumerates the exact pipeline this tool executes (save → build → boot project generate → activate → restart → delete old result → wait → parse), which is a specific multi-step verb sequence rather than a restatement of the name. This lets an agent distinguish it from tcunit_scaffold (creates a scaffold) and tcunit_results (reads results) without opening any 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?

The description names the required confirmation flow (tc_request_confirmation(action='tcunit_run', target=<NetId XAE targets>)) and the source of the required argument (plc_project_path from xae_plc_projects), giving clear context for invoking it. It stops short of stating when NOT to use it or naming tcunit_results as the read-only alternative, so it is clear-but-not-exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tcunit_scaffoldA
Idempotent

Generate _Tests.TcPOU (TcUnit.FB_TestSuite) with Test_InitialState and one test method per public method, arranged from the FB interface, and register it in the .plcproj. Assertions are left as TODO stubs.

NameRequiredDescriptionDefault
fb_nameYes
out_dirNo
overwriteNo
add_to_plcprojNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring non-readOnly, idempotent, non-destructive, the description still adds valuable behavior: it writes to the .plcproj, and critically, that assertions are left as TODO stubs (so the result is incomplete until filled in). These are real side effects the agent needs. It doesn't explain overwrite or out_dir semantics, keeping it short of 5.

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?

A single dense sentence, front-loaded with the verb and artifact and trailing into the meaningful detail about TODO stubs. No filler, though the run-on structure packs several distinct facts into one clause chain.

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?

An output schema exists so return values need not be described, and the description covers the artifact, its layout, .plcproj registration, and the stub caveat. The remaining gap is the undocumented out_dir and overwrite parameters, which most agents would want clarified before invoking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 four parameters, yet it only hints at fb_name (FB interface) and add_to_plcproj (register in the .plcproj). The out_dir and overwrite parameters receive no explanation anywhere, leaving half the surface undocumented.

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 (Generate) plus an exact artifact (<FB>_Tests.TcPOU of type TcUnit.FB_TestSuite) and enumerates its contents (Test_InitialState, one method per public method). It is clearly distinct from siblings like tcunit_run, which executes rather than scaffolds tests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The generation context is implied — you call this to create a test suite skeleton — but there is no explicit when-to-use, no stated precondition (e.g. an existing FB interface), and no reference to alternatives such as tcunit_run or exp_' tooling. Usage is inferable but not spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_expectA
Read-only

Assert conditions on live values. checks: [{symbol, op, value, tolerance?}], op ∈ == != > >= < <= ~= (relative/abs tolerance) in between. within_ms>0 waits until all hold. Returns pass/fail per check with the time each one was met.

NameRequiredDescriptionDefault
checksYes
within_msNo
interval_msNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral detail beyond the annotations: supported operators, relative/absolute tolerance, 'in between', the waiting behavior when within_ms>0, and the per-check pass/fail return with timestamps. It does not pause to describe rate limits or symbol resolution, but the added context is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded: purpose first, then check syntax, operator semantics, waiting behavior, and return shape. Every sentence adds necessary information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values are covered structurally, but the description still adds helpful return detail. Gaps remain: interval_ms is unexplained, the source/nature of 'live values' and symbol resolution is vague, and there is no guidance on sibling alternatives. Given the sparse schema, these omissions leave the definition only adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 parameter meaning. It does a good job for 'checks' by explaining the object fields and the op enum, and it clarifies 'within_ms' waiting behavior. However, it completely omits 'interval_ms', leaving one of three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Assert conditions on live values.' It clearly conveys the core operation and even details the check structure. However, it does not explicitly distinguish this tool from sibling assertion or wait tools like test_stable, test_response, or ads_wait_until.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. The note about within_ms>0 waiting is a behavioral parameter detail, not a usage recommendation or exclusion. The agent must infer the intended context solely from the purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_responseA
Destructive

Write a stimulus ({symbol: value}) and measure the PLC-timestamped latency until response ('MAIN.fbValve.bOpen == TRUE') holds — how fast does the FB react? Writes are gated per symbol; originals are restored afterwards unless restore=false.

NameRequiredDescriptionDefault
restoreNo
responseYes
stimulusYes
timeout_msNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and destructiveHint=true; the description adds genuinely useful context beyond that: writes are gated per symbol, and originals are restored afterwards unless restore=false. It does not explain timeout behavior or failure modes, and there is mild tension between destructiveHint=true and the default restore=true, but the added disclosure is substantive.

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 action, then results, then side effects, in a compact form with an inline example. Slightly dense with parentheticals and a dotted symbol path, but every clause carries 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?

An output schema exists, so return-value explanation is not required. Given four params with a nested stimulus object, the description covers the critical stimulus/restore semantics but is silent on timeout_ms, a minor gap for a mutation tool that otherwise explains its side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 the load. It clarifies stimulus format ({symbol: value}) and the meaning of restore=false, but leaves response and timeout_ms (default 5000) unexplained, so it only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: writes a stimulus mapping and measures PLC-timestamped latency until a response condition holds, illustrated with a concrete expression ('MAIN.fbValve.bOpen == TRUE'). Clear purpose, but it never names or contrasts with siblings test_expect/test_stable/test_scenario, so the agent must infer the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the description — this is for measuring how fast an FB reacts to an injected stimulus — but there is no explicit when-to-use, when-not-to-use, or pointer to the alternative test_* tools for assertions or stability checks. Guidance exists only by inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_scenarioA
Destructive

Scripted FB test against the live PLC with a recording in parallel. spec = {name, record:{symbols|prefix|pattern, mode, cycle_ms}, steps:[{at_ms?, write:{sym:val}} | {expect:[checks], within_ms} | {wait_ms} | {wait_until:{symbol,op,value,timeout_ms}} | {stable:{symbol,duration_ms,tolerance}}], final_expect:[checks], timeout_ms, restore, stop_on_fail}. Every written symbol is gated before the run starts; written values are restored at the end. Returns per-step results, overall pass, and the recording id.

NameRequiredDescriptionDefault
specYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real behavioral context beyond the destructiveHint annotation: every written symbol is gated before the run starts, values are restored at the end, and stop_on_fail governs abort behavior. It also states the return shape. It stops short of naming permission/auth requirements or any rate/scope limits on the live PLC, so not a 5.

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 purpose, then dense but waste-free spec grammar; every clause describes a field, a step type, or a side effect. The brief return summary is mildly redundant given the output schema exists, but nothing is padding.

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?

For a complex nested-argument tool with an output schema, the description covers the spec structure, gating/restore semantics, and result shape well enough to call it correctly. It leaves selection relative to sibling test_* and exp_* tools unaddressed, which is the only real gap.

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?

The schema exposes only an open-ended 'spec' object at 0% description coverage, so the description carries the full burden — and does: it lays out the spec grammar (name, record{symbols|prefix|pattern, mode, cycle_ms}, the full step union, final_expect, timeout_ms, restore, stop_on_fail). This is exhaustive compensation for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource: a scripted FB test executed against the live PLC with a parallel recording. The scope is concrete enough to distinguish it from single-shot helpers like test_expect or test_stable, but it never explicitly names those siblings, so the differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the scenario in which it runs (multi-step scripted sequences with writes, expectations, waits and a recording) but gives no explicit when-to-use versus test_expect / test_stable / exp_run, and no prerequisites. Usage is deducible from the described capabilities, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_stableB
Read-only

Assert a value does not move more than tolerance for duration_ms (settle check for a weight, pressure, PID output, state).

NameRequiredDescriptionDefault
symbolYes
toleranceNo
duration_msNo
interval_msNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully implies a time-consuming operation ('for duration_ms'), but does not say whether it blocks/polls, how it fails on an assertion miss, or its polling cadence. With annotations carrying safety, a 3 is appropriate.

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?

A single front-loaded sentence with no filler; the core assertion leads and the examples clarify scope. It is tightly sized, though the terseness leaves some parameter detail unaddressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and annotations cover safety. The remaining gap is parameter meaning at 0% schema coverage, where only half the params are described. Adequate but incomplete for a 4-parameter assertion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It conveys real meaning for two of four params (tolerance = maximum permitted movement; duration_ms = observation window), which is genuine added semantics. However, symbol and interval_ms are left entirely unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Assert') and a precise behavior: a value must not move more than tolerance over duration_ms. The parenthetical examples (weight, pressure, PID output, state) make the intent concrete. It is clear, though it does not explicitly contrast itself with siblings like test_expect or test_response.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Calling it a 'settle check' implies the usage context (verifying a signal has stabilized) but no when-to-use/when-not or alternative tool is named. An agent must infer whether to reach for test_stable versus test_expect or ads_wait_until.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wf_debug_symbolB
Read-only

One-call debugging dossier for a variable: live value, declaring file:line chain, the statements that write it, code excerpts around them, and a short change watch.

NameRequiredDescriptionDefault
symbolYes
watch_msNo
context_linesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the returned artifacts and a 'short change watch', which is a behavioral trait beyond the annotations. It does not explain the watch mechanism, permissions, or side effects, so a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with a colon-delimited list of outputs and zero filler. It is appropriately sized and structured for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return-value explanation is not strictly necessary, though the description lists outputs anyway. For a composite tool with many overlapping siblings, the definition remains incomplete on selection guidance and parameter detail, even with annotations and an output schema reducing the burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 parameter meaning. It loosely maps all three parameters: symbol is the variable, context_lines are the 'code excerpts around' write statements, and watch_ms is the 'short change watch'. It omits units, defaults, and precise semantics, adding moderate but incomplete value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: one-call debugging dossier for a variable, and enumerates the concrete artifacts returned. It does not explicitly contrast with overlapping siblings like ads_read, ads_symbol_info, or proj_references, but the composite scope is distinct enough for an agent to identify it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, when-not-to-use, or alternative guidance. 'One-call debugging dossier' implies a debugging context, but with many overlapping siblings (ads_read, ads_symbol_info, proj_resolve_symbol, ads_watch) the description leaves tool selection entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wf_fb_profileB
Idempotent

Profile an FB instance for duration_s: records every leaf (change mode), samples task timing in parallel, then reports most-active symbols, boolean pulse rates, state dwell timelines, silent symbols and the FB's cost on the task. Read-only on the PLC.

NameRequiredDescriptionDefault
cycle_msNo
instanceYes
duration_sNo
task_indexNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description ends with the safety claim 'Read-only on the PLC,' while the annotations declare readOnlyHint=false, which tells an agent the tool may modify its environment. These are directly conflicting safety signals on a tool whose whole purpose is instrumenting a live controller, so the description undercuts rather than clarifies the structured hints.

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?

Two sentences, front-loaded with the verb and target, followed by the output inventory. The single-sentence output list is dense but each item earns its place by telling the agent what data comes back; only the trailing safety clause is problematic, not the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not re-explain return values, and it usefully summarizes what is reported. However, for a long-running sampling tool (default duration_s=10) it omits whether the call blocks for the full duration, what load it places on the target task, and what prerequisites must hold before calling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the four parameters (cycle_ms, instance, duration_s, task_index) are documented only by bare titles. The description explains duration_s ('for duration_s') and loosely ties task_index to 'the FB's cost on the task,' but cycle_ms (sampling resolution) and instance (which FB instance, and in what notation) are left entirely unexplained, which is a real gap for a profiling tool where sampling rate matters.

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 (profile) and resource (an FB instance) and enumerates exactly what it produces: leaf recordings, task timing samples, most-active symbols, pulse rates, state dwell timelines, silent symbols, and task cost. This is specific enough to separate it from siblings such as rec_profile_start, ads_watch, or wf_debug_symbol.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the phrasing ('Profile an FB instance for duration_s'), so an agent can infer this is the deep-profiling entry point, but there is no explicit when-to-use vs when-not, and no mention of alternatives or prerequisites (e.g. needing an established ADS connection or a running task). The sibling set contains several overlapping profiling/recording tools that are never referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wf_project_overviewA
Read-only

Orientation in one call: index summary, programs with call trees, FBs with interfaces, GVLs/DUTs, lint summary, git state.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that many facets are bundled into a single call, but says nothing about cost, size, or freshness of the aggregated data. With annotations carrying safety and an output schema carrying returns, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence leading with the core idea ('Orientation in one call') followed by a dense enumeration of covered facets. No filler, every listed item earns its place.

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?

For a zero-parameter aggregator with an output schema, the description tells the agent what the payload covers, which is enough to call it correctly. What it lacks is a note on relative cost/volume of pulling every facet at once, the one piece of context an agent would want before invoking it as a first step.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which per the rubric sets a baseline of 4. There is no parameter behavior for the description to clarify or omit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb-adjacent concept ('orientation') and enumerates exactly what the call aggregates: index summary, programs with call trees, FBs with interfaces, GVLs/DUTs, lint summary, git state. This is clearly distinguishable from granular siblings like proj_lint or proj_call_graph, but the description never explicitly names those siblings, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Orientation in one call' implies this is a starting-point/aggregate tool, which is genuine usage context. However, it gives no explicit when/when-not guidance and does not name any alternative (e.g. use proj_lint for just lint, proj_scan for a scan) to route the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wf_release_checkA
Idempotent

Go/no-go before a deploy: git changes, build result, lint, source-vs-runtime, TcUnit result on the target, task health. Writes nothing to the PLC.

NameRequiredDescriptionDefault
run_buildNo
lint_rulesNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover safety (idempotent, non-destructive) but leave readOnlyHint=false, which reads as 'this mutates something.' The description resolves that by scoping the mutation claim: 'Writes nothing to the PLC,' and lists the verifications performed. It still omits prerequisites (connected target? open solution?) and whether checks fail-fast or all report.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, and the operative purpose plus check list are front-loaded before the safety note. Optimal density for a composite tool.

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?

An output schema exists, so return values need not be described, and all three params are optional. The description covers what is checked and the PLC write-scope, which is most of what an agent needs; only environmental prerequisites for running the check are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. The checklist items map loosely onto the params (build result -> run_build, lint -> lint_rules, source-vs-runtime/TcUnit on target -> plc_project_path), giving inferable semantics, but defaults (run_build=true) and the null semantics of lint_rules/plc_project_path are never explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope: a go/no-go release check, then enumerates the exact signals it aggregates (git changes, build result, lint, source-vs-runtime, TcUnit on target, task health). Very clear what it does, though it never names or distinguishes itself from the sibling checks it composes (tcunit_run, proj_vs_runtime, proj_lint).

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?

"Go/no-go before a deploy" gives an unambiguous usage trigger. There is no when-not guidance or named alternative (e.g. running individual checks instead), but the context is clear enough to select the tool correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_activate_configurationA
Destructive

ActivateConfiguration on the current target (overwrites the boot project on the IPC). Destructive-class. Follow with xae_restart_twincat.

NameRequiredDescriptionDefault
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=false, so safety class is known. The description still adds real value beyond them by specifying what is overwritten (the boot project on the IPC) and that a restart must follow. It does not state permission requirements or reversibility, so 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and its consequence before the follow-up instruction. No filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the destructive consequence plus restart sequencing are covered. However, the confirm_token parameter — plausibly a required confirmation gate for a destructive operation — is entirely unexplained, and 'current target' is never defined, leaving a real gap for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single confirm_token parameter, and the description never mentions it. For a destructive-class tool whose only parameter is apparently a confirmation gate, an agent is left guessing its format and purpose. The description should have compensated for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('ActivateConfiguration') on a specific target ('the current target') and immediately names the consequence ('overwrites the boot project on the IPC'). An agent understands the operation without opening the schema. It does not explicitly distinguish itself from the nearby xae_boot_project or xae_deploy siblings, so it stops short of a 5.

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?

Provides a concrete sequencing rule: 'Follow with xae_restart_twincat,' which tells the agent the activation is not a terminal step. It also labels the operation 'Destructive-class,' which is a usage warning. It does not say when NOT to use it or name alternatives to activation, so no 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_attachA
Idempotent

Attach to the running XAE shell / Visual Studio (Running Object Table) that has the solution: solution_path when given (from then on every xae_* tool works on it — flagged solution_mismatch when it is not xae.solution_path), else xae.solution_path. A solution no shell has open is never replaced by another one (refused, or launch=true starts a shell with it); several shells with different solutions and none named or configured: refused. If the solution is closed later, every xae_* tool refuses until it is open again (in any shell — they find it by themselves).

NameRequiredDescriptionDefault
launchNo
progidNo
solution_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish that this is not read-only, is idempotent, and is non-destructive. The description adds substantial behavioral context beyond that: attaching changes the target for every xae_* tool, mismatch is flagged against xae.solution_path, ambiguous shells are refused, and all xae_* tools refuse after the solution is closed until it is reopened.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core attach behavior and every clause carries operational meaning, but the first sentence is a dense run-on with nested parentheticals that make the conditions hard to parse. It would benefit from clearer structure or bullets even though it is not padded with fluff.

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?

For a stateful attach tool with an output schema, it covers the important lifecycle behavior: default solution selection, mismatch signaling, ambiguous refusal, launch alternative, and the effect of closing the solution. The main remaining gap is the unexplained progid parameter, but the overall attachment model is complete enough for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 parameter meaning. It does explain solution_path semantics and the launch=true behavior, but progid is not mentioned at all, leaving one of three parameters undocumented.

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?

It names a specific verb, attach, and a precise resource, the running XAE shell / Visual Studio instance via the Running Object Table that has a given solution. The contrast with opening a solution is implicit in 'running shell' and is clear enough for an agent to distinguish this from xae_open_solution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It specifies the selection logic explicitly: use the provided solution_path when given, otherwise fall back to xae.solution_path. It also states refusal conditions for no open shell and ambiguous multiple-shell cases, and names launch=true as the alternative when no shell has the solution open.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_boot_projectB
Idempotent

Boot project settings: set Autostart and/or GenerateBootProject (local, no activate unless activate_after_generate=true, which is then destructive-class).

NameRequiredDescriptionDefault
generateNo
autostartNo
confirm_tokenNo
plc_project_pathYes
activate_after_generateNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety baseline is covered. The description adds genuine value by disclosing that setting activate_after_generate=true escalates the call to destructive-class, a condition the static annotation cannot express. It stops short of explaining the confirm_token flow or permission prerequisites for that escalation.

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?

A single dense sentence that front-loads the core action and places the risk condition after it. Every clause carries information, though the parenthetical is terse enough to require rereading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. What is missing is how confirm_token is obtained and what plc_project_path must point at, gaps that matter for a mutation tool with a destructive escalation path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 compensate and it only partially does, mapping 'Autostart', 'GenerateBootProject' and 'activate_after_generate' to their parameters. The critical confirm_token and the required plc_project_path are never explained, leaving the destructive path's mechanics undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Boot project settings') and names the settings it writes (Autostart, GenerateBootProject), so the agent knows this mutates boot configuration. It does not differentiate itself from siblings like xae_activate_configuration or xae_deploy, leaving the boundary to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides one conditional rule ('no activate unless activate_after_generate=true, which is then destructive-class'), which implies when the risky path applies. There is no explicit when-to-use vs alternatives guidance against the many xae_* siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_buildA
Idempotent

Build the solution. save_first (default) runs File.SaveAll, saves whatever the shell still reports unsaved, and checks that every xae_pou_set / xae_pou_create edit of this session is in the source files — it refuses to build otherwise (an external reload would discard the edits). Returns success, error/warning items with file:line (VS error list, or parsed from the Build output pane) and the output tail. check_all_objects=true runs PLC 'Check all objects' instead (compiles unused POUs). After a build of 0 errors, link_check names the GVLs nothing in the source references (TwinCAT does not link them: no symbol on the target) unless they carry {attribute 'linkalways'}.

NameRequiredDescriptionDefault
cleanNo
rebuildNo
save_firstNo
check_all_objectsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds real behavioral context beyond them: save_first runs File.SaveAll and refuses to build if session edits are not persisted in source files, plus what the result contains (error/warning items with file:line, output tail). The link_check behavior is disclosed but the mechanism is left ambiguous.

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 purpose is front-loaded in the first two words, and each subsequent sentence carries information (guard behavior, return shape, alternative mode, link diagnostics). It is dense and somewhat parenthetical-heavy, but no sentence is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the description need not re-explain return values, yet it does so usefully. The real gap is that two of four parameters (clean, rebuild) are undocumented and the link_check reference is orphaned from the schema, leaving an agent uncertain about non-default configuration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 burden of explaining the four parameters. It explains save_first and check_all_objects well, but clean and rebuild are never mentioned, and it references a "link_check" behavior that has no corresponding parameter, which could confuse an agent about what is configurable.

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 opening "Build the solution" states a specific verb and resource, and the surrounding detail (VS error list / Build output pane, PLC compile semantics) makes it unmistakably the build tool among siblings like xae_command or proj_lint. An agent can identify it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contrasts the default save_first path with check_all_objects=true, which is genuine selection guidance, but it frames these as internal options rather than telling the agent when to reach for xae_build versus alternatives such as xae_command or xae_plc. No exclusions or prerequisites for invoking it are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_commandB
Destructive

Execute an arbitrary DTE command (e.g. 'PLC.Login'). Control-class; commands whose name contains download/reset/activate/restart/delete/remove/shutdown are destructive-class.

NameRequiredDescriptionDefault
argsNo
nameYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, so the bar is lower, yet the description adds real value by defining which command names fall into the destructive class. It does not, however, explain what confirm_token is for or what triggers a confirmation requirement, leaving a behavioral gap for a destructive-capable tool.

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?

Two dense sentences with no filler, and the core action is front-loaded ahead of the classification rule. Slightly clunky punctuation around "(e.g. 'PLC.Login'). Control-class;" but nothing wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic, destructive-capable command executor with 0% parameter documentation, the description should explain how args are passed and when confirm_token is required. The output schema covers return values, so that omission is acceptable, but the input-side gaps are significant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters, and the description only implicitly touches 'name' via an example. The format of 'args' (a free-form string — quoting, separators, positional ordering) and the purpose/requiredness of 'confirm_token' are entirely undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Execute an arbitrary DTE command', with a concrete example ('PLC.Login'). It is clearly distinguishable from xae_list_commands (which enumerates) and from typed siblings like xae_build or xae_plc, though it never names those alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The destructive-class naming heuristic (download/reset/activate/restart/delete/remove/shutdown) implicitly tells the agent when an operation is risky, which is genuine contextual guidance. However, there is no guidance on when to prefer this raw escape hatch over typed siblings such as xae_build, xae_activate_configuration, or xae_restart_twincat, and nothing about prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_deployA
Destructive

Save → build → (boot project autostart on) → activate → restart, in one call. Stops at the first build error. Destructive-class (one confirmation covers all steps). Refuses when the XAE target and the ADS target of this server differ. Done = the target runs the new configuration: in RUN and a restart proven (steps.verify.transition_by): 'poll' (another state seen after the commands), 'mode_change' (it was not in RUN before the activation), 'witness' (task 1's cycle counter went back, or the PLC application's compile timestamp changed). In RUN without such proof is reported as that, not as 'not in RUN'.

NameRequiredDescriptionDefault
skip_buildNo
confirm_tokenNo
plc_project_pathNo
allow_target_mismatchNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false): it explains the confirmation model, the fail-fast-on-build-error behavior, the target-mismatch refusal condition, and precisely defines the success state via steps.verify.transition_by ('poll', 'mode_change', 'witness'). This is substantive behavioral disclosure an agent could not infer from the schema alone.

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-loads the pipeline and then the caveats; every clause carries meaning. The 'Done =' sentence and steps.verify.transition_by jargon are dense but necessary and not redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value exposition is not required, yet the description still usefully defines the success proof. Annotations already declare the destructive profile. The remaining gap is that two parameters (skip_build, plc_project_path) and how to obtain a valid confirm_token are left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for all four parameters. The description implicitly covers confirm_token ('one confirmation') and allow_target_mismatch ('refuses when the XAE target and the ADS target differ'), but says nothing about skip_build or plc_project_path, so it only partially compensates for the coverage gap.

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 composite action ('Save → build → (boot project autostart on) → activate → restart, in one call') for a named resource. It clearly differentiates itself from siblings like xae_build, xae_activate_configuration and xae_restart_twincat by being the orchestrator of the whole chain.

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 concrete use conditions and constraints: stops at the first build error, one confirmation covers all steps, and it refuses when the XAE and ADS targets differ. It doesn't explicitly name a single-step alternative for when you only want part of the pipeline, but the composite framing implies the boundary well.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_diagnosticsB
Read-only

Current XAE Error List (errors/warnings/messages with file:line — TwinCAT's own entries too, read from the list view when the automation interface reports none; this focuses the Error List window) merged with the Build output pane, plus the pane's tail, without rebuilding. source names where each part came from.

NameRequiredDescriptionDefault
tail_linesNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds real context beyond them: it merges two sources, includes TwinCAT's own entries, falls back to the list view, and explicitly does not trigger a rebuild. These are behavioral traits an agent needs and cannot get from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the main resource, but the single rambling sentence stacks parentheticals and an em-dash aside, and the trailing fragment '`source` names where each part came from' is disconnected from the main clause. Information is present but the structure is heavier than needed.

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?

An output schema exists, so return values need not be spelled out, and the description still usefully mentions the `source` field. For a single-parameter read-only diagnostics tool, the description conveys the key behavior (merged sources, no rebuild). The only real omission is the meaning of tail_lines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the sole parameter (tail_lines, default 200) is undocumented in the schema. The description's phrase 'plus the pane's tail' only loosely gestures at this parameter and never explains that it controls how many tail lines are returned or what the default is, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource: read the current XAE Error List (errors/warnings/messages with file:line) merged with the Build output pane. It distinguishes itself from xae_build by stating it works 'without rebuilding'. The dense parentheticals and the odd 'this focuses the Error List window' clause make the core purpose slightly harder to extract than it should be.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the tool for inspecting build/error diagnostics. The only explicit conditional is an internal implementation fallback ('read from the list view when the automation interface reports none'), which is about how it reads, not when the agent should choose it over siblings like xae_build or tc_audit_tail. No when-not guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_dialog_resolveA
Destructive

Click a button on an open XAE dialog ('OK', 'Yes', 'No', 'Cancel'…). remember=true adds an auto-answer rule for that title (never for machine-affecting prompts). Control-class; machine-affecting prompts (activate/run/download/login/delete/safety) are destructive-class. A window that is not a standard dialog is pressed through UI Automation; one whose buttons cannot be read is refused (close it in XAE) — never closed by the tool.

NameRequiredDescriptionDefault
hwndNo
buttonYes
rememberNo
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond annotations: auto-answer rules, which prompts are destructive-class, UIA fallback behavior, refusal for unreadable buttons, and an explicit guarantee that the tool never closes the window itself. This is exactly the behavioral detail an agent needs for a destructive, non-idempotent tool.

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 core action is front-loaded, and every clause carries safety or behavior information. It is slightly dense and semicolon-heavy, but not padded or redundant.

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?

Covers the difficult parts: destructive classification, auto-answer restrictions, UIA fallback, and refusal behavior. An output schema exists, so return values need not be explained, but the missing hwnd and confirm_token semantics keep it short of fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 parameter meaning. It explains button examples and remember semantics well, but hwnd and confirm_token are not mentioned at all, leaving two of four parameters undocumented.

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: clicking a button on an open XAE dialog. It is clearly distinct from the sibling xae_dialogs, which presumably lists dialogs, and the examples make the action concrete.

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?

Explains the remember=true condition and explicitly excludes machine-affecting prompts from auto-answer. It does not explicitly say to call xae_dialogs first or when to use this versus xae_dialogs, but the context is otherwise clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_dialogsA
Read-only

Modal dialogs currently open in the attached XAE shell (title, class, text, buttons), the watchdog's auto-answer rules and its recent log. A pending dialog blocks every COM call. Any window that holds the shell modal (its main window disabled) is listed, whatever its class (WPF About / Options, WinForms): its buttons read through UI Automation, or buttons null + buttons_note when they cannot be read; unidentified when the shell is modal but no window could be named.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses real behavioral detail: a pending dialog blocks all COM calls, buttons are read via UI Automation, unreadable buttons yield null plus a buttons_note, and an 'unidentified' state exists when the shell is modal but no window can be named. These edge-case disclosures materially help an agent interpret results.

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?

Content is dense and front-loaded with the core fact (open dialogs block COM calls) before the edge-case caveats. Some parenthetical asides (WPF About / Options, WinForms) add flavor that could be trimmed, but overall every sentence carries 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 an output schema present, the description needn't restate return values, and it covers the critical operational fact (blocking) and known ambiguity states. The only notable omission is routing to xae_dialog_resolve for remediation, which keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to document; baseline 4 applies. The description correctly focuses on output shape instead of inventing parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource set: modal dialogs open in the XAE shell plus the watchdog's auto-answer rules and log, enumerating the fields returned (title, class, text, buttons). It is clearly an inspection/list tool and distinct from mutation siblings, though it never names xae_dialog_resolve, the obvious counterpart, so separation is only implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The line 'a pending dialog blocks every COM call' gives a strong implied reason to call this before other XAE operations, but the description never explicitly says when to call it or that xae_dialog_resolve is the tool for acting on a found dialog. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_io_disableA
Idempotent

Set/clear the Disabled flag on I/O devices under TIID (all, or the named ones) so a configuration activates without the hardware present — TcUnit on a PC, dry runs.

NameRequiredDescriptionDefault
onlyNo
disableNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds the meaningful effect (toggling a flag so configs activate without hardware), but says nothing about required prerequisites, what happens to devices not matched by names, or error behavior when TIID is unreachable.

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?

A single front-loaded sentence with the action first and the motivation trailing after the em-dash; every clause carries information. Dense but not padded, and no redundant restatement of the name or annotations.

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?

An output schema exists, so return values need not be described, and the annotations carry the mutation/idempotency profile. The description covers purpose, params and rationale adequately for a two-param toggle; only edge-case behavior (unmatched names, failure modes) is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 the params — and it largely does: 'Set/clear' maps to the boolean `disable` and 'all, or the named ones' maps to `only`, including the null default meaning all. It does not specify the expected name format or scope of the name strings, so one detail is left to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair ('Set/clear the Disabled flag on I/O devices under TIID') plus the operational rationale. It is not a tautology and an agent can tell this is a device-flag mutation, though it never names a sibling to contrast with (e.g. xae_activate_configuration or xae_target).

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 a concrete when-to-use context ('so a configuration activates without the hardware present — TcUnit on a PC, dry runs'), which tells the agent the precondition of absent hardware. It stops short of naming a when-not condition or an alternative tool for the same goal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_library_addA
Idempotent

Add a library reference (AddLibrary): library by name, version ('' = '*', the newest installed) and distributor, or by display name 'Tc2_Math, * (Beckhoff Automation GmbH)'. XAE refuses a bare name: a missing distributor / version is completed from the installed libraries (ScanLibraries) — refused when the library is not installed, is installed from several distributors and none is given, or a pinned version is not installed. Refused when it is already referenced. Runs once; the result has the references before / after, XAE's messages, and build_required — it never builds. guarded: confirmation tc_request_confirmation(action='xae_library_add', target=':').

NameRequiredDescriptionDefault
libraryYes
versionNo
distributorNo
confirm_tokenNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses important behavior: the call runs once, never builds, may complete missing version/distributor data from installed libraries, and is guarded by tc_request_confirmation. This is exactly the kind of operational context an agent needs for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded, starting with the action and accepted forms before covering validation, refusal conditions, execution behavior, and confirmation. Every sentence adds operational value for a complex tool.

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?

Although an output schema exists, the description still summarizes the result fields and build_required, and it fully covers mutation behavior, refusal conditions, and confirmation guarding. Nothing essential for correct invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning, and it does for library, version, and distributor, including the special version value '' = '*' and display-name syntax. It also implies plc_project_path via the confirmation target format and confirm_token via the guard, but those two parameters are not explicitly named and explained.

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 description gives a specific verb and resource: add a library reference. It also explains the accepted library forms by name/version/distributor or display name, which distinguishes this from list, installed, and remove siblings.

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?

It clearly describes the operational context and refusal conditions, including ScanLibraries completion, ambiguous distributors, missing pinned versions, and duplicate references. It does not explicitly name sibling alternatives such as xae_library_installed or xae_library_remove, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_library_installedB
Read-only

The libraries installed in the repositories XAE uses (ScanLibraries): name, version, distributor — every version of a library. name filters (part of the name, any case).

NameRequiredDescriptionDefault
nameNo
max_itemsNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description usefully notes it returns every version of a library, but says nothing about the 500-item default cap, truncation behavior, or what plc_project_path changes.

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?

Two short sentences, front-loaded with what the tool returns before the filter detail. Slight awkwardness in the em-dash aside, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return shapes need not be explained, and the tool is non-mutating. Still, two of three parameters and the result-cap behavior are unexplained, leaving an agent to guess the meaning of max_items and plc_project_path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. It does explain the key one — name matches a partial name, any case — which the bare schema title does not, but max_items and plc_project_path are left completely undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: lists libraries installed in the repositories XAE uses, with the ScanLibraries reference and the fields returned (name, version, distributor). It is nearly distinguishable from xae_library_list/proj_libraries via 'installed in the repositories', but never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The name-filter behavior is described, implying usage for lookups, but there is no explicit statement of when to use this versus xae_library_list, xae_library_repositories or proj_libraries. Usage must be inferred from the words 'installed' and 'repositories'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_library_listA
Read-only

The library references of a PLC project as XAE holds them now (TE1000 ITcPlcLibraryManager): libraries (name, version, distributor) and placeholders (default and effective resolution — '*' and what it resolves to). Flags a library referenced twice and a version that is not installed (ScanLibraries; check_installed=false skips it), and the references and requested versions that differ from the saved .plcproj (unsaved changes; an unsaved resolve / freeze cannot be seen). plc_project_path: plc_path, iec_project_path or instance_path — needed when the solution has more than one PLC project.

NameRequiredDescriptionDefault
check_installedNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only safety profile, yet the description still adds real behavioral detail: it flags duplicate references, uninstalled versions and drift from the saved .plcproj, and explicitly discloses a blind spot ('an unsaved resolve / freeze cannot be seen') plus the ScanLibraries side effect behind check_installed. Cost/performance or output shape are not discussed, keeping it short of a 5.

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?

Every clause carries information and the purpose is stated first, but the text is a run-on of parentheticals and em-dashes that is harder to parse than it needs to be. No sentence is wasted, though readability could be improved with separation into discrete points.

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?

Both optional parameters are semantically covered, the scanning behavior is explained, and an output schema exists so return values need not be described. What remains missing is routing guidance relative to the many library-related siblings, which matters given how crowded that namespace is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 the load, and it does: plc_project_path is explained as accepting plc_path, iec_project_path or instance_path, and check_installed=false is described as skipping the installed-version check. Types and defaults still come only from the schema, so it stops short of full compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and scope: library references "as XAE holds them now (TE1000 ITcPlcLibraryManager)", covering both libraries (name, version, distributor) and placeholders with default/effective resolution. The 'live vs saved .plcproj' framing implicitly separates it from file-based tools, but no sibling is named outright, so differentiation must be inferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage conditions are given only indirectly: plc_project_path is 'needed when the solution has more than one PLC project' and check_installed=false skips the installed-version scan. There is no statement of when to prefer this over xae_library_installed, proj_libraries or xae_library_repositories, leaving the choice to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_library_removeA
Destructive

Remove a library or placeholder reference (RemoveReference). A name referenced more than once (a library and a placeholder of the same name, two versions) is refused until kind ('library' / 'placeholder') or version says which ('#X' = the placeholder X). RemoveReference itself takes a name (and a library's version): which of a placeholder and a library of one name XAE removes is checked afterwards and said. Code that uses it does not build any more — said, nothing in the code is changed. Destructive-class: tc_request_confirmation(action='xae_library_remove', target=':' + ' ()' and ', ' when given).

NameRequiredDescriptionDefault
kindNo
libraryYes
versionNo
distributorNo
confirm_tokenNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the destructiveHint annotation: it discloses that code using the removed reference will no longer build while nothing in the code itself is modified, that ambiguous names are refused, and that the tool is confirmation-gated via tc_request_confirmation with the required action/target string format. These are exactly the side effects and auth prerequisites an agent needs before invoking a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core intent is front-loaded in the first clause, but the text is dense, parenthesis-heavy, and reads as translated prose with repeated hedging ('said', 'checked afterwards and said'). Several clauses could be tightened without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the confirmation workflow is documented. However, for a 6-parameter destructive mutation with zero schema descriptions, leaving distributor and confirm_token undefined is a meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load. It does explain kind ('library'/'placeholder') and version ('#X' = the placeholder X) and ties plc_project_path into the confirmation target, but distributor and confirm_token are never explained, and the relationship between version and distributor is left unstated.

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 (remove) and resource (library or placeholder reference) and pins down the exact underlying operation (RemoveReference). It also pre-empts the main ambiguity an agent will hit — same-named libraries vs placeholders — which no sibling tool description covers, letting the agent distinguish this from xae_library_add, xae_placeholder_add, or xae_unlink.

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 a concrete conditional rule: a name referenced more than once is refused until kind or version disambiguates, and '#X' selects placeholder X. That is real when-to-do-what guidance, but it never routes the agent to alternatives (e.g., xae_placeholder_resolve or xae_unlink for other reference kinds).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_library_repositoriesA
Read-only

The library repositories XAE uses, in priority order (name, folder). Where this XAE's Automation Interface does not give them, it says so — nothing is guessed.

NameRequiredDescriptionDefault
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds real behavioral context beyond that: results come back in priority order and, crucially, the tool reports absence rather than guessing when the Automation Interface does not expose the data. That no-fabrication guarantee is exactly the kind of trait annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the returned data shape front-loaded; nothing is redundant. The second sentence is slightly indirect but earns its place by disclosing the no-guessing guarantee.

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?

An output schema exists, so the return structure needn't be explained, and the description covers ordering and the missing-data behavior. The only real omission is any hint about the plc_project_path parameter's role or default behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single optional parameter (plc_project_path) with 0% schema description coverage, and the description never mentions it, so an agent cannot tell whether omitting it targets the active project or what path format is expected. With only one parameter the gap is tolerable but uncompensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('library repositories XAE uses') and the shape of the result ('in priority order (name, folder)'). It does not name the sibling it differs from (xae_library_list, xae_library_installed, proj_libraries), so an agent must infer the distinction, but the verb+resource is concrete enough to select it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no mention of the closely related siblings such as xae_library_list or xae_library_installed, which an agent would reasonably confuse with this tool. Usage is only implied by the description of what it returns.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_list_commandsB
Read-only

List DTE command names containing a substring (to discover what this shell exposes).

NameRequiredDescriptionDefault
limitNo
containsNoPLC

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds the introspection intent but says nothing about result volume, truncation, or how the limit interacts with a large command set — relevant context that annotations do not supply.

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?

A single front-loaded sentence with the filter scope stated before the parenthetical rationale. Nothing is wasted, though it is arguably too terse given the undocumented defaults.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value documentation is not required. However, for a tool with two unannotated parameters and surprising defaults (contains='PLC', limit=200), the description leaves the agent guessing about default filtering and result capping.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 both parameters. It conceptually explains 'contains', but ignores 'limit' entirely and never warns that 'contains' silently defaults to 'PLC', a non-obvious default that will filter results unexpectedly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List DTE command names') plus the filtering dimension ('containing a substring'), which is enough to distinguish it from a generic command executor. It gestures at the sibling relationship by framing this as discovering 'what this shell exposes', but never names xae_command as the tool that actually runs a command.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical 'to discover what this shell exposes' implies the intended discovery/introspection use case. There is no explicit when-not guidance and no named alternative, so the agent must infer that this is the read-only precursor to xae_command.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_open_solutionB
Idempotent

Open a .sln in the attached shell.

NameRequiredDescriptionDefault
pathYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety/mutation profile is largely covered. The description adds only the implicit precondition that a shell must be attached; it says nothing about what happens on failure, whether the solution replaces the current project state, or whether it triggers a build/load.

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?

A single short sentence with the action front-loaded and no filler. It is efficient, though brevity here shades into under-specification rather than tight, information-dense writing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required, but the lone parameter is undocumented and the dependency on a prior attach is only implied. For a simple one-parameter tool that is minimally adequate, not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single required 'path' parameter, so the description carries the full burden and fails to add anything: no expected format (.sln extension, absolute vs relative, escaping). An agent must guess what a valid path looks like.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (Open) and resource (.sln solution file) and clarifies the operating context ('in the attached shell'). It does not, however, distinguish this from nearby siblings like xae_boot_project or xae_attach, so an agent must infer which entry point applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this versus xae_attach, xae_boot_project, or xae_activate_configuration, and no prerequisites (e.g. that a shell must already be attached). The phrase 'attached shell' hints at a precondition but never states it or tells the agent what to do if none exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_placeholder_addB
Idempotent

Add a placeholder (AddPlaceholder) with its default library (library '' = the device's placeholder of that name; a library's missing distributor / version is completed as in xae_library_add). target=':'.

NameRequiredDescriptionDefault
libraryNo
versionNo
distributorNo
placeholderYes
confirm_tokenNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare that this is a non-read-only, idempotent, non-destructive mutation. The description adds useful behavioral context about default library handling and missing distributor/version completion, but it does not explain confirm_token, permission requirements, or side effects.

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 compact and front-loads the core action: adding a placeholder. The target-format note is useful but slightly cryptic, and the parenthetical default-library explanation is dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a mutation with six parameters and 0% schema description coverage, so more context would help. The annotations and output schema reduce the burden, and the description covers key default-library semantics, but it is incomplete on usage, confirmation behavior, and several parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 parameter meaning. It explains library '' default behavior and how missing distributor/version are completed, and it mentions target formatting, but it leaves most of the six parameters—especially confirm_token and plc_project_path—undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: adding a placeholder via AddPlaceholder, including default-library semantics and target formatting. It clearly distinguishes the operation itself, though it does not explicitly differentiate it from sibling tools such as xae_placeholder_resolve or xae_placeholder_freeze.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not state when to use this tool versus xae_placeholder_resolve, xae_placeholder_freeze, or xae_library_add. It explains one default-library behavior but provides no when-to-use or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_placeholder_freezeB
Idempotent

Freeze a placeholder (all when placeholder is left out) at the version it resolves to now (FreezePlaceholder): '' no longer follows newer installed versions. target=':' ('' for all).

NameRequiredDescriptionDefault
placeholderNo
confirm_tokenNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=false, idempotent=true, destructive=false, and the description adds real behavioral context by explaining the '*' version-pinning semantics. However, it says nothing about the confirm_token parameter, which implies a confirmation workflow (a tc_request_confirmation sibling exists), nor about re-freeze behavior or permissions.

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 verb and resource, and every clause adds substantive meaning about version pinning and target format. The redundant '(FreezePlaceholder)' restatement and the compressed target notation are minor wastes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the core mutation semantics are covered. But for a write tool with an unexplained confirm_token and an ambiguous relationship between the target string and the two separate parameters, an agent could not reliably construct a confirmed call from this alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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. It explains placeholder (omitted = all, '*' = all), but completely omits confirm_token, and its 'target=<iec project path>:<placeholder>' notation conflates the separate plc_project_path and placeholder parameters into one string, leaving the actual argument mapping ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Freeze a placeholder') and immediately defines what freezing means: pinning at the currently resolved version so '*' stops following newer installed versions. That distinguishes it in spirit from xae_placeholder_add/resolve, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'all when placeholder is left out' clause implies the bulk-freeze path, and the effect (no longer following newer versions) hints at when to use it. But there is no explicit when-to-use/when-not framing, no prerequisites, and no pointer to the sibling tools that add or resolve placeholders.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_placeholder_resolveC
Idempotent

Set what a placeholder resolves to (SetEffectiveResolution): library, version ('' or '*' = newest), distributor (completed from the installed libraries when not given). The result checks the effective resolution after it. target=':=' + ', ' when given.

NameRequiredDescriptionDefault
libraryYes
versionNo
distributorNo
placeholderYes
confirm_tokenNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare non-read-only, idempotent, non-destructive, so safety is largely covered. The description adds genuinely useful behavior: empty or '*' version means newest, distributor is auto-filled from installed libraries, and the resolution is re-checked after the call. It omits the confirm_token/authorization requirement, which is the biggest behavioral unknown for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with real content and the action is front-loaded, but the awkward line break, dangling parenthetical, and the orphaned 'target=...' clause make it read like pasted internal notes rather than a clean specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required, but for a 6-parameter mutation tool the description leaves two parameters (confirm_token, plc_project_path) entirely undefined and doesn't explain the confirmation workflow implied by a sibling tc_request_confirmation. That is not enough to call this safely the first time.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 only partially does. It explains version and distributor defaults well, but says nothing about confirm_token or plc_project_path, and the 'target=<iec project path>:<placeholder>=<library>' fragment describes a string format that does not correspond to any parameter in the schema, which risks confusing the caller.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: sets the effective resolution target for a placeholder, and names the underlying API call (SetEffectiveResolution). It is distinguishable from xae_placeholder_add and xae_placeholder_freeze by implication, but never names or contrasts with them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus xae_placeholder_add (declare a placeholder) or xae_placeholder_freeze (pin the resolution), nor on prerequisites such as the confirmation flow implied by the confirm_token parameter. The agent must infer the lifecycle position of this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_plcA
Destructive

PLC online actions: login | logout | start | stop | reset_cold | reset_origin | download. First the Automation Interface (ConsumeXml online commands on ' Project' — no active project needed; plc_project_path when there are several PLC projects), then the shell's DTE commands (names vary by build). download/reset_cold/reset_origin are destructive-class, the rest control-class.

NameRequiredDescriptionDefault
actionYes
confirm_tokenNo
plc_project_pathNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations give only a blanket destructiveHint=true, so the description adds real value by partitioning which actions are destructive (download/reset_cold/reset_origin) versus control-class, and by describing the AI-ConsumeXml-then-DTE fallback mechanism that affects execution. The one notable omission is any mention of confirm_token, which a destructive tool should flag.

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 action list an agent needs first, then the mechanism and risk classification. It is compact, though the ConsumeXml/DTE implementation detail and 'names vary by build' are lower-value minutiae that compete with the more important confirm_token explanation that is missing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no prose, and the description covers the action set and project-path selection. However, for a destructive, non-idempotent multi-action tool with 0% schema coverage, the unexplained confirm_token and absent when-to-use guidance leave gaps an agent would need to close before invoking safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must carry parameter meaning. It usefully explains plc_project_path ('when there are several PLC projects') and effectively enumerates the action values, but confirm_token is never explained despite being prominent for destructive operations, leaving one of three parameters undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('PLC online actions') and enumerates every action the tool exposes (login, logout, start, stop, reset_cold, reset_origin, download), which is essential since the action parameter has no enum in the schema. It is clear what the tool does, but it does not explicitly draw a boundary against plausible siblings like xae_restart_twincat, ads_plc_state, or xae_build.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the action list and the 'destructive-class vs control-class' split signal that this is for controlling PLC runtime state. There is no explicit 'use this when ...' statement, no naming of an alternative tool, and no condition distinguishing it from xae_build/xae_deploy for the download action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_plcopen_exportB
Idempotent

Export PLC objects ('POUs.FB_X', 'DUTs.ST_Y' — folder.object) to a PLCopen XML file.

NameRequiredDescriptionDefault
itemsYes
xml_fileYes
plc_project_pathYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, and the description is consistent with a safe, repeatable file export. However, it adds no behavioral context beyond them – nothing about overwrite behavior if xml_file already exists, permissions, or partial-failure semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with an inline example; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, but three required parameters at 0% coverage are largely undocumented and there is no usage or behavioral guidance for a write-to-file operation. The description is too thin for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 the load. It explains only the 'items' address syntax ('POUs.FB_X' — folder.object) with examples; xml_file and plc_project_path remain entirely undocumented, so it partially compensates at best.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Export PLC objects') plus the output artifact ('PLCopen XML file'), and names the object-address format. It implicitly distinguishes itself from the sibling xae_plcopen_import, though it does not explicitly route the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use context, no prerequisite (e.g. an attached/open solution), and no comparison to related export tools such as ads_export, exp_template, or xae_plcopen_import. The agent must infer all of this.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_plcopen_importA
Idempotent

Import a PLCopen XML file into a PLC project (path from xae_plc_projects). option: none | rename | replace | skip (conflict handling). replace: the existing object keeps its place (folder) and identity and gets the imported text. TwinCAT's own replace deletes it and re-creates the import at the project root, so the file is imported as renamed copies (PRG_X_1, header renamed too) and the tool finishes the replace: the copy's header is named back, the texts are checked against the XML, written into the existing object, read back, and the declared name must equal the object's name. Only then is the copy — created by this import, it was not in the tree before — deleted (nothing that existed before the import is ever deleted). Anything not proven → nothing written, the copy kept and named in the error. An object that is not at its place after an import is named (removed / moved). Result: replaced, header_renamed, copies_removed, build_required + objects_to_build (build next).

NameRequiredDescriptionDefault
optionNonone
xml_fileYes
plc_project_pathYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes far beyond the annotations: it explains that nothing pre-existing is ever deleted, that the tool works around TwinCAT's destructive replace by creating a named copy and cleaning it up, and that anything unproven results in nothing being written with the offending copy named in the error. This is exactly the mutation-safety context an agent needs and is consistent with destructiveHint=false and idempotentHint=true.

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 core import statement and option list, with the dense replace walkthrough after. It is long and a touch rambling, but nearly every sentence carries non-redundant safety information, so the size is largely justified.

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 mutation tool whose annotations do not carry safety detail, the description supplies the safety semantics, the option semantics, and even enumerates result fields (replaced, header_renamed, copies_removed, build_required, objects_to_build) that point the agent toward the build step. Nothing essential is missing despite the weak schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 compensate; it does so well for 'option' by listing all four valid values (none/rename/replace/skip) even though the schema declares no enum, and hints where plc_project_path comes from ('path from xae_plc_projects'). 'xml_file' remains semantically unexplained, so it falls short of full compensation.

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+resource ('Import a PLCopen XML file into a PLC project') and immediately routes to the sibling that supplies the path (xae_plc_projects), clearly distinguishing it from xae_plcopen_export. An agent can identify the operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It enumerates the conflict-handling options (none | rename | replace | skip) and elaborates heavily on replace, which implicitly tells the agent when to pick each option. However, it never states when to use this tool versus the related sibling xae_tree_consume_xml, nor any prerequisite like requiring an open project.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_plc_projectsA
Read-only

PLC projects in the TwinCAT project with their tree paths (needed by PLCopen / boot tools).

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds that the returned data includes tree paths and that downstream tooling depends on it, but says nothing further about behavior. With annotations carrying the load, this is adequate at a 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the core resource front-loaded and the prerequisite note kept in a parenthetical. Every clause earns its place; nothing is padded.

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?

For a zero-parameter, read-only listing tool with an output schema already defined, the description supplies what an agent needs to select it. The only shortfall is naming which specific sibling tool consumes the tree paths, but the return format need not be restated given the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to disambiguate; per the rubric this is a baseline 4. The description appropriately adds no fictional parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource set (PLC projects in the TwinCAT project) and a distinguishing attribute (their tree paths), so an agent knows what it yields. The verb is implicit rather than stated ('list/retrieve'), but the scope is unambiguous. It does not explicitly contrast with the similarly named sibling xae_plc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical '(needed by PLCopen / boot tools)' implies a usage context — call this to obtain paths before xae_plcopen_import/export or xae_boot_project — but it never states when to use it directly or what alternatives exist. Usage is implied rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_pou_createA
Idempotent

Create a PLC object under a folder/POU. kind = program | fb | function | method | property | action | transition | struct | enum | union | alias | gvl | interface | itf_method | itf_property | folder | parameter_list, and accessors on their own: property_get | property_set (under a property) | itf_property_get | itf_property_set (under an interface property). A property / itf_property is created with its accessors (accessors='get,set' default, 'get' or 'set'): without one it does not compile (C0373). return_type: function, method, property; access: PUBLIC | PRIVATE | PROTECTED | INTERNAL. Optional code is set after creation.

NameRequiredDescriptionDefault
kindYes
nameYes
accessNo
extendsNo
languageNost
accessorsNoget,set
implementsNo
declarationNo
parent_pathYes
return_typeNo
implementationNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=false, destructive=false and idempotent=true, so safety is covered; the description adds real behavioral value by disclosing the accessor requirement for property kinds, the resulting compile error C0373, and the ordering constraint that implementation code must be set after creation. It omits what happens on a name collision or whether an existing object is overwritten, which keeps it from a 5.

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?

A single dense paragraph that front-loads the core action before the kind enumeration and constraints; nearly every clause carries operational information. The long pipe-delimited kind list is bulky but is the primary semantic payload the schema lacks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the annotations carry the safety profile. Still, for an 11-parameter creation tool with zero schema descriptions, the omission of extends/implements/declaration/implementation semantics leaves the agent inferring how to build inheritance and body content.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 11 parameters, so the description carries the full burden; it defines the most consequential ones (kind with a full value enumeration, accessors default and semantics, access, return_type), which is substantial added meaning since the schema's kind is a bare untyped string. But extends, implements, declaration, implementation, language, parent_path and name are left undocumented in both places, leaving a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (create a PLC object under a folder/POU) and enumerates the full set of creatable kinds, so the agent knows exactly what can be produced. It does not explicitly differentiate itself from siblings like xae_pou_get or xae_pou_set, which would have made it a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It supplies a genuine usage constraint ('A property / itf_property is created with its accessors ... without one it does not compile (C0373)') and hints at a workflow boundary ('Optional code is set after creation'), implying xae_pou_set handles code. However, it never names an alternative tool or states when-not to use this one, so guidance remains implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_pou_getB
Read-only

Declaration/implementation text of a POU/DUT/GVL/interface tree item and its methods/properties/actions.

NameRequiredDescriptionDefault
pathYes
include_subitemsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds that the result spans declaration AND implementation text plus nested methods/properties/actions, which is genuinely useful scoping context, but it says nothing about path resolution or error behavior.

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?

A single, front-loaded sentence with no filler. It is efficient, though the absence of a verb makes the opening slightly less scannable than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and annotations cover safety. However, for a tool whose only required parameter is an undocumented path string, the definition is thinner than the task demands.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 compensate. It hints at what 'subitems' means (methods/properties/actions), indirectly clarifying include_subitems, but leaves the required 'path' parameter completely unexplained—no format, root, or delimiter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (a POU/DUT/GVL/interface tree item) and specifies the returned content (declaration/implementation text, including methods/properties/actions). It is clear what the tool retrieves, though it never states a verb and does not distinguish itself from close siblings like xae_tree_get or proj_get_code.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use statement, no prerequisites, and no routing to alternatives despite many overlapping siblings (xae_tree_get, proj_get_code, infosys_declaration, xae_pou_set). The agent must infer the use case entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_pou_setA
Idempotent

Replace declaration and/or implementation text of a POU item inside the live shell (no file round-trip, XAE keeps LineIds consistent). Build afterwards.

NameRequiredDescriptionDefault
pathYes
declarationNo
implementationNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnly=false, idempotent=true, destructive=false), so the bar is lower. The description still adds non-obvious behavior: edits happen in-place in the live shell, LineIds are kept consistent, and a build is required afterwards — useful context an agent would not get from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the verb and resource, with the parenthetical and the 'Build afterwards' note each carrying distinct value. Nothing is padded or redundant.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description implies the POU must already exist and that a build follows, but omits failure behavior and path format, leaving a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters, so the schema supplies no meaning. The description clarifies that declaration and implementation are the editable payloads and may be set individually or together, but says nothing about the required 'path' parameter or its expected format, leaving the most important parameter undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (replace) acting on a specific resource (declaration and/or implementation text of a POU item), and scopes it with 'inside the live shell (no file round-trip)'. This differentiates it from file-based siblings like proj_set_code, though it does not name an alternative tool explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'no file round-trip' implicitly signals when to prefer this over file-editing tools, and 'Build afterwards' gives the required follow-up step. However, no explicit when-not conditions or named alternative tools are given, so usage remains inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_restart_twincatC
Destructive

StartRestartTwinCAT on the current target (runtime restarts in RUN mode). Destructive-class.

NameRequiredDescriptionDefault
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true and non-idempotent, so the 'Destructive-class' label largely repeats structured data. The description does add real behavioral context — the runtime restarts in RUN mode on the current target — but omits impact/downtime, permission needs, and how the confirm token gates execution.

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?

One compact sentence with the action front-loaded; no filler. Slight waste in 'Destructive-class,' which restates the destructiveHint annotation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described, but for a destructive restart of an industrial runtime the definition leaves key operational facts unexplained: the confirm-token requirement, downtime/state loss, and how to recover if the restart fails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter (confirm_token) with 0% schema description coverage, so the description carries the full burden and says nothing about it. Given a sibling tc_request_confirmation exists, the omission of how the token is obtained and whether it is optional is a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names the verb (restart) and the resource (TwinCAT runtime) and clarifies the target scope (current target). It is distinguishable from build/deploy/mode-setting siblings, though the odd casing of 'StartRestartTwinCAT' and the 'XAE' prefix add noise rather than precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus alternatives such as tc_set_mode, ads_system_mode, or xae_activate_configuration. No mention of preconditions (confirmation flow, project attachment) or when not to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_statusA
Read-only

Shell version, open solution, projects, TwinCAT project name, target NetId, started flag. Attaches to the shell first if not attached yet (as every xae_* tool does). solution_bound: the solution the xae_* tools work on; solution_mismatch / refused: it is not open (they refuse); reattached: it was found in a shell again.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds real value on top: the auto-attach side effect, the fact that this call can establish the solution the other xae_* tools operate on, and the refusal semantics when no solution is open. What is missing is any indication of latency, failure modes, or cost of the attach step.

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 returned fields are front-loaded in a single dense line, followed by the attach caveat and the state glossary, so an agent gets the essentials immediately. The key/value phrasing ('solution_bound: ...', 'solution_mismatch / refused: ...') is terse but slightly telegraphic compared to prose.

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 an output schema present, the description is not obliged to explain return values, yet it still glosses the meaningful state names, and it covers the auto-attach behavior that an agent must anticipate. It is complete enough to call correctly; only a clearer tie-break against xae_attach and the diagnostic siblings would improve it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. The description appropriately spends no space on parameter documentation and instead uses that room for return-state semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence enumerates exactly what the tool reports: shell version, open solution, projects, TwinCAT project name, target NetId, and started flag, which makes the resource and scope unmistakable. However, it never explicitly distinguishes itself from nearby siblings like xae_attach or xae_dialogs, so an agent must infer that this is the passive state-read while xae_attach is the explicit attach action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The note that it 'attaches to the shell first if not attached yet (as every xae_* tool does)' implicitly tells the agent it need not call xae_attach beforehand. The solution_bound / solution_mismatch / refused / reattached vocabulary helps interpret results but does not state when this tool should be chosen over the siblings. Usage is implied rather than prescribed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_targetB
Destructive

Get (net_id=None) or set the target AMS NetId of the TwinCAT project. Setting is control-class.

NameRequiredDescriptionDefault
net_idNo
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds 'Setting is control-class', which flags the mutation path as a higher-consequence control operation, useful context layered on top of destructiveHint=true. It does not, however, explain the destructive impact, any authorization/permission needs, or how the confirm_token confirmation flow behaves. Annotations cover the safety profile, so the lower bar is met but not exceeded.

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?

Two tight sentences with no filler; the dual-mode behavior is front-loaded and the control-class caveat trails directly after. Efficient without being truncated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained. But for a destructive, non-idempotent mutation tool, the confirm_token parameter and the meaning of 'control-class' are left unexplained, leaving the agent without enough to safely execute the set path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must carry the full parameter burden. It does explain the meaningful net_id=None get semantics, but confirm_token is never mentioned at all, leaving a required-for-control-class-flow parameter completely undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair (get/set the target AMS NetId of the TwinCAT project) and clarifies its dual-mode nature. It is comprehensible on its own, though it does not differentiate itself from the many sibling xae_* and tc_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the parameter pattern: 'net_id=None' triggers a get, providing net_id triggers a set. However, there is no explicit when/when-not guidance, no named alternatives, and no indication of the conditions under which the control-class set path should be exercised.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_tree_consume_xmlB
Idempotent

ConsumeXml on a tree item — the generic write path for any configuration (add I/O boxes, link variables, set task cycle time, add project routes on TIRR …).

NameRequiredDescriptionDefault
xmlYes
pathYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds real value by enumerating the kinds of mutations this path performs, but it says nothing about failure behavior, partial application, or why a generic XML write is idempotent when it 'adds' elements.

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?

One sentence, front-loaded with the core action and then justified by concrete examples. The parenthetical list is long but every item earns its place by clarifying the breadth of 'any configuration'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described. But for a generic XML write against an engineering tree, the accepted XML dialect/format is the single most important thing an agent must know, and the description never addresses it even though schema coverage is 0%.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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, yet it documents neither parameter. 'On a tree item' loosely implies path is a tree node, and 'ConsumeXml' loosely implies xml is the configuration payload, but no format, encoding, or dialect for the XML is given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair ('ConsumeXml on a tree item') and quantifies the scope as 'the generic write path for any configuration', which separates it from narrower siblings like xae_tree_set_values and xae_tree_create_child. It stops short of explicitly naming those siblings as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical examples (I/O boxes, variable links, task cycle time, TIRR routes) give a good feel for when this tool applies, and 'any configuration' signals broad applicability. However, it never says when NOT to use it or when the targeted siblings (xae_tree_set_values, xae_tree_create_child, xae_links) would be preferable, which an agent needs before defaulting to a generic write.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_tree_create_childB
Idempotent

Generic CreateChild (tree item types/subtypes per Infosys). For PLC objects prefer xae_pou_create.

NameRequiredDescriptionDefault
infoNo
nameYes
beforeNo
subtypeYes
parent_pathYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds only that subtypes come from an Infosys catalog; it says nothing about side effects, whether the parent must exist, or the notable idempotency claim for a create operation.

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?

Two sentences, zero filler, with the purpose and the sibling routing front-loaded. Terse to the point of under-specification, but there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described, but a 5-parameter creation tool with 0% schema coverage and only two lines of description leaves too much undocumented. The description does not compensate for the missing parameter semantics or creation preconditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for all 5 parameters (info, name, before, subtype, parent_path), so the description must carry the burden and largely does not. The only hint is that subtype values follow 'Infosys' definitions, leaving parent_path, name, before, and the untyped 'info' object entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (create a child tree item) and explicitly routes PLC-object cases to xae_pou_create, which distinguishes it from at least one sibling. The parenthetical 'tree item types/subtypes per Infosys' is cryptic and leans on external catalog knowledge, keeping it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The one-line exclusion ('For PLC objects prefer xae_pou_create') gives real routing guidance, but there is no general statement of when to use this generic creator versus xae_tree_consume_xml, xae_plcopen_import, or other tree-construction tools. Implied usage rather than complete guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_tree_deleteB
Destructive

Delete a tree item (POU, box, task …). Destructive-class; the confirmation names the item: tc_request_confirmation(action='xae_tree_delete', target='<parent_path>^').

NameRequiredDescriptionDefault
nameYes
parent_pathYes
confirm_tokenNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, so 'Destructive-class' is largely redundant. What earns credit is the non-obvious workflow disclosure: that a confirmation must name the item via tc_request_confirmation with target='<parent_path>^<name>'. It still omits whether deletion is irreversible or affects children.

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?

Two sentences, front-loaded with the action and its scope, then the confirmation detail. Minor waste in 'Destructive-class', which merely restates the destructiveHint annotation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, for a destructive tool with 0% schema coverage, the description leaves the confirm_token mechanism (how the token is obtained and passed) and parameter formats unaddressed, which is a meaningful gap for a two-step operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden, yet it only partially compensates. The '<parent_path>^<name>' target format implicitly ties the two required params together, but the confirm_token parameter is never mentioned and no path syntax or format guidance is given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Delete') and resource ('a tree item'), with concrete examples (POU, box, task) that scope what kind of node is targeted. It is distinguishable from write-oriented siblings like xae_tree_set_values or xae_tree_create_child, though it never explicitly names an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage through the destructive framing and the required confirmation step, but gives no explicit when-to-use/when-not guidance and does not contrast with sibling tree tools. The confirmation prerequisite is useful context but is not a usage rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_tree_getA
Read-only

System Manager tree item: properties, children to depth, and ProduceXml when xml=true. Path syntax 'TIPC^Plc^Plc Project^POUs^MAIN' (xae_plc_projects gives the ' Project' path; its children POUs/DUTs/GVLs are walked even though the node itself reports no ChildCount). Roots (ITcSysManager::LookupTreeItem shortcuts): TIIC (I/O Configuration), TIID (its I/O Devices), TIRC (Real-Time Configuration), TIRT (its Additional Tasks), TIRS (its Real-Time Settings), TIRR (its Route Settings), TIPC (PLC Configuration), TINC (NC Configuration).

NameRequiredDescriptionDefault
xmlNo
pathYes
depthNo
max_itemsNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only safety profile, so the bar is lower, yet the description adds real behavioral context: the ChildCount quirk (children are walked even though the node reports no ChildCount) and that xml=true triggers ProduceXml. That quirk disclosure is valuable and goes beyond structured data; it stops short of describing pagination/truncation behavior tied to max_items.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action in the first sentence, then dense supporting detail on path syntax and root shortcuts. The root list is long but each entry (code + human name) earns its place as directly callable navigation anchors; there is no filler.

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?

An output schema exists, so return values needn't be explained, and annotations cover safety. The description supplies path grammar, roots, and the ChildCount quirk, making it largely self-sufficient; only max_items semantics and any truncation behavior remain unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must carry parameter meaning and it partially does: path (with syntax and example), depth ('children to `depth`'), and xml (Produces ProduceXml). max_items is never explained despite a 2000 default, leaving one of four parameters undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('System Manager tree item: properties, children to `depth`, ProduceXml when xml=true'), so an agent knows it retrieves a node's properties and subtree. It references the sibling xae_plc_projects as the source of the '<Name> Project' path, but does not explicitly distinguish itself from xae_tree_consume_xml or xae_tree_set_values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides strong path-construction guidance (concrete example path, the xae_plc_projects linkage, and the full list of root shortcuts), which implies how to use the tool. However, it never states when to prefer this over the other tree tools (consume_xml, set_values, create_child) or any exclusions, so usage is inferred rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xae_tree_set_valuesB
Idempotent

Set element texts in a tree item's XML by relative XPath, e.g. {'TaskDef/CycleTime': '10000'} (unit 100 ns).

NameRequiredDescriptionDefault
pathYes
assignmentsYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a mutating (readOnlyHint=false), idempotent, non-destructive write, so the safety profile is covered. The description adds the unit semantics of the value (100 ns), which is genuinely useful, but says nothing about persistence, whether unlisted elements are preserved, or the required connection state — a notable gap for a mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence plus an inline example, front-loaded with the action and immediately followed by the concrete format. Nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema means return values need no explanation, and the value format is conveyed. However, for a mutation tool with a required `path` parameter at 0% schema coverage, the definition leaves the anchor of the XPath (which tree item, which document) unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 burden. It does document the `assignments` shape well via the example (relative XPath key → string value), but the required `path` parameter — what path, relative to which tree item — is never explained in either place.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: sets element texts inside a tree item's XML via relative XPath, which is clearly distinct from read-oriented siblings (xae_tree_get, xae_tree_consume_xml) and the structural siblings (xae_tree_create_child, xae_tree_delete). It stops short of explicitly naming those siblings, so it is clear but not self-differentiating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The example shows how to call it but gives no when-to-use guidance, no prerequisites (must a solution/project be attached?), and no pointer to the sibling to use for reading or bulk-consuming XML instead. Usage must be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 11 tool updatesv0.8.19
    • Addedxae_library_add
    • Addedxae_library_installed
    • Addedxae_library_list
    • Addedxae_library_remove
    • Addedxae_library_repositories
    • Addedxae_link
    • Addedxae_links_import
    • Addedxae_placeholder_add
    • Addedxae_placeholder_freeze
    • Addedxae_placeholder_resolve
    • Addedxae_unlink
  2. 7 tool updatesv0.8.18
    • Changedhw_search3 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"items per page, 1-100; a larger limit is used as 100 (clamped: true)"
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • addedInput schema / properties / offset
        Added value: +{
        +  "default": 0,
        +  "description": "skipped first: the next page is offset=<next_offset>",
        +  "minimum": 0,
        +  "title": "Offset",
        +  "type": "integer"
        +}
    • Changedinfosys_get_page5 fields changed
      • addedInput schema / properties / max_chars / description
        Added value: +"characters shown, 200-60000; read on with section= or offset="
      • addedInput schema / properties / max_chars / maximum
        Added value: +60000
      • addedInput schema / properties / max_chars / minimum
        Added value: +200
      • addedInput schema / properties / offset
        Added value: +{
        +  "default": 0,
        +  "description": "skipped first: the next page is offset=<next_offset>",
        +  "minimum": 0,
        +  "title": "Offset",
        +  "type": "integer"
        +}
      • addedInput schema / properties / section
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Section"
        +}
    • Changedinfosys_search3 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"hits per page, 1-50; a larger limit is used as 50 (clamped: true)"
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • addedInput schema / properties / offset
        Added value: +{
        +  "default": 0,
        +  "description": "skipped first: the next page is offset=<next_offset>",
        +  "minimum": 0,
        +  "title": "Offset",
        +  "type": "integer"
        +}
    • Changedinfosys_search_code3 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"results shown, 1-50"
      • addedInput schema / properties / limit / maximum
        Added value: +50
      • addedInput schema / properties / limit / minimum
        Added value: +1
    • Changedinfosys_search_symbols3 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"results shown, 1-50"
      • addedInput schema / properties / limit / maximum
        Added value: +50
      • addedInput schema / properties / limit / minimum
        Added value: +1
    • Changedrec_start1 field changed
      • addedInput schema / properties / scope_disconnect
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "boolean"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Scope Disconnect"
        +}
    • Changedscope_record1 field changed
      • addedInput schema / properties / confirm_token
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Confirm Token"
        +}
  3. 38 tool updatesv0.8.12
    • Changedads_export1 field changed
      • addedInput schema / properties / overwrite
        Added value: +{
        +  "default": false,
        +  "title": "Overwrite",
        +  "type": "boolean"
        +}
    • Addedhw_diag
    • Addedhw_lookup
    • Addedhw_module
    • Addedhw_object
    • Addedhw_search
    • Changedinfosys_search_code1 field changed
      • addedInput schema / properties / ignore_spacing
        Added value: +{
        +  "default": false,
        +  "title": "Ignore Spacing",
        +  "type": "boolean"
        +}
    • Changedipc_list_dir1 field changed
      • changedInput schema / properties / max_entries / default
        Previous value: -500New value: +100
    • Addedkb_add_project
    • Addedkb_rebuild
    • Addedkb_reindex
    • Addedkb_remove_project
    • Addedkb_search
    • Addedkb_set_location
    • Addedkb_status
    • Addedproj_libraries
    • Addedrec_capture
    • Changedrec_delete1 field changed
      • addedInput schema / properties / confirm_token
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Confirm Token"
        +}
    • Changedrec_export2 fields changed
      • addedInput schema / properties / fill
        Added value: +{
        +  "default": false,
        +  "title": "Fill",
        +  "type": "boolean"
        +}
      • addedInput schema / properties / overwrite
        Added value: +{
        +  "default": false,
        +  "title": "Overwrite",
        +  "type": "boolean"
        +}
    • Changedrec_list2 fields changed
      • addedInput schema / properties / limit
        Added value: +{
        +  "default": 30,
        +  "title": "Limit",
        +  "type": "integer"
        +}
      • addedInput schema / properties / offset
        Added value: +{
        +  "default": 0,
        +  "title": "Offset",
        +  "type": "integer"
        +}
    • Changedrec_profile_start1 field changed
      • addedInput schema / properties / align
        Added value: +{
        +  "default": true,
        +  "title": "Align",
        +  "type": "boolean"
        +}
    • Changedrec_read1 field changed
      • addedInput schema / properties / fill
        Added value: +{
        +  "default": false,
        +  "title": "Fill",
        +  "type": "boolean"
        +}
    • Changedrec_start8 fields changed
      • addedInput schema / properties / allow_partial
        Added value: +{
        +  "default": false,
        +  "title": "Allow Partial",
        +  "type": "boolean"
        +}
      • addedInput schema / properties / also_scope
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "boolean"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Also Scope"
        +}
      • addedInput schema / properties / cycle_counter
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": "auto",
        +  "title": "Cycle Counter"
        +}
      • addedInput schema / properties / edge_triggers
        Added value: +{
        +  "default": false,
        +  "title": "Edge Triggers",
        +  "type": "boolean"
        +}
      • addedInput schema / properties / engine
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Engine"
        +}
      • addedInput schema / properties / max_delay_ms
        Added value: +{
        +  "default": 0,
        +  "title": "Max Delay Ms",
        +  "type": "number"
        +}
      • addedInput schema / properties / post_trigger_s
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "number"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Post Trigger S"
        +}
      • addedInput schema / properties / scope
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Scope"
        +}
    • Changedrec_stats1 field changed
      • addedInput schema / properties / exact
        Added value: +{
        +  "default": false,
        +  "title": "Exact",
        +  "type": "boolean"
        +}
    • Addedrec_verify
    • Addedscope_export
    • Addedscope_list
    • Addedscope_record
    • Addedscope_status
    • Addedtc_allow_write
    • Changedtc_doctor1 field changed
      • addedInput schema / properties / verbose
        Added value: +{
        +  "default": false,
        +  "title": "Verbose",
        +  "type": "boolean"
        +}
    • Addedtc_reload_config
    • Changedtc_request_confirmation1 field changed
      • addedInput schema / properties / args
        Added value: +{
        +  "anyOf": [
        +    {
        +      "additionalProperties": true,
        +      "type": "object"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Args"
        +}
    • Changedtc_session_report2 fields changed
      • addedInput schema / properties / inline
        Added value: +{
        +  "default": false,
        +  "title": "Inline",
        +  "type": "boolean"
        +}
      • addedInput schema / properties / overwrite
        Added value: +{
        +  "default": false,
        +  "title": "Overwrite",
        +  "type": "boolean"
        +}
    • Changedtc_set_mode1 field changed
      • addedInput schema / properties / confirm_token
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Confirm Token"
        +}
    • Changedtcunit_run1 field changed
      • addedInput schema / properties / save_first
        Added value: +{
        +  "default": true,
        +  "title": "Save First",
        +  "type": "boolean"
        +}
    • Changedxae_plc1 field changed
      • addedInput schema / properties / plc_project_path
        Added value: +{
        +  "anyOf": [
        +    {
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "default": null,
        +  "title": "Plc Project Path"
        +}
    • Changedxae_pou_create1 field changed
      • addedInput schema / properties / accessors
        Added value: +{
        +  "default": "get,set",
        +  "title": "Accessors",
        +  "type": "string"
        +}
  4. 139 tool updatesv0.6.0
    • First observedads_add_route_to_plc
    • First observedads_app_info
    • First observedads_call_method
    • First observedads_connect
    • First observedads_discover
    • First observedads_dump
    • First observedads_ethercat
    • First observedads_export
    • First observedads_io_read
    • First observedads_leaves
    • First observedads_list_symbols
    • First observedads_ping
    • First observedads_plc_state
    • First observedads_read
    • First observedads_read_many
    • First observedads_read_raw
    • First observedads_routes
    • First observedads_status
    • First observedads_symbol_info
    • First observedads_system_mode
    • First observedads_task_stats
    • First observedads_types
    • First observedads_wait_until
    • First observedads_watch
    • First observedads_write
    • First observedads_write_many
    • First observedads_write_raw
    • First observedexp_abort
    • First observedexp_compare
    • First observedexp_evaluate
    • First observedexp_get
    • First observedexp_list
    • First observedexp_report
    • First observedexp_run
    • First observedexp_runs
    • First observedexp_save
    • First observedexp_status
    • First observedexp_template
    • First observedexp_validate
    • First observedhmi_bindings
    • First observedhmi_scan
    • First observedhmi_vs_runtime
    • First observedinfosys_books
    • First observedinfosys_declaration
    • First observedinfosys_get_page
    • First observedinfosys_index
    • First observedinfosys_search
    • First observedinfosys_search_code
    • First observedinfosys_search_symbols
    • First observedipc_delete_file
    • First observedipc_eventlog
    • First observedipc_list_dir
    • First observedipc_read_file
    • First observedipc_reboot
    • First observedipc_start_process
    • First observedipc_write_file
    • First observedproj_call_graph
    • First observedproj_changed
    • First observedproj_get_code
    • First observedproj_interface
    • First observedproj_lint
    • First observedproj_list
    • First observedproj_read_file
    • First observedproj_references
    • First observedproj_resolve_symbol
    • First observedproj_scan
    • First observedproj_search
    • First observedproj_set_code
    • First observedproj_validate_xml
    • First observedproj_variables
    • First observedproj_vs_runtime
    • First observedrec_compare
    • First observedrec_delete
    • First observedrec_export
    • First observedrec_latency
    • First observedrec_list
    • First observedrec_profile_delete
    • First observedrec_profile_get
    • First observedrec_profile_list
    • First observedrec_profile_save
    • First observedrec_profile_start
    • First observedrec_profile_stop
    • First observedrec_pulses
    • First observedrec_read
    • First observedrec_scan
    • First observedrec_snapshot
    • First observedrec_start
    • First observedrec_stats
    • First observedrec_status
    • First observedrec_stop
    • First observedsnap_apply
    • First observedsnap_compare
    • First observedsnap_list
    • First observedsnap_save
    • First observedtc_audit_tail
    • First observedtc_doctor
    • First observedtc_request_confirmation
    • First observedtc_safety_status
    • First observedtc_session_report
    • First observedtc_set_mode
    • First observedtcunit_results
    • First observedtcunit_run
    • First observedtcunit_scaffold
    • First observedtest_expect
    • First observedtest_response
    • First observedtest_scenario
    • First observedtest_stable
    • First observedwf_debug_symbol
    • First observedwf_fb_profile
    • First observedwf_project_overview
    • First observedwf_release_check
    • First observedxae_activate_configuration
    • First observedxae_attach
    • First observedxae_boot_project
    • First observedxae_build
    • First observedxae_command
    • First observedxae_deploy
    • First observedxae_diagnostics
    • First observedxae_dialog_resolve
    • First observedxae_dialogs
    • First observedxae_io_disable
    • First observedxae_links
    • First observedxae_list_commands
    • First observedxae_open_solution
    • First observedxae_plc
    • First observedxae_plc_projects
    • First observedxae_plcopen_export
    • First observedxae_plcopen_import
    • First observedxae_pou_create
    • First observedxae_pou_get
    • First observedxae_pou_set
    • First observedxae_restart_twincat
    • First observedxae_status
    • First observedxae_target
    • First observedxae_tree_consume_xml
    • First observedxae_tree_create_child
    • First observedxae_tree_delete
    • First observedxae_tree_get
    • First observedxae_tree_set_values

TDQS

C2.8/5.0

Scored across 171 tools

Disambiguation2/5

The domain prefixes help, but there are many near-duplicate entry points for capturing or inspecting PLC behavior: rec_start, rec_capture, ads_watch, test_scenario, wf_fb_profile, and exp_run all overlap in purpose. Similarly, several read/write, status, search, and deploy tools have boundaries that are hard to keep straight at 171 tools.

Naming Consistency3/5

All names are snake_case and use stable family prefixes such as xae_, ads_, proj_, and rec_, but verb/object ordering is mixed: xae_pou_get versus xae_pou_create, ads_list_symbols versus ads_read, and proj_get_code versus proj_scan. It is readable, but not one predictable convention.

Tool Count1/5

171 tools is far beyond a well-scoped MCP surface, even for a broad TwinCAT automation domain. Many workflow helpers duplicate compositions of lower-level tools, and the sheer count overwhelms selection.

Completeness4/5

Coverage is unusually broad across shell automation, build/diagnostics, PLC runtime ADS, project files, recordings, tests, experiments, documentation, ESI hardware lookup, HMI, IPC, Scope, and safety. Some lifecycle operations are only reachable through generic escape hatches such as xae_command or tree XML, but no major domain gap is apparent.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    F
    maintenance
    An MCP server for validating, auto-fixing, and scaffolding TwinCAT 3 XML files using deterministic code quality tools and IEC 61131-3 OOP checks. It enables AI assistants to perform structural validation, apply safe fixes, and generate canonical code skeletons for industrial automation projects.
    16
    39
    MIT
  • A
    license
    B
    quality
    B
    maintenance
    MCP server for Beckhoff TwinCAT XAE / TE1000 Automation Interface, enabling control of XAE Shell, TwinCAT tree manipulation, PLC operations, and build actions via natural language.
    25
    21
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables read-only access to Beckhoff TwinCAT PLCs via ADS, allowing queries of device info, symbols, variables, and EtherCAT diagnostics through natural language.
    8
    MIT