TIA Portal MCP Server

Overview Schema Source Related Servers Discussions Admin

Query Current TIA Project Objects

tia_query_live_project

Read-onlyIdempotent

Resolve blocks, PLC data types, tag tables or PLC tags in the running TIA V20 project, returning attributes, cross-reference evidence and block interface or program body.

Instructions

Resolve blocks, PLC data types/UDTs, tag tables or PLC tags in the exact running TIA V20 project through the resident session (attached automatically when Portal is visible). One object: give resourceKind and name; returns direct official attributes, optional CrossReferenceService evidence and, for a block, interface and program body from one temporary XML. Several objects: give queries (up to 50) for a shallower result per object in one call; cross references default off there.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "tia_query_live_project"
  }
}

Input Schema

Name	Required	Description
`name`	No
`number`	No
`queries`	No	Batch form; replaces the single-object fields.
`blockKind`	No
`namespace`	No
`processId`	No	Exact Portal PID; skips the UI observation.
`timeoutMs`	No	Default 20000 for one object (at most 60000), 30000 for queries.
`maxResults`	No	Per object. Default 500 (one object) or 200 (queries, at most 1000).
`maxXmlBytes`	No
`resourceKind`	No
`softwarePath`	No
`tagTableName`	No
`includeRawXml`	No	One block only; needs includeProgramBody.
`interfaceLimit`	No	One object: interface members returned, default 1000.
`includeInterface`	No	One object only; default true.
`refreshInventory`	No
`bodyEvidenceLimit`	No	Program-body evidence rows, default 1000 (queries: 200, at most 1000).
`includeProgramBody`	No	Default false.
`officialIdentifier`	No
`includeCrossReferences`	No	Default true for one object, false for queries.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`status`	Yes
`completeness`	No
`requestedActionCompleted`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.29.1Nov 11, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful behavior beyond that: the session is attached automatically when Portal is visible, results include official attributes and optional cross-reference evidence, block bodies come from one temporary XML, and cross references default off in batch mode.

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 dense but front-loaded, moving from the core purpose to single-object mode and then batch mode. It avoids unnecessary repetition, though the second sentence packs several defaults and return details tightly together.

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?

This is a complex 20-parameter tool, and an output schema exists so return values need less explanation. The description covers the main single-object and batch usage paths, but it leaves several parameters and the interaction between optional fields under-explained relative to the tool's complexity.

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 50%, and the description adds mode-level meaning for resourceKind, name, and the queries batch array with its 50-object cap and cross-reference default. It does not explain several other parameters such as processId, timeoutMs, maxResults, refreshInventory, softwarePath, or namespace beyond what the schema already provides.

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 states a specific verb and resource set: resolve blocks, PLC data types/UDTs, tag tables, or PLC tags in the exact running TIA V20 project through the resident session. It clearly frames the live-project scope, but it does not explicitly differentiate itself from siblings such as tia_search_live_objects or tia_get_current_block.

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 gives useful mode guidance: one object uses resourceKind and name, several objects use queries (up to 50) for shallower per-object results. However, it does not say when to prefer this tool over sibling search or get tools, nor does it state exclusions or prerequisites beyond the automatic session attachment.

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

Deploy Server