Skip to main content
Glama
Svel26

Sigmatek LASAL MCP Server

by Svel26
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

plc_diagnostics

Runs PLC diagnostics including trace recording, file upload/download/delete, and static code analysis to inspect and maintain Sigmatek LASAL controls.

Instructions

Run PLC diagnostics: trace recording, file upload/download/delete on PLC, or static code analysis.

Input Schema

NameRequiredDescriptionDefault
actionYesPLC diagnostics/maintenance action: trace (DataAnalyzer run), file_upload/file_download/file_delete (files on the control), code_analysis (static analysis on the project or one source file), download_os (install a LasalOS .lbi — control reboots), clear_ram_image, save_project_on_plc (backup the running project on the control), download_connection_file (.lcf).
os_pathNoLasalOS update file (.lbi) to install (download_os action only).
lcp_pathNoAbsolute path to the .lcp file. Omit to use the currently selected project.
plc_pathNoFile path on the PLC (for file upload/download/delete).
timeout_sNoTimeout override in seconds. Defaults: 120s, or 600s for download_os.
connectionNoPLC connection string. Omit to use connection from project's .lss file.
local_pathNoLocal file path on the host (for file upload/download).
config_pathNoAbsolute path to the DataAnalyzer config file (trace action only).
duration_msNoDuration in milliseconds to run the trace (trace action only). Default 5000.
output_pathNoDestination path for the trace output or code analysis result.
source_fileNoAnalyze a single source file instead of the whole project (code_analysis action only).
connection_fileNoOptional .lcf connection file path (download_connection_file action only; omit to use the project's active connection file).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.3.2
    • changedInput schema / properties / action / description
      Previous value: -"PLC diagnostics/maintenance action to perform."New value: +"PLC diagnostics/maintenance action: trace (DataAnalyzer run), file_upload/file_download/file_delete (files on the control), code_analysis (static analysis on the project or one source file), download_os (install a LasalOS .lbi — control reboots), clear_ram_image, save_project_on_plc (backup the running project on the control), download_connection_file (.lcf)."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "trace",
-  "file_upload",
-  "file_download",
-  "file_delete",
-  "code_analysis"
-]New value: +[
+  "trace",
+  "file_upload",
+  "file_download",
+  "file_delete",
+  "code_analysis",
+  "download_os",
+  "clear_ram_image",
+  "save_project_on_plc",
+  "download_connection_file"
+]
    • addedInput schema / properties / connection_file
      Added value: +{
+  "description": "Optional .lcf connection file path (download_connection_file action only; omit to use the project's active connection file).",
+  "type": "string"
+}
    • addedInput schema / properties / os_path
      Added value: +{
+  "description": "LasalOS update file (.lbi) to install (download_os action only).",
+  "type": "string"
+}
    • addedInput schema / properties / source_file
      Added value: +{
+  "description": "Analyze a single source file instead of the whole project (code_analysis action only).",
+  "type": "string"
+}
    • addedInput schema / properties / timeout_s
      Added value: +{
+  "description": "Timeout override in seconds. Defaults: 120s, or 600s for download_os.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
  2. Added

TDQS

C2.9/5.0
Behavior2/5

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

Only openWorldHint is annotated, so the description carries the behavioral burden and largely fails it: it does not disclose that file_delete is destructive, that clear_ram_image wipes the controller's RAM, that save_project_on_plc overwrites a backup, or that download_os reboots the control. Those risk notes exist only partially in the schema's action text, and no permission, auth, or timeout behavior is described in the description itself.

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?

A single front-loaded sentence with no filler; the core purpose and action families come first. It is tight, though it is arguably too terse for nine heterogeneous actions with very different risk profiles.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, 9-action tool with no output schema and only openWorldHint annotated, the description omits critical context: which actions mutate or reboot the PLC, default timeouts, and what each action returns. The action enum in the schema compensates somewhat, but the description alone is not sufficient for safe invocation.

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?

Schema description coverage is 100%, so the schema already documents all 12 parameters including per-action applicability (e.g., os_path for download_os only, duration_ms for trace only). The description adds only the coarse grouping of actions and no additional parameter semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Run) and resource (PLC diagnostics) and enumerates representative sub-actions (trace, file ops, code analysis), so the agent can distinguish it from control_plc and plc_values. However, the enumeration is incomplete — download_os, clear_ram_image, save_project_on_plc, and download_connection_file appear only in the schema's action enum, not the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no alternatives are named, despite siblings like control_plc, plc_values, and lse_project that plausibly overlap. The reader must infer which of the nine actions to pick and when this tool is preferred over the control/runtime tools.

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

Deploy Server

Other Tools