Sigmatek LASAL MCP Server

Overview Schema Source Related Servers Discussions Admin

deploy_all

Deploy a complete LASAL project to PLC and HMI by compiling, downloading, starting runtimes, updating Visu stations, and verifying state. Each pipeline step can be enabled or skipped via flags.

Instructions

Full deploy pipeline: compile → download PLC → start PLC → verify state → update Visu stations → download Visu → start HMI runtime. Each step is optional via flags.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`compile`	No	Compile the CLASS 2 project. Default true.
`lcp_path`	No	Absolute path to the .lcp file. Omit to use 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.
`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.
`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.

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.2/5.0

Behavior4/5

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

The description transparently lists the main side effects (downloading to PLC, starting PLC, downloading Visu, starting HMI runtime, updating stations). Since no annotations are provided, the description carries the burden, and it does so reasonably well, though it does not explicitly warn about overwriting target systems.

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, well-structured sentence that front-loads the pipeline sequence and immediately notes that every step is optional. It is concise and easy 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?

Given the rich input schema (15 parameters, all described), the brief description is sufficient to convey the overall purpose and flow. It does not need to repeat parameter details, and the pipeline steps align well with the boolean flags in the schema.

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?

The input schema provides descriptions for 100% of parameters, so the baseline applies. The description itself adds little beyond the schema, but the schema's parameter descriptions are detailed and sufficient.

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 clearly identifies the tool as a full deploy pipeline and enumerates the exact sequence of steps it performs (compile, download PLC, start PLC, verify state, update Visu stations, download Visu, start HMI runtime). This distinguishes it from the individual sibling tools that handle only one step.

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 provides clear context: it is a full deployment pipeline, and each step is optional via flags, making it suitable for both full and partial deployments. It does not explicitly name alternative single-step tools, but the pipeline nature is clear enough for an agent to infer when to use it.

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

Deploy Server

deploy_all

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools