Sigmatek LASAL MCP Server

Overview Schema Source Related Servers Discussions Admin

deploy_all

Run the full PLC and HMI deploy pipeline in one call: compile, download, start, and verify runtime states, with optional LASAL SCREEN and Visu steps plus async job polling.

Instructions

Full deploy pipeline: compile → download PLC → start PLC → verify state → compile LASAL SCREEN (.lpr, when present) → optional SCREEN download → update Visu stations → download Visu → start HMI runtime. Each step is optional via flags. Supports async: true — the call then returns immediately with a jobId and you MUST poll check_job_status until it reports status completed/failed (the result is delivered there).

Input Schema

Name	Required	Description	Default
`async`	No	Run in the background: returns { status: 'pending', jobId } — poll with check_job_status. Default false.
`compile`	No	Compile the CLASS 2 project. Default true.
`lse_run`	No	Start the screen runtime on the target after download (Download & Run). Default true.
`lcp_path`	No	Absolute path to the .lcp file. Omit to use the selected project.
`lse_path`	No	Absolute path to the .lpr (LASAL SCREEN) project. Omit to auto-detect from the selected project.
`lvp_path`	No	Absolute path to the .lvp file. Omit to auto-detect from the selected project.
`start_plc`	No	Start the PLC runtime after a successful download. Default true.
`timeout_s`	No	Timeout override in seconds for compile and download steps.
`compile_lse`	No	Compile the LASAL SCREEN project (writes the Runtime output folder). Skipped when there is no .lpr. Default true.
`download_lse`	No	Download the LASAL SCREEN project to its station (requires lse_connection or a station target in the solution). Default false.
`download_plc`	No	Download the compiled CLASS 2 project to the PLC. Default true.
`download_visu`	No	Download the VISUDesigner project to the HMI after updating stations. Requires visu_connection. Default false.
`add_plc_loader`	No	Force loader download to PLC even if the target already has a compatible loader. Default: auto — sent for local LARS/loopback targets, skipped otherwise. Set false to disable, true to force.
`lse_connection`	No	SCREEN download target, e.g. 'TCPIP:192.168.1.50'. Omit to resolve from the station that owns the .lpr.
`plc_connection`	No	PLC connection string (e.g. 'TCPIP:192.168.1.100'). Omit to use the connection saved in the project's .lss file.
`compile_options`	No	Compile mode. RebuildAll is safest; BuildChanges is faster for incremental work.	RebuildAll
`visu_connection`	No	HMI connection string (e.g. 'TCPIP:192.168.1.100'). Required when download_visu is true.
`add_visu_runtime`	No	Force runtime download to HMI even if the version already matches.
`start_hmi_runtime`	No	Start the local HMI runtime (DataService) and copy HMI files after a successful compilation/update. Default false.
`visu_download_flags`	No	VISUDesigner download mode: 0=normal (default), 1=changes only, 2=publish+download changes.
`update_visu_stations`	No	Run update_all_stations on the VISUDesigner project to sync datapoints after CLASS 2 changes. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.3.2Oct 19, 2026

removedInput schema / properties / add_plc_loader / default
```
Removed value: -false
```

changedInput schema / properties / add_plc_loader / description

Previous value: -"Force loader download to PLC even if the target already has a compatible loader."New value: +"Force loader download to PLC even if the target already has a compatible loader. Default: auto — sent for local LARS/loopback targets, skipped otherwise. Set false to disable, true to force."

addedInput schema / properties / async

Added value: +{
+  "default": false,
+  "description": "Run in the background: returns { status: 'pending', jobId } — poll with check_job_status. Default false.",
+  "type": "boolean"
+}

addedInput schema / properties / compile_lse

Added value: +{
+  "default": true,
+  "description": "Compile the LASAL SCREEN project (writes the Runtime output folder). Skipped when there is no .lpr. Default true.",
+  "type": "boolean"
+}

addedInput schema / properties / download_lse

Added value: +{
+  "default": false,
+  "description": "Download the LASAL SCREEN project to its station (requires lse_connection or a station target in the solution). Default false.",
+  "type": "boolean"
+}

addedInput schema / properties / lse_connection

Added value: +{
+  "description": "SCREEN download target, e.g. 'TCPIP:192.168.1.50'. Omit to resolve from the station that owns the .lpr.",
+  "type": "string"
+}

addedInput schema / properties / lse_path

Added value: +{
+  "description": "Absolute path to the .lpr (LASAL SCREEN) project. Omit to auto-detect from the selected project.",
+  "type": "string"
+}

addedInput schema / properties / lse_run

Added value: +{
+  "default": true,
+  "description": "Start the screen runtime on the target after download (Download & Run). Default true.",
+  "type": "boolean"
+}

Changed2 schema fields changedSep 7, 2026

addedInput schema / properties / start_hmi_runtime

Added value: +{
+  "default": false,
+  "description": "Start the local HMI runtime (DataService) and copy HMI files after a successful compilation/update. Default false.",
+  "type": "boolean"
+}

addedInput schema / properties / timeout_s

Added value: +{
+  "description": "Timeout override in seconds for compile and download steps.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

First observedv0.1.0Jun 30, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations provide only `openWorldHint: true`, so the description carries most of the burden — and it does disclose the key non-obvious behavior: asynchronous execution returns immediately with a jobId and the real result is delivered via check_job_status, not in this response. It also reveals that steps are skipped conditionally (LSE compile skipped when no .lpr; loader auto-sent only for local loopback targets). It does not disclose partial-failure semantics, whether a failed mid-pipeline deploy leaves the PLC/HMI in an inconsistent state, or permission/auth requirements for a tool that physically writes to and starts hardware.

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 pipeline order and then the async contract — no filler or restated title. The pipeline enumeration is dense but every stage listed corresponds to a real flag, so it earns its space. A short structural break between the pipeline description and the async/mode guidance would improve scanability for a 21-parameter 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?

For a high-complexity, zero-required-parameter tool with no output schema, the description correctly compensates by explaining where the result actually appears (the job record polled via check_job_status) and what the pipeline does end-to-end. Given `openWorldHint: true` and hardware-mutating side effects, it still omits failure/recovery behavior and the deploy_solution relationship, leaving modest gaps for a tool this consequential.

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 100%, so the baseline is 3; the description earns a point by supplying cross-parameter meaning the schema does not — namely the execution ordering of the flags and the fact that any stage can be individually disabled. The async contract is stated in prose as well as in the schema, reinforcing which parameter drives the job/poll flow. It adds nothing, though, about interactions between flags (e.g. start_plc with compile=false).

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 tool's specific action and enumerates the exact pipeline stages in execution order (compile → download PLC → start PLC → verify → LSE compile → SCREEN download → update/download Visu → start HMI), which is far more informative than a generic 'deploy' label. However, it never distinguishes itself from the sibling tool `deploy_solution`, which appears to be a near-overlapping deploy entry point, so an agent cannot tell the two apart from the text alone.

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 operational directive for one mode: with `async: true` the call returns a jobId and the caller 'MUST poll check_job_status until it reports status completed/failed', naming the sibling tool to use. It also states each pipeline step is individually optional via flags, implying the whole-pipeline usage. What is missing is when NOT to use this tool versus `deploy_solution` or the granular per-stage tools like build_project/hmi_runtime.

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

deploy_all

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools