Loading ToolBench
MCP server for Siemens TIA Portal automation engineering, exposing ~212 tools for PLC programming, hardware configuration, project management, and cross-reference analysis
Server exposes 4 tools with mixed quality. FindTools and CallTool are meta-discovery tools with clear descriptions and proper parameter schemas (query string, limit integer). GetDeviceItemIoAddresses and SetDeviceItemIoAddress have detailed descriptions explaining hardware concepts (engine raw values, byte offsets) but lack explicit input schema definitions in the visible code. Descriptions are substantive (100-200 chars) and include context about prerequisites and safety. However, parameter type information is not visible in the provided source excerpts, preventing full schema validation. The server includes a dead-reference checker (Check-DeadToolReferences.py) and capability matrix generator, showing attention to consistency, but tool definitions appear to be inferred from attributes rather than explicitly registered with full JSON Schema.
[L0][Meta] Invoke ANY tool in the full roster by name, including ones not listed in this session. Use FindTools first to get the exact name and parameter signature. Behaves exactly like calling the tool directly: same work, same result, same safety checks. Example: name='ExportPlcWatchTable', argumentsJson='{"softwarePath":"PLC_1","watchTableName":"WT1"}'.
[L0][Meta] Search the FULL tool roster (all ~200 tools), including ones not listed in this session. The server ships a ~48-tool 'lite' roster by default so the tool list stays small and every host can load it; everything else is reached through this tool plus CallTool. USE THIS whenever the visible tools do not cover what you need, before concluding the server cannot do something. Search by capability words, not exact names: 'watch table', 'HMI screen', 'download', 'cross reference', 'GSD'. Returns each match's exact name, parameter signature with defaults, and full description; then invoke it with CallTool.
[L2][Hardware] READ-ONLY. List the I/O addresses of one device item (signal module, signal board, built-in CPU I/O). Returns each address as ioType + startAddress + length in ENGINE RAW VALUES (startAddress is the byte offset: %I2.0 is startAddress 2). Use this to confirm an address before and after changing it. Device item path looks like 'PLC_1/DI 8x24VDC_1' — get it from GetDeviceItemTree.
[L2][Hardware][Destructive] Preview or change the I/O START ADDRESS of one device item (e.g. move a DI module to start at %I2.0 by passing startAddress=2). Defaults to dryRun=true. startAddress is the ENGINE RAW byte offset, not '2.0'. It writes hardware configuration, so a wrong value does NOT fail compilation — the program silently reads a different module. Read back with GetDeviceItemIoAddresses, then CompileSoftware and SaveProject. Overlapping address ranges are rejected by TIA and reported back with the reason.
SetDeviceItemIoAddress lacks explicit input schema validation in visible code. Parameter types (deviceItemPath: string, ioType: enum, startAddress: integer, dryRun: boolean) are documented in description but not in a machine-readable JSON Schema structure.
GetDeviceItemIoAddresses and SetDeviceItemIoAddress lack documented output schemas. Callers cannot know what fields to expect in responses, forcing LLMs to guess at result structure and breaking tool chaining.
SetDeviceItemIoAddress is destructive (writes hardware config) but lacks a confirmation/dry-run pattern in the visible schema. While dryRun parameter exists, no explicit confirmation-request or multi-round-trip mechanism is evident.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
ioType parameter in SetDeviceItemIoAddress is documented as 'Input, Output, Diagnosis or Substitute' but not declared as an enum in visible schema, inviting hallucinated values.
Error handling guidance is minimal. SetDeviceItemIoAddress mentions 'Overlapping address ranges are rejected by TIA and reported back with the reason' but no structured error classification (retryable, user-fixable, fatal) is visible.