Sigmatek LASAL MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LASAL_CLASS2_EXE | No | Full path to Lasal2.exe (Defaults to C:\Program Files (x86)\Sigmatek\Lasal\Class2\Bin\Lasal2.exe) | C:\Program Files (x86)\Sigmatek\Lasal\Class2\Bin\Lasal2.exe |
| LASAL_VISUDESIGNER_EXE | No | Full path to VISUDesigner.exe (Defaults to C:\Program Files\Sigmatek\Lasal\VISUDesigner\VISUDesigner.exe) | C:\Program Files\Sigmatek\Lasal\VISUDesigner\VISUDesigner.exe |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| select_projectA | Set the active LASAL project by directory path. Call first — all other tools default to this project. |
| lasal_statusA | Check project selection, station discovery, PLC/HMI reachability, engine paths, running processes, and HMI runtime health. Call to orient or diagnose connection issues. |
| check_job_statusA | Poll the status of a background job started with async: true (build_project, deploy_all, deploy_solution, lse_project). Omit jobId to list recent jobs. |
| inspect_projectA | Read-only inventory of the CLASS 2 project: classes (name, channels, tasks), networks and objects, from the .lcp manifest and class sources. Use it to plan changes before apply_project_changes. |
| validate_guidsB | Scan a LASAL station project for duplicate GUID collisions and uninitialized TO_UDINT(0) placeholders in classes. Auto-resolves duplicate GUID collisions (generating fresh GUIDs and updating MaeExp.txt/xml) and populates exact LASAL CRC32 @CT_ hashes. Also cleans dangling network metadata. |
| read_class_sourceA | Read or write a CLASS 2 class source (.st) by class name, with optional .h access. Writes are latin1-validated and require the CLASS 2 IDE to be closed. |
| set_target_ipA | Update the target IP/port/SSL of a station in its .lss (surgical edit, other settings preserved). Use when a station moved networks; connection strings can also be passed per call. |
| manage_class2A | Open or close the LASAL CLASS 2 IDE GUI. Close before running batch operations. |
| manage_visudesignerA | Open or close the VISUDesigner GUI. Close before running automated visu operations. |
| manage_lasalscreenA | Open or close the LASAL SCREEN (LSE) editor for .lpr screen projects. Close before running lse_project automation (releases .lpr file locks). |
| build_projectA | Compile the CLASS 2 project or download it to the PLC. Compilation kills CLASS 2 IDE. Download pings the PLC first. 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). |
| create_class2_bootdiskA | Create a CLASS 2 bootdisk (update stick): plain bootdisk or the full Update-Tool flavor with update script, Autoexec.lsl, LasalOS image, VISUDesigner publish folder and MultiMaster Stations.txt. Platform AUTO/ALL/ARM/X86. |
| control_plcB | Start, stop, or query PLC runtime state. Pings the target PLC before start/stop. |
| plc_valuesB | Read or write live channel values on a running PLC. Channels use 'ObjectName.ChannelName' format. Auto-coerces types based on ST declarations. |
| apply_project_changesA | Run CLASS 2 batch engine operations that cannot be done by editing files directly: create/delete/rename networks, add/remove/rename objects, create/delete connections, set init values, configure tasks, compile, download. Kills CLASS 2 IDE before running. |
| run_class2_scriptA | Escape hatch: run arbitrary Python 2.7 batch statements through Lasal2.exe (module |
| plc_diagnosticsC | Run PLC diagnostics: trace recording, file upload/download/delete on PLC, or static code analysis. |
| lars_runtimeA | Manage local LARS (LASAL Runtime System) simulation instances. LARS runs one program per instance — use one workspace per station (PLC + HMI) so both run simultaneously on separate ports. Actions: list (auto-cleans stale workspaces), setup (create workspaces for all stations), start (auto-creates the workspace if the station is known but unconfigured), stop, remove, gc (lazy cleanup of unreferenced workspaces), set_station_target (point a station's .lss at its LARS instance), restore (revert .lss to the real target. After set_station_target, build_project/control_plc/plc_values/deploy_all operate on the LARS instance automatically. |
| visu_projectB | Run VISUDesigner engine operations: update stations, publish, manage text lists/schemes/media/code modules, set datapoint properties, or download to HMI. These need the VISUDesigner engine — for direct dashboard JSON editing, edit the files in the project directly. |
| lse_projectA | Run LASAL SCREEN (LSE) engine operations on a .lpr screen project via the LASALScreen COM automation: info (screens/windows/servers/text lists/languages/settings inventory), create (fresh project), compile (Runtime output folder), download to a panel (Download & Run), and apply_changes with granular operations: merge/fuse projects, export_xml/import_xml text round-trips, import_variables (CLASS 2 references), textlist_* translations, server_get_property/server_set_property (limits, unit, menu, state schema, hostname, …), bulk update_buttons/update_softkeys theming, settings_set (resolution/compiler/online), image_insert. The .lpr itself is binary — never edit it directly; use this tool or the editor. 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). |
| deploy_allA | 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). |
| deploy_solutionA | Multi-station deploy via MachineManager: generates a .lutc update file from the solution (class2/screen/visu downloads, OS updates, file transfers, run/boot, channel writes, CLI commands) and executes it with MachineManager.exe /update. This is the official flow for pushing LASAL SCREEN projects together with CLASS 2 to the same panel. Use dry_run to review the generated .lutc first. The newest MachineManager per-run log is returned with the result. 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). |
| hmi_runtimeA | Start, stop, or check the local HMI web simulation (LasalVISUDataService). Publishes the project, copies webroot, and spawns the DataService. Returns the accessible HTTP URL (e.g. for testing via Playwright MCP or opening in a browser). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| deploy-checklist | Guided deploy: orient, compile, deploy PLC + HMI (+ LASAL SCREEN), verify. |
| bring-up-simulation | Get a station running locally via LARS without hardware (compile, download, start, screenshot). |
| translate-visu | Round-trip VISUDesigner text lists through CSV for translation. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| LASAL Project Guide | Complete guide to LASAL file formats, file editing, HMI debugging, and the runtime JS API |
| LASAL Project Status | Current project selection, discovered stations, runtime URLs, and configuration |
| LASAL Stations | List of stations in the active LASAL solution and their connection targets |
TDQS
Scored across 23 tools
Most tools target a distinct subsystem (CLASS 2, VISUDesigner, LASAL SCREEN, LARS, HMI, PLC), but there are genuine overlaps: build_project vs deploy_all both compile/download, run_class2_script overlaps apply_project_changes as a broader escape hatch, and the three 'engine operation' tools (visu_project, lse_project) are similar in shape. Descriptions help distinguish them but an agent could misselect among the deploy/build family.
All names use snake_case consistently, which is good. However the verb pattern is mixed: many are verb_noun (build_project, control_plc, manage_class2, set_target_ip) while several are noun_topic (lasal_status, plc_values, lse_project, hmi_runtime), so the convention is readable but not uniform.
23 tools is on the heavier side, but the domain spans multiple engines and deployment pipelines, so each tool has a defensible role. It borders on heavy but avoids redundancy for a system this complex.
Coverage is strong across the lifecycle: project selection/inspection, source editing, batch operations, builds, single- and multi-station deploys, PLC/runtime control, live values, diagnostics, GUID validation, LARS simulation and HMI simulation. Minor gaps remain (e.g. no explicit new CLASS 2 project creation or teardown), but the surface is largely complete and has no obvious dead ends.