te1000-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.3.0
Disambiguation5/5
Each tool has a clearly distinct domain (e.g., PLC, C++, EtherCAT, fieldbus, licensing, mapping) and action set. Overlap is minimal—generic tree operations in tc_tree complement dedicated tools like tc_ethercat and tc_fieldbus without ambiguity.
Naming Consistency5/5
All tool names consistently use snake_case with domain-specific prefixes (plc_, tc_, xae_, twincat_) followed by descriptive verbs, creating a predictable and readable naming convention.
Tool Count4/5
25 tools is a high count, but it reflects the extensive scope of TwinCAT engineering (PLC, C++, fieldbuses, licensing, etc.). A few more focused tools could reduce the number, but the set is still well-scoped for the domain.
Completeness4/5
The tool surface covers core engineering workflows comprehensively: PLC lifecycle, C++ projects, major fieldbuses, licensing, variable links, tasks, and XAE operations. Notable gaps include TwinSAFE (safety) which is explicitly excluded, and some advanced device configuration may rely on generic tools.
Average 4.2/5 across 25 of 25 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 80 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions waiting for completion, but not key behaviors like side effects of clean/rebuild, prerequisites, error handling, or what happens when waitForFinish is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, the extreme brevity sacrifices clarity on parameters and usage, making it less effective despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, no annotations, the description is incomplete. It does not cover return values, error states, prerequisites, or parameter details, leaving significant gaps for an AI agent.
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%, so description must compensate. It fails to explain any parameter beyond the action enum (implicitly). No details on waitForFinish behavior, timeout implications, or accepted values.
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 clearly states the tool cleans, builds, or rebuilds the active solution configuration, which is specific verb+resource. It could better distinguish from sibling tools like xae or xae_command, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as xae or xae_command. There is no mention of alternatives or prerequisites, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only hints at behavior for 'errors' ('latest messages') and provides default values for parameters. It fails to describe side effects (e.g., resetting PLC on rescan), permission requirements, or response formats, leaving significant behavioral uncertainty.
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 a single line with a compact structure using colons and parentheses. It conveys all actions and parameter hints without extra words. It is concise and efficient, though the density slightly reduces readability. Score 4 for being very concise with moderate clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 parameters, 0% schema coverage, no output schema), the description covers the action list and parameter mappings but lacks details on each action's behavior, return values, and error handling. It is incomplete for an agent to use the tool reliably without additional context.
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 0%, so the description must compensate. It does add meaning for 'netId' and 'path' parameters via parenthetical notes (e.g., 'default TIPC', 'IO device node'). However, it does not explain the 'action' enum values beyond listing them, and the parameter descriptions are fragmented. This is adequate but not thorough.
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 lists the supported actions (get_netid, set_netid, errors, rescan_plc, scan_io_boxes) and their parameter hints, making it clear what operations the tool performs. However, it lacks an explicit statement of the tool's overall purpose (e.g., 'Manage TwinCAT system settings'), so it is not a full 5, but it is specific enough for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools like nc, plc_download, or tc_link. It does not mention scenarios, prerequisites, or alternatives. The agent must infer usage from the action names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the guard requirement ('confirm=ALLOW_XAE_COMMAND_EXEC'), but fails to describe side effects, error handling, or return behavior of the executed command, leaving significant transparency gaps.
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 concise at two sentences with no wasted words. However, it could be structured to list example commands or parameter formats, slightly improving efficiency without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw command execution tool with no output schema, the description lacks essential context about return values, error messages, or side effects. It does not tell the agent what happens after execution, which is critical for decision-making and error handling.
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 0%, so the description must explain parameters. It implicitly explains the 'confirm' parameter by referencing the guard string, but does not clarify 'commandName' (only indirectly via the verb 'command by name') or 'args'. This provides some but insufficient semantic value for the three parameters.
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 clearly states the action ('Execute a raw XAE/DTE command by name') and provides a concrete example ('View.SolutionExplorer'), making the primary purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'xae' or 'xae_build', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'xae_build' or 'twincat_activate_configuration'. The description implies it is for arbitrary commands but does not state exclusion cases or prerequisites, leaving the agent uninformed about tool selection boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses what each action returns (tasks list, axes list, axis info + children) but does not mention side effects, permissions, or data format. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential information with no wasted words. It is efficiently structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 actions, 2 parameters, and no output schema, the description is incomplete. It assumes knowledge of the NC motion tree, does not specify return formats, and does not clarify how the path parameter behaves for each action beyond brief hints.
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 coverage is 0%, so the description must compensate. It explains the action enum values, but the 'path' parameter is only partially clarified (e.g., 'path = task' for axes, 'full axis path' for axis). The dependency on action is implicit, not explicit.
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 specifies the tool is for NC motion tree and lists three actions (tasks, axes, axis) with brief explanations. It clearly distinguishes the tool's purpose from siblings which are about PLC, TC, and system operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not provide context or exclusions, leaving the agent to infer usage from the name and actions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'start/restart' and the confirm guard. It omits side effects (e.g., stopping running code, disconnecting clients), permission requirements, or error states.
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?
Two sentences with clear purpose and a parameter hint. No fluff, but could include more structured information like usage steps or consequences without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action like restarting runtime, the description is too minimal. It lacks output description, error handling, and context on impact. Schema and annotations do not compensate.
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?
The schema only specifies parameter 'confirm' as a string. The description adds critical usage context by stating the required value 'ALLOW_TWINCAT_RESTART'. This adds meaning beyond the schema, though it could explain why this guard exists.
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 action (start/restart), the resource (TwinCAT runtime), and the location (on the target). It distinguishes from sibling tools like plc_download or twincat_activate_configuration, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions a guarded confirm parameter, but does not explain prerequisites, context, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the guarded nature ('confirm="ALLOW_TWINCAT_ACTIVATE"') but does not explain potential consequences (e.g., system restart, destructive actions, or side effects). This is insufficient for an activation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the purpose, the second explains the guard. No unnecessary words. Every sentence serves a purpose.
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?
Given the low complexity (1 parameter, no output schema, no annotations), the description covers the basic action and confirmation requirement. However, it lacks context about what activation entails, prerequisites, or typical integration with sibling tools like tc_link or plc_download. It meets minimum viability but is not comprehensive.
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 coverage is 0%, and the schema only specifies a required string 'confirm' without description. The tool description adds critical semantic context by stating the exact required value 'ALLOW_TWINCAT_ACTIVATE', which is essential for correct invocation. However, it does not explain error handling if the value is wrong.
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's action: 'Activate the TwinCAT configuration on the target.' The verb 'Activate' and resource 'TwinCAT configuration' are specific. The sibling tools (e.g., plc_download, twincat_restart_runtime) indicate distinct operations, making this tool's purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical workflow position, or conditions for activation. The description only states the action and the required confirmation, but not the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description covers important behaviors: open_solution's closeExisting/discardChanges effects, error_list's limit/severityFilter behavior, dialog_probe being read-only, dialog_resolve's click and remember functionality, and the refusal of destructive prompts for auto-remember. This is thorough disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that packs much information but lacks formatting (e.g., bullet points or sections). While every sentence adds value, the structure could be improved for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and no output schema, the description covers most actions and their key behaviors. Missing details like return values (e.g., what status returns) are minor, and the tool's complexity is well-addressed overall.
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 coverage is only 20%, but the description substantially compensates by explaining parameters like solutionPath, closeExisting, discardChanges, limit, severityFilter, button, remember, and filter in context. However, the mode parameter is only described in the schema, leaving a small gap.
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 enumerates all actions (status, open_solution, save_all, etc.) with specific verbs and resources. Each action is distinct, and the tool is differentiated from siblings like xae_build and xae_command by being a general-purpose shell.
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?
The description does not explicitly state when to use this tool versus its siblings. Some actions have implicit usage context (e.g., dialog_probe/dialog_resolve for modal dialogs), but no general guidance on selecting this shell over others is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: guarded operations (require confirm), default no-op for generate_boot_project, mutation for install:true, live runtime impact of online commands, and out-of-scope safety projects. It also notes an unverified ConsumeXml envelope. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that is quite long. While it contains valuable information, it lacks structure (e.g., bullet points or sections) and is not front-loaded effectively for scanning. Each sentence carries weight, but overall it is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 parameters, 9 actions) and absence of output schema, the description covers most aspects: all actions, parameter defaults, node context, guarded operations, and edge cases. Missing details include the exact return values for the info action, but overall it is quite complete.
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?
The input schema has only 6% description coverage, but the description compensates by explaining parameters in context of each action, e.g., 'create_from_template (name, template, before?, save?)'. It also clarifies treePath semantics. However, some parameters like 'selection' for plcopen_export/import are not fully explained.
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 clearly states that the tool handles PLC project lifecycle actions, listing specific actions like create_from_template, open, info, etc. It does not explicitly distinguish from sibling tools like plc_library or plc_pou, but the breadth of actions and the context of project lifecycle make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed per-action usage guidelines, including required parameters, defaults (e.g., treePath defaults), and prerequisites (e.g., login before reset_*). However, it lacks an overall statement of when to use this tool versus alternatives, and the information is dense and could be more scannable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the read-only nature of produce, the mutation of consume, and the destructive nature of clear (guarded by confirm). It also highlights safety concerns with TwinSAFE links and the undocumented XML schema, providing comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but somewhat lengthy with complex sentences. It is well-structured into actions and safety notes, but could be more concise without losing essential details. The length is justified by the tool's complexity.
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?
The description explains the produce action's return (raw XML) but does not specify return values for consume and clear. Error conditions and exact output format are not detailed. Overall, it provides enough context but leaves some gaps in expected results.
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?
The input schema has 0% description coverage, but the description compensates by explaining the meaning of each parameter: the action enum values, the xml blob for consume, the confirm string for clear, and the optional save flag. This significantly aids understanding beyond the bare schema.
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 identifies the tool as for bulk variable-mapping operations on the loaded TwinCAT project, listing three distinct actions (produce, consume, clear) with specific verbs and scope. It distinguishes itself from sibling tools by emphasizing whole-project operations without a tree path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each action, such as running produce first as a backup, and notes that these are project-wide config-tree ops, not runtime writes. It does not mention alternatives directly, but the detailed action descriptions and safety instructions help the agent decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the guard, method behaviors, autoLogout effects, and states 'never logs back in,' providing good insight into side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a purpose: purpose, guard, method details, autoLogout behavior—concise and well-structured with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers core behavior and key parameters, though it could elaborate on autostart and treePath.
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 coverage is only 17%—the description adds value by explaining confirm, method enum, and autoLogout, but leaves treePath, autostart, and commandName 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 clearly states 'Deploy the active PLC project' with specific details about methods and guard, distinguishing it from sibling tools like plc_library or plc_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the guard requirement and the two methods (bootproject vs command) with context, but lacks explicit guidance on when to choose one method over the other or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description fully covers the behavioral traits. It details the internal implementation (ITcSmTreeItem.CreateChild), input format, revision handling, fallback behavior for failed modules, and the optional save action. The return format is also described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite verbose and packs extensive detail into a single dense paragraph. While it is front-loaded with the purpose, it could be more concise or structured with bullet points for easier readability. It earns its place but is not optimally concise.
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 complexity of creating EtherCAT boxes, the lack of schema descriptions, and no output schema, the description is remarkably complete. It covers input structure, behavior for single and multiple modules, revision handling, error recovery, and return format. The user can fully understand and use the tool from this description alone.
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?
The input schema has 0% description coverage, leaving the description to explain all parameters. It thoroughly explains 'racks', 'parent', 'modules', 'type', 'name', 'revision', 'before', and 'save', including the format for revision pinning and default behaviors. This adds significant meaning beyond the bare schema.
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's purpose: 'Create EtherCAT IO boxes (terminals/couplers) NATIVELY.' It specifies the exact method and distinguishes the tool from other operations, such as using the GUI's 'Add Box' route. The tool is uniquely positioned among siblings for creating EtherCAT hardware.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest other tools for different scenarios. While it implies its use for native EtherCAT box creation, no comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses offline-only, no confirm token, runtime activation needed, and TISC refusal. It mentions cleanup on wrong subType/vInfo and notes unverified parts. However, it lacks explicit detail on side effects or idempotency, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that includes many sub-actions, caveats, and numerical codes. While all information is valuable, it lacks bullet points or clear separation, making it harder to parse quickly. It could be restructured for better readability.
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?
With 28 parameters, no output schema, and many sub-actions, the description covers most actions and parameters but omits return values for actions like list_resources or get_xml. It provides caveats and behavioral notes, but some actions could benefit from more detail on expected outcomes.
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 only 7%, but the description compensates by explaining parameters for each action (e.g., create_device parameters: parent, name, subType, etc.) and includes a subType cheat-sheet. Not all parameters are fully described (e.g., xml for set_xml), but the value added is substantial given the low schema coverage.
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 it creates and configures non-EtherCAT fieldbus masters/slaves/boxes. It lists specific protocols and distinguishes from sibling tc_ethercat. The various sub-actions (create_device, create_batch, etc.) are enumerated, making the purpose highly specific.
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?
Explicit guidance is given: 'For EtherCAT terminals/boxes use tc_ethercat instead.' It emphasizes offline-only, no confirm token, and that runtime needs later activate/restart. Batch-first recommendation for multiple devices is provided. Caveats are included for GSD box and set_station_address, and TISC safety paths are refused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: batch returns failures-only by default, details:true includes all rows; resolve returns compact or verbose; auto-resolution of dot-form subfields. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and run-on, lacking paragraph breaks or bullet points. While information-dense, it could be better structured for quick scanning by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all actions and parameter behaviors thoroughly, including the 'discover→act→verify' loop for the 'links' action. No output schema exists, but description provides sufficient detail for effective use.
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?
Adds meaning beyond the schema by explaining parameters like 'a' as source, 'b' as destination, 'links' array structure, 'save' for batch, and 'details'/'verbose' for output control. Does not explicitly cover 'autoResolve' default but schema coverage is low, so description compensates well.
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 clearly defines the tool's purpose: managing variable links (producer↔consumer) with multiple actions (link, unlink, resolve, links, batch variants). It distinguishes between single and batch operations, but could be more succinct about the core function.
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?
Explicitly advises batch usage for multiple links ('BATCH-FIRST'), explains when to use link_batch/unlink_batch instead of single actions, and describes behavior of unlink with only 'a'. Provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses that READ actions are side-effect-free, WRITE actions are offline with no runtime impact and require a solution close+reopen, and REPO ADMIN mutates shared machine state and requires a confirm parameter. It also notes the safety system is not targeted.
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 with clear sections for READ, WRITE, LANDMINE, and REPO ADMIN. It is somewhat verbose but front-loaded with the purpose. Every sentence adds value, and the structure aids readability.
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 (20 parameters, multiple actions) and lack of output schema, the description is remarkably complete. It covers all action categories, side effects, prerequisites, and the critical LANDMINE note. It provides sufficient context for an agent to select and invoke the tool correctly.
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 only 15%, so the description must compensate. It explains parameters in context of actions (e.g., name, version, company for add_library; filter for scan; referencesPath default), but many parameters like lib, dist, mode, index, folder, overwrite, placeholder remain unexplained. The description provides some added meaning but is not exhaustive.
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 manages PLC library references, placeholders, and repositories via ITcPlcLibraryManager. It distinguishes between READ, WRITE, and REPO ADMIN actions, and the tool name and context differentiate it from sibling tools like plc_project or xae.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly divides actions into READ (no side effects), WRITE (offline edits, no runtime impact, requires close+reopen), and REPO ADMIN (machine-wide, guarded, requires confirm). It provides clear context but does not explicitly compare to alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that status is read-only, logout logs out and applies source edits, and that logout requires confirmation with a specific value. It also states the tool never logs back in. This is transparent for its simplicity, though it could detail error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a brief list, front-loading the purpose and then detailing each action. Every sentence adds value; no fluff. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers purpose, both actions, effects, and guards. It mentions status output format and logout side effects. It could be more explicit about the output schema or error cases, but for a simple tool it is largely complete.
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?
Schema has 0% coverage, but description adds full meaning: explains the 'action' enum values (status is read-only, logout logs out) and clarifies that 'confirm' is needed only for logout, with exact required value 'ALLOW_PLC_LOGOUT'. This is highly informative beyond schema.
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 'PLC online-session control via UI Automation', with explicit actions (status, logout). It distinguishes itself from siblings by focusing on session management, not downloading, libraries, or other PLC operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that DTE Login/Logout commands are unavailable on 64-bit shell, implying this tool is the substitute. It also warns 'Never logs back in', guiding usage. However, it doesn't name an alternative for logging back in, which slightly limits guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral details: VS-hosted-safe operation via ITcSmTreeItem.CreateChild, open project not renamed, build-only for compile, publish guarded and not activating runtime, and ConsumeXml error behavior. It covers side effects, restrictions, and prerequisites comprehensively.
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 with a clear overview followed by action-specific details. While lengthy, every sentence serves a purpose, and the information is organized logically. Minor redundancy exists (e.g., repeating 'CreateChild' details), but overall it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, 7 actions, no output schema), the description is highly comprehensive, covering per-action behaviors, defaults, error indications, and guarded operations. It lacks details on return values or success/failure representation, but the context provided is sufficient for effective agent invocation.
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 only 7% schema description coverage, the description explains each action's parameters with defaults, constraints, and specific values (e.g., template options for create_project, subType semantics for open, confirm requirement for publish). This adds crucial meaning beyond the schema, fully compensating for low coverage.
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 identifies the tool as handling TwinCAT C++ projects/modules under TIXC with distinct differentiation from TISC safety. It explicitly lists seven actions with specific behaviors, making the purpose unambiguous and distinguishing from sibling tools like tc_ethercat or plc_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage guidance within its domain: it states 'C++ ONLY', notes when runtime activation is needed separately, and gives per-action caveats (e.g., build does not deploy, publish does not activate). However, it lacks explicit comparison to alternative tools or direct 'when-not-to-use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: set_silent_mode suppresses dialogs (with version dependency), switching platform invalidates builds, parent directory must exist for save_plc_archive, and set_disabled only accepts 0/1. It does not explicitly cover authorization or side effects like idempotency, but provides substantial transparency.
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 a dense single paragraph that efficiently conveys general context first, then lists actions with details. While it is concise and front-loaded, it could benefit from structured formatting (e.g., bullet points) for easier scanning. However, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 actions, 7 parameters, no output schema or annotations), the description provides comprehensive coverage: it explains each action's behavior, parameter usage, constraints, and return format for get_disabled. Missing details like exact return types for other getters, but overall adequate for agent decision-making.
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?
The input schema has 7 parameters with 0% description coverage. The description fully compensates by explaining each parameter's meaning in context (e.g., platform values, file as absolute path, path as tree path with ^ separators, enabled/disabled booleans, name default). It adds semantics beyond the schema's enum and type definitions.
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 that the tool handles 'XAE engineering settings & packaging' and lists all actions (get_silent_mode, set_silent_mode, etc.). It distinguishes itself from runtime tools by explicitly noting it is offline/engineering-only and does not change runtime state directly.
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?
The description provides explicit guidance: it labels the tool as offline-only, explains that no confirm-gating is needed, and warns that switching the target platform invalidates prior build output (recommending xae_build). It also mentions that safety paths are rejected by policy for certain actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must be self-sufficient. It discloses read-only vs write actions, optional save behavior, error conditions for old installs, and the readback disabled int with SMDS_PARENT_DISABLED=2. This provides rich behavioral context.
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 and well-structured with clear sections for each action. It is somewhat verbose but every sentence adds value. Could be slightly more concise, but front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return values for get_config (raw XML), get_current (variant name or empty), and disable/enable (disabled int). It lacks explicit return types for set_config, select, etc., but overall is thorough for a complex multi-action tool.
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?
Schema description coverage is 0%, but the description fully explains each parameter in context of actions (e.g., xml for set_config, variant for select, path for disable/enable). It adds meaning beyond the schema enum and property names.
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 that this tool manages project variants on the open solution, listing specific actions (get_config, get_current, set_config, select, disable, enable). It is distinct from sibling tools, none of which handle variant management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Prerequisites are given (TCatSysManagerLib >= 3.3.0.0) with behavior for older versions. Constraints like offline-only, no confirm token, and TISC path refusal for disable/enable are stated. However, no explicit comparison to alternative tools is made, but siblings don't overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosure. It details that list is read-only, create may clean up malformed children, set_xml is an escape hatch, set_context is guarded and defaults to no-op, and that XPath/attribute names are unverified from a how-to summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy (approx. 350 words) and includes redundant explanations (e.g., 'CONFIG-TIME ONLY' repeated, details on list output). It is well-organized with actions clearly separated, but could be more succinct without losing clarity.
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 complexity of 13 parameters and multiple actions with no output schema, the description comprehensively covers each action's behavior, parameter usage, error handling, and prerequisites (e.g., call get_xml first). It also mentions return values for list and provides caveats about verification, ensuring the agent has sufficient context.
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 coverage is low (15%), but the description adds significant meaning for nearly all parameters: it explains each action, the path structure, create parameters (name, by, id, before), xml and returnXml for set_xml, boolean parameters for enable_symbols, and taskObjectId/contextId with decimal notation for set_context. Slight deduction for not fully describing path or confirm in all contexts.
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 manages 'TcCOM module objects under TIRC^TcCOM Objects', specifies it is 'CONFIG-TIME ONLY' and not for transitions, and lists specific actions with their purposes. It distinguishes from sibling tool 'tc_link' which handles wiring of symbols.
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?
Explicitly says when to use (config-time only) and when not to (no runtime transitions). Provides alternatives: 'To wire module DataArea symbols ... use tc_link link/unlink.' Also advises calling get_xml before set_xml for parameter toggle verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses offline-only, in-memory edits, TISC path rejection, cache self-invalidation, dirty-checking, and the effect of 'validate' and 'refresh' parameters. There are no behavioral contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long and dense, making it hard for an AI agent to quickly scan. While comprehensive, it lacks structural breaks (bullets, tables) and front-loads details. It could be more concise.
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 46 parameters, no output schema, and zero annotations, the description is remarkably complete. It covers all actions, edge cases (TISC, batch behavior, caching), and provides enough detail for an agent to invoke the tool correctly without ambiguity.
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?
With only 59% schema description coverage, the description adds significant meaning: it explains subType numeric values, language codes, the interplay of range and grep, batch shapes, and contextual hints like 'For code POUs prefer set_decl after create.' This goes well beyond the schema.
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 explicitly states it handles 'PLC object authoring + code edit', lists dozens of specific actions (CREATE, READ, WRITE, SURGICAL TEXT EDIT, DISCOVER, DELETE, etc.), and clearly distinguishes each sub-action. It is specific and aligns with the tool's name.
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?
Extensive guidance is provided: 'cheap-first' hints, when to use outline vs get_decl vs full text, preference for set_decl after create, offline-only constraint, TISC rejection, batch behavior like continue-on-error, and compare with sibling tools like set_decl_batch vs create_batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses that scope/analytics projects are separate DTE nodes, TIAN nodes are SysManager children, creation methods (AddFromTemplate vs CreateChild), guarded confirmations, unverified features (e.g., analytics wiring, Scope data-export), and naming behavior (stream '..._Obj1'). This is highly transparent.
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 (needed for 9+ actions) and front-loads the overview. However, it is a single dense paragraph without clear section breaks; adding bullet points or headers would improve scanability. Still, every sentence earns its place given the tool's complexity.
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?
Despite no output schema, the description covers all actions, parameters, prerequisites, limitations, and even omitted features. It also references sibling tools for related operations. For a tool with 17 parameters and 9 actions, this is thorough and leaves little ambiguity.
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?
Schema description coverage is low (24%), but the description compensates by detailing each parameter for each action (e.g., template defaults, parentPath meaning, elementType verification, confirm values, before for insertion, dryRun purpose). It adds substantial meaning beyond the schema.
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's purpose: handling TwinCAT Measurement (TE130X Scope View) projects and TwinCAT Analytics (TIAN) logger/stream configurations. It distinguishes between project types (EnvDTE.Project vs SysManager children) and lists specific actions, making it distinct from sibling tools like tc_tree or plc_*.
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?
The description explicitly provides usage guidance: it mentions prerequisites (required products), warns about experimental features (elementType non-zero), and tells when to use a sibling tool (tc_tree for raw XML). It also explains guarded actions with specific confirm strings, giving clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses config-only nature, need for later activation, and that TISC is untouched. Explains summary parameter behavior, create defaults, and conversion of cycleTimeUs. Mentions unconfirmed tag names and escape hatch.
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 well-structured: begins with domain, then lists actions separated by semicolons. It is appropriate for the complexity (19 params, 10 actions) but could be slightly more readable with bullet points or clearer separation.
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 high complexity, lack of output schema, and 19 parameters, the description is remarkably complete. It covers all actions, parameter behaviors, caveats, and practical usage notes, leaving little ambiguity for an AI agent.
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?
With only 5% schema description coverage, the description compensates fully, explaining parameters per action: path, summary, withImage, before, cycleTimeUs (conversion to 100ns ticks), priority range, autoStart, xml escape hatch, save, returnXml, etc. Adds meaning beyond schema.
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 precisely states it handles RT tasks under TIRT, RT-core settings under TIRS, and a PLC project's LinkedTask under TIPC, listing specific actions. It clearly distinguishes from sibling tools focused on other subsystems.
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 clear when-to-use guidance: 'CONFIG-ONLY — no confirm token needed; runtime needs a later activate/restart; TISC (safety) untouched.' Includes caveats about unconfirmed tag names and prefers xml escape hatch. Specifies actions and their contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: batch continue-on-error roll-up result structure (count, succeeded, failed), get_xml summary mode, rename keeping IO links, create ghost detection, delete guard pattern, and save flag for mutating batches. No contradictions.
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-organized by action groups and front-loaded with path format and batch guidance. However, it is dense and could be slightly more concise by reducing minor repetitions (e.g., repeated mention of batch result structure). Still, every sentence adds value.
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 20 parameters, no output schema, and rich semantics, the description covers all actions, batch behavior, error handling, guardrails, and sibling context. It provides sufficient detail for an agent to correctly select and invoke the tool without missing critical behavioral aspects.
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?
Schema coverage is only 5%, but the description elaborates on all key parameters: path format (^), arrays (items, paths, creates, deletes, renames) with required fields, and parameters like save, dryRun, confirm, summary, returnXml, before, subType, createInfo. This adds significant semantic value beyond the schema.
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 that the tool manages TwinCAT System Manager tree items with specific path separator ^. It lists numerous actions (get, children, exists, etc.) and distinguishes from sibling tools like tc_ethercat for adding EtherCAT terminals, making purpose and scope unambiguous.
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?
Explicitly advises using batch actions for multiple items ('BATCH-FIRST'), recommends tc_ethercat for EtherCAT hardware addition, and explains guarded delete with dryRun and confirm. It also notes create validation behavior, giving clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: READ operations are unguarded and never persist; WRITE operations are guarded and require a specific confirm parameter. It also clarifies that route changes are not auto-activated and that the tool does not target the safety system, providing crucial context for safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (READ/WRITE, action details, notes) and front-loaded with the primary purpose. Each sentence adds value, covering behavior, prerequisites, and return formats without unnecessary verbosity.
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?
Despite the complexity (16 parameters, multiple actions, no output schema), the description is comprehensive. It covers return formats for each action (e.g., targets list for broadcast_search, found object for search_host), prerequisites, side effects (engineering project vs live target), and exclusions (safety system). All critical aspects are addressed.
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?
The input schema has 0% schema description coverage, but the description compensates by explaining which parameters are relevant for each action (e.g., broadcast_search uses timeoutMs, add_route requires remoteIpAddr or remoteHostName). This adds meaning beyond the raw schema, effectively documenting parameter semantics.
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 it 'ADS routes via the System Manager TIRR (Routes) node' and distinguishes between READ (non-persistent searches) and WRITE (guarded route addition) operations. The specific actions (list, broadcast_search, search_host, add_route, add_project_route) are enumerated, making the tool's purpose unambiguous.
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?
The description provides explicit guidance on when to use each action: READ actions are unguarded, transient searches; WRITE actions require confirmation and are intentionally NO-OP by default. It also explains prerequisites (e.g., version requirements for search_host) and notes that changes affect the engineering project but not the live target, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![TwinCAT-XAE-MCP MCP server](https://glama.ai/mcp/servers/Edge-JB/TwinCAT-XAE-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Edge-JB/TwinCAT-XAE-MCP)

Score Badge

Copy to your README.md:

[![TwinCAT-XAE-MCP MCP server](https://glama.ai/mcp/servers/Edge-JB/TwinCAT-XAE-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Edge-JB/TwinCAT-XAE-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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