Sigmatek LASAL MCP Server

Overview Schema Source Related Servers Discussions Admin

lars_runtime

Manage local LARS simulation instances for LASAL stations: set up/start/stop workspaces, redirect station targets to simulated ports, restore real targets, and run no-hardware tests.

Instructions

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.

Input Schema

Name	Required	Description	Default
`name`	No	LARS workspace name (e.g. 'VisuPalletizer_PLC'). Required for start/stop/remove/set_station_target/restore when station is omitted.
`action`	Yes	'list' shows all configured LARS workspaces and their state (auto-cleans stale ones, but never the selected project's). 'setup' creates/updates LARS workspaces for the selected project's stations (or one station/lcp), wiring both the CLASS 2 project and the LASAL SCREEN (.lpr) project so LARS renders the screen locally. 'start' launches a LARS instance (auto-creates the workspace first if the station is known but unconfigured); reports the effective online port it probed (LARS builds differ in which port they serve). 'stop' terminates it, 'remove' deletes its workspace config. 'gc' runs lazy garbage collection: deletes auto-created workspaces that are not running and no longer referenced by any station .lss or published DataService stations.json, while always keeping workspaces of the selected project. 'set_station_target' points a station's .lss at the online port its LARS instance actually services (probed; never a port another running instance owns); 'restore' reverts to the saved real target. 'target_pc' switches an ARM-compiled .lcp to the PC (x86) compile target LARS requires (restore via 'restore'). 'simulate' runs the full no-hardware loop in one call: ensure workspace (auto-creates), switch ARM targets to PC, compile, start the local LARS instance (probing its effective online port), then download to it. 'screenshot' captures the LARS window of a running workspace (returns the PNG) — use it to visually verify LASAL SCREEN projects running locally.
`dry_run`	No	With action 'gc': report what would be removed without deleting anything. Default false.
`station`	No	Station name from the selected project's solution (e.g. 'PLC', 'HMI', 'Local'). Resolution is scoped to the selected project; a station that only exists in another project's workspace is refused, and multiple matches report an ambiguity error and list the candidates. Pass name= to disambiguate. Mutually exclusive with name.
`lcp_path`	No	Absolute path to a .lcp to create a workspace for (setup only, when no station name is usable).
`min_age_h`	No	With action 'gc': only delete workspaces unreferenced for at least this many hours (overrides LASAL_MCP_LARS_GC_MIN_AGE_H; 0 = immediately.
`project_dir`	No	Solution directory to auto-detect stations from and to scope station resolution (setup/list/start/stop/set_station_target/restore/target_pc/simulate. Defaults to the selected project.
`compile_mode`	No	With action 'simulate': CLASS 2 compile mode. Default RebuildAll (safest).	RebuildAll
`skip_compile`	No	With action 'simulate': skip the CLASS 2 compile step (reuse the existing build). Default false.
`skip_download`	No	With action 'simulate': skip the download step (only compile + start). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.3.2Oct 19, 2026

changedInput schema / properties / action / description

Previous value: -"'list' shows all configured LARS workspaces and their state (auto-cleans stale ones). 'setup' creates/updates LARS workspaces for the selected project's stations (or one station/lcp. 'start' launches a LARS instance (auto-creates the workspace first if the station is known but unconfigured), 'stop' terminates it, 'remove' deletes its workspace config. 'gc' runs lazy garbage collection: deletes auto-created workspaces that are not running and no longer referenced by any station .lss or published DataService stations.json. 'set_station_target' points a station's .lss at its LARS instance (127.0.0.1:<port>); 'restore' reverts to the saved real target. 'target_pc' switches an ARM-compiled .lcp to the PC (x86) compile target LARS requires (restore via 'restore')."New value: +"'list' shows all configured LARS workspaces and their state (auto-cleans stale ones, but never the selected project's). 'setup' creates/updates LARS workspaces for the selected project's stations (or one station/lcp), wiring both the CLASS 2 project and the LASAL SCREEN (.lpr) project so LARS renders the screen locally. 'start' launches a LARS instance (auto-creates the workspace first if the station is known but unconfigured); reports the effective online port it probed (LARS builds differ in which port they serve). 'stop' terminates it, 'remove' deletes its workspace config. 'gc' runs lazy garbage collection: deletes auto-created workspaces that are not running and no longer referenced by any station .lss or published DataService stations.json, while always keeping workspaces of the selected project. 'set_station_target' points a station's .lss at the online port its LARS instance actually services (probed; never a port another running instance owns); 'restore' reverts to the saved real target. 'target_pc' switches an ARM-compiled .lcp to the PC (x86) compile target LARS requires (restore via 'restore'). 'simulate' runs the full no-hardware loop in one call: ensure workspace (auto-creates), switch ARM targets to PC, compile, start the local LARS instance (probing its effective online port), then download to it. 'screenshot' captures the LARS window of a running workspace (returns the PNG) — use it to visually verify LASAL SCREEN projects running locally."

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "setup",
-  "start",
-  "stop",
-  "remove",
-  "set_station_target",
-  "restore",
-  "target_pc",
-  "gc"
-]New value: +[
+  "list",
+  "setup",
+  "start",
+  "stop",
+  "remove",
+  "set_station_target",
+  "restore",
+  "target_pc",
+  "gc",
+  "screenshot",
+  "simulate"
+]

addedInput schema / properties / compile_mode

Added value: +{
+  "default": "RebuildAll",
+  "description": "With action 'simulate': CLASS 2 compile mode. Default RebuildAll (safest).",
+  "enum": [
+    "RebuildAll",
+    "BuildChanges"
+  ],
+  "type": "string"
+}

changedInput schema / properties / project_dir / description

Previous value: -"Solution directory to auto-detect stations from (setup/list only. Defaults to the selected project."New value: +"Solution directory to auto-detect stations from and to scope station resolution (setup/list/start/stop/set_station_target/restore/target_pc/simulate. Defaults to the selected project."

addedInput schema / properties / skip_compile

Added value: +{
+  "default": false,
+  "description": "With action 'simulate': skip the CLASS 2 compile step (reuse the existing build). Default false.",
+  "type": "boolean"
+}

addedInput schema / properties / skip_download

Added value: +{
+  "default": false,
+  "description": "With action 'simulate': skip the download step (only compile + start). Default false.",
+  "type": "boolean"
+}

changedInput schema / properties / station / description

Previous value: -"Station name from the solution (e.g. 'PLC', 'HMI', 'Local'). Picks the matching workspace. Mutually exclusive with name."New value: +"Station name from the selected project's solution (e.g. 'PLC', 'HMI', 'Local'). Resolution is scoped to the selected project; a station that only exists in another project's workspace is refused, and multiple matches report an ambiguity error and list the candidates. Pass name= to disambiguate. Mutually exclusive with name."

AddedSep 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only carry openWorldHint=true, so the description does the heavy lifting — and it does: list auto-cleans stale workspaces (never the selected project's), start auto-creates an unconfigured workspace and probes the effective online port, gc is lazy and preserves referenced/selected-project workspaces, set_station_target never claims a port another instance owns, and station resolution is refused for cross-project names and errors on ambiguity. Mutation semantics (remove deletes workspace config, restore reverts .lss) are also explicit.

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?

Front-loaded with the purpose sentence, then the workspace-per-station rule, then an action inventory in one dense block. It is long but proportional to 11 actions; the only waste is partial overlap between the action list in the description and the enum descriptions in the schema.

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?

With no output schema, the description correctly notes what is returned for the two outlier actions (start reports the probed port, screenshot returns the PNG) and covers scoping, auto-creation, and cleanup policies. What it does not cover is failure behavior for the mutating actions in general and any timing/latency expectations for launching an instance.

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 coverage is already 100%, so the baseline is 3; the description adds genuine value on top, noting that name is required for start/stop/remove/set_station_target/restore when station is omitted, that name and station are mutually exclusive, and how station resolution is scoped to the selected project.

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?

States a specific verb+resource ('Manage local LARS (LASAL Runtime System) simulation instances') and enumerates every action with a one-line gloss so an agent can select among them without opening the schema. It also explicitly distinguishes itself from siblings by naming build_project/control_plc/plc_values/deploy_all as the tools that consume the LARS state it sets up.

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?

Gives concrete operating advice ('use one workspace per station (PLC + HMI) so both run simultaneously') and per-action usage context (simulate runs the full no-hardware loop in one call; screenshot is for visually verifying LASAL SCREEN projects). It does not explicitly compare itself to close siblings such as hmi_runtime or when *not* to use LARS, so it falls short of a full when/when-not/alternative statement.

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

lars_runtime

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools