Fast TIA Program Lookup

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

Annotations declare readOnlyHint=false but destructiveHint=false and idempotentHint=true, implying some write side-effect, which is consistent with the undocumented autoBuild parameter but is never explained in the description. The description does add useful behavior ('single cached call', one call spanning six data domains), but it never says what autoBuild does or that a lookup may mutate/build the index. No contradiction, but the mutating side is left opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the capability list and the batching semantics front-loaded; every clause carries information. The enumeration is long but each item names a distinct data domain, so little could be cut without losing scope detail.

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

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

With no output schema, the description should convey something about result shape, yet it only implies returns via the list of domains and says nothing about how six heterogeneous result types are structured. The autoBuild default (true) and its mutation implication are also unexplained, leaving meaningful gaps for a 4-parameter tool with partial schema coverage.

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

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

Schema coverage is only 50% (exportDir and query have no schema descriptions), and the description compensates well for query by explaining it can be one string or up to 50 strings of block aliases, symbols, or addresses resolved together. It still adds nothing for exportDir, and limit/autoBuild are handled only by the schema itself.

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

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

The description gives a specific verb ('lookup') and enumerates the exact resource domains covered: block inventory, call edges, symbol definitions, read/write references, data flows, and engineering notes, scoped to an indexed S7-1200/S7-1500 export. It is far more specific than a tautology, but it never contrasts itself with plausible siblings such as tia_get_graph_context or tia_inspect_engineering, so an agent must infer which lookup tool to pick.

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

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

Usage is only implied: 'One-call lookup' plus 'resolved together in a single cached call' signals this is the batch/federated search entry point. There is no explicit when-to-use statement, no exclusions, and no mention of when to prefer a narrower sibling tool instead.

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