Skip to main content
Glama

hw_lookup

Read-only

EtherCAT device data from the ESI index (index\esi.db: the ESI files in the knowledge folder's manuals\ and TwinCAT's ESI folders): name, product code, revisions, E-bus current, mailbox, DC modes, sync managers, PDOs with every entry…

Instructions

EtherCAT device data from the ESI index (index\esi.db: the ESI files in the knowledge folder's manuals
and TwinCAT's ESI folders): name, product code, revisions, E-bus current, mailbox, DC modes, sync managers, PDOs with every entry (index, subindex, bit length, type; gaps marked), the predefined PDO assignments, slots of modular devices with their modules, the CoE object list, the diagnosis catalogue size, the ESI file(s). query = type / order code ('EL3356-0010'), part of a name, or a product code ('#x07D83052', '0x07D83052'; a number is read as a decimal product code and as digits of a type or name — read_as). revision: '#x…' as shown, '0x…' or decimal. detail: 'newest' (default) = all of that for the newest revision of each type (or of revision), other revisions as one line each; 'summary' = counts only; 'full' = everything for every revision. Nothing found: note says what is not there — a revision of an indexed device (revisions_available), or the device (then: add its ESI file). One CoE object with sub-indices, defaults and enum texts: hw_object; full-text: hw_search; a diagnosis text id: hw_diag. The index's first build starts by itself (minutes); until it is there the answer says so. source: the index the answer came from (state, built; state_note when it is not current). manuals names the indexed PDF manuals that mention the product, with pages (the twincat-docs skill reads them).

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
detailNonewest
revisionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.12

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already identify this as a safe read-only operation, and the description adds meaningful behavioral context beyond that. It discloses the first-build delay, the source/state reporting, not-found behavior with revisions_available, and manual references with pages.

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 long and dense, but the complexity of the tool justifies most of the detail, and the core purpose is front-loaded. It could be structured more readably, but little of the text appears to be pure filler.

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

Completeness5/5

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

Given the tool's complexity and the presence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers the data domain, query modes, fallback behavior, index-build state, source reporting, and sibling routing.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It thoroughly explains query formats, revision formats, and detail modes, but it does not mention the limit parameter at all, leaving one of the four parameters undocumented.

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

Purpose5/5

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

The description states a specific resource and scope: EtherCAT device data from the ESI index, with a detailed list of what is returned. It clearly distinguishes this lookup from sibling tools such as hw_object, hw_search, and hw_diag.

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

Usage Guidelines5/5

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

It explicitly names the alternatives and the conditions that select them: use hw_object for one CoE object, hw_search for full-text lookup, and hw_diag for a diagnosis text id. It also explains the detail modes, which helps the agent choose how to query.

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