Skip to main content
Glama
Svel26

Sigmatek LASAL MCP Server

by Svel26

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LASAL_CLASS2_EXENoFull 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_EXENoFull 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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}
completions
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 batch, project prj in scope). Use for batch API calls not covered by apply_project_changes; the project is NOT saved automatically.

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

NameDescription
deploy-checklistGuided deploy: orient, compile, deploy PLC + HMI (+ LASAL SCREEN), verify.
bring-up-simulationGet a station running locally via LARS without hardware (compile, download, start, screenshot).
translate-visuRound-trip VISUDesigner text lists through CSV for translation.

Resources

Contextual data attached and managed by the client

NameDescription
LASAL Project GuideComplete guide to LASAL file formats, file editing, HMI debugging, and the runtime JS API
LASAL Project StatusCurrent project selection, discovered stations, runtime URLs, and configuration
LASAL StationsList of stations in the active LASAL solution and their connection targets

TDQS

A3.6/5.0

Scored across 23 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessResponsive