twincat-mcp

Overview Schema Source Related Servers Discussions Admin

tc_request_confirmation

Read-only

Issue a single-use confirm_token for a control or destructive TwinCAT tool so guarded operations can proceed. Pass the tool name and its arguments to compute and verify the exact target.

Instructions

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'.

Input Schema

Name	Required	Description	Default
`args`	No
`action`	Yes
`target`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.12Oct 19, 2026

addedInput schema / properties / args

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Args"
+}

First observedv0.6.0Oct 16, 2026

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.

Deploy Server