Skip to main content
Glama
Sign In
TIA Portal MCP Server

TIA Portal MCP Server

by BJM1122
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Inspect TIA Hardware, Network and HMI

tia_inspect_engineering
Read-onlyIdempotent

Reads bounded hardware, network, HMI, and PLC-tag data from a V20 session and reports evidence-backed configuration diagnostics without compiling, exporting, modifying projects, or contacting a PLC.

Instructions

Read a bounded hardware/network/HMI/PLC-tag observation from an already prepared exact V20 session and report evidence-backed configuration diagnostics. Includes exposed HMI tags, connections and Unified alarms; classic HMI alarms are explicitly unsupported when not exposed. Never compiles, exports files, changes a project or contacts a PLC.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "processId": "<processId>"
    },
    "name": "tia_inspect_engineering"
  }
}

Input Schema

NameRequiredDescriptionDefault
processIdYes
timeoutMsNo
maxObjectsNo
includeScreensNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.29.1

TDQS

B3.3/5.0
Behavior4/5

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

Beyond the read-only/idempotent/non-destructive annotations, the description adds meaningful behavioral context: it is a bounded observation, requires a prepared V20 session, exposes HMI tags/connections/Unified alarms, and explicitly does not support classic HMI alarms when not exposed. It also rules out compilation, export, project changes, and PLC contact. It does not explain pagination or timeout behavior, but the annotations already cover the core safety profile.

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?

The description is compact and front-loaded, leading with the read scope and immediately following with boundaries. The phrasing is dense and slightly jargon-heavy ('evidence-backed configuration diagnostics'), but every clause carries scope or limitation information.

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

Completeness3/5

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

For a read-only inspection tool with no output schema, the description does a reasonable job explaining scope, supported observations, and unsupported classic HMI alarms. However, the complete absence of parameter semantics for four undocumented inputs leaves a significant completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description never mentions processId, timeoutMs, maxObjects, or includeScreens. The word 'bounded' vaguely hints at limits but does not explain any parameter's meaning, so the description fails to compensate for the undocumented schema.

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?

The description uses a specific verb and resource set: 'Read a bounded hardware/network/HMI/PLC-tag observation' and 'report evidence-backed configuration diagnostics.' It clearly scopes the tool to an 'already prepared exact V20 session,' though it does not explicitly distinguish itself from siblings such as tia_inspect_unified_hmi or tia_analyze_hmi_alarms.

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

Usage Guidelines3/5

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

It states a prerequisite ('already prepared exact V20 session') and a boundary ('Never compiles, exports files, changes a project or contacts a PLC'), implying use for read-only inspection. However, it gives no explicit guidance on when to choose this over sibling inspection or alarm 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