Skip to main content
Glama
Edge-JB
by Edge-JB

tc_license

Manage TwinCAT licenses on TIRC^License node: list dongle devices, link license to existing dongle, and activate OEM license response files.

Instructions

TwinCAT licensing on the TIRC^License node (requires TC3.1 >= 4022.4; older targets have no AvailableLicenseDevices/ActivateResponseFile support and ProduceXml/ConsumeXml return empty or error — the HRESULT is surfaced, not masked). Nothing here touches the safety system (TIRC^License is real-time/licensing config). Actions: list (read-only) — discover available dongle license devices via ProduceXml; returns {treePath, devices:[{name,pathName,typeName,objectId}]} (pass raw:true to also include the full License-node ProduceXml blob). add (name, device) — OFFLINE config edit: CreateChild a license-device child under License bound to a dongle that MUST already exist in the I/O tree (device = its display-name e.g. "Term 2 (EL6070)" OR its ObjectID e.g. "50462722" from list). This only links the License node to existing hardware; it does NOT create the dongle terminal — add the EL6070 (etc.) first via tc_ethercat/tc_tree. Not confirm-gated (config-only). activate_response (confirm, path, oemGuid?) — GUARDED, requires confirm="ALLOW_LICENSE_ACTIVATE" and defaults to no-op: ConsumeXml the ActivateResponseFile command to activate an OEM license response file (path = absolute path to the .tmc/.reresponse file). oemGuid is "only required in special cases" and accepts any value; defaults to 0 when omitted. This is a license-activation state change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawNo
nameNo
pathNoabsolute path to the OEM license response (.tmc/.reresponse) file
actionYes
deviceNodongle display-name (e.g. "Term 2 (EL6070)") or ObjectID string from list
confirmNo
oemGuidNo
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: list is read-only, add is offline config edit not confirm-gated, activate_response is guarded and defaults to no-op, and mentions HRESULT behavior for older targets.

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 well-structured by action and each sentence adds value. Slightly verbose but not wasteful. Front-loaded with purpose and version constraints.

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 (3 actions, 7 parameters, no output schema), the description covers all behavioral aspects: return format for list, prerequisites for add, guard for activate_response, and version constraints.

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

Parameters5/5

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

Despite low schema coverage (29%), the description adds significant meaning for each parameter: explains 'raw' for list, 'name' and 'device' for add (with example formats), and 'confirm', 'path', 'oemGuid' for activate_response (including defaults). Compensates fully.

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 clearly states the tool is for TwinCAT licensing on the TIRC^License node, lists three actions (list, add, activate_response), and distinguishes from siblings by noting it does not touch the safety system and references tc_ethercat/tc_tree for dongle creation.

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?

Provides explicit usage context: prerequisites for 'add' (dongle must exist in I/O tree), alternatives (use tc_ethercat/tc_tree for dongle creation), and when not to use (not for safety system). Also specifies guard condition for 'activate_response' requiring confirm='ALLOW_LICENSE_ACTIVATE'.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Edge-JB/TwinCAT-XAE-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server