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
} |
| resources | {
"listChanged": true
} |
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. |
| 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. |
| build_projectA | Compile the CLASS 2 project or download it to the PLC. Compilation kills CLASS 2 IDE. Download pings the PLC first. |
| control_plcA | Start, stop, or query PLC runtime state. Pings the target PLC before start/stop. |
| plc_valuesA | 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. |
| plc_diagnosticsB | 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_projectA | 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. |
| deploy_allA | Full deploy pipeline: compile → download PLC → start PLC → verify state → update Visu stations → download Visu → start HMI runtime. Each step is optional via flags. |
| hmi_runtimeA | Start, stop, or check the local HMI web simulation (LasalVISUDataService). Publishes the project, copies webroot, and spawns the DataService. Use hmi_browser to interact with it afterwards. |
| hmi_browserA | Automate a headless Edge browser to test the HMI. Actions: open (navigate), screenshot (capture viewport or element), console (read logs/errors), eval (run JS), click, type, wait, close. ALWAYS use this after deploy to visually verify the HMI works. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
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 |
TDQS
Scored across 14 tools
Tools are largely distinct with detailed descriptions, but there is some overlap in functionality (e.g., control_plc, build_project, and deploy_all all involve starting or downloading to a PLC; hmi_runtime and visu_project both touch the HMI). The descriptions clarify context (real vs. simulation, single step vs. pipeline), so misselection is unlikely but possible.
All tool names follow a consistent snake_case style (e.g., control_plc, build_project, lars_runtime). While not every name follows the verb_noun pattern (lasal_status, plc_values are nouns), the naming convention is uniform and predictable.
14 tools is well-scoped for a complex PLC/HMI development and automation environment. The count covers project management, build/deploy, runtime control, diagnostics, HMI validation, and browser testing without being overwhelming.
The toolset covers the full development lifecycle: project selection, building, downloading, runtime state, diagnostics, HMI runtime management, and browser-based verification. It also includes composite pipelines like deploy_all and granular operations for LARS and VS engine, leaving no obvious gaps for typical tasks.