TwinCAT Validator MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is significant overlap between tools, particularly between autofix_batch/autofix_file, validate_batch/validate_file, and process_twincat_batch/process_twincat_single which appear to be batch vs single-file versions of the same core operations. However, the descriptions help clarify the scope differences, and tools like extract_methods_to_xml, generate_skeleton, and get_context_pack have distinct purposes.
Naming Consistency4/5
Most tools follow a consistent snake_case pattern with clear verb_noun structure (e.g., validate_file, generate_skeleton, get_context_pack). The main deviation is check_specific which uses an adjective_verb pattern rather than verb_noun, but overall the naming is predictable and readable.
Tool Count3/5
16 tools is borderline high for a TwinCAT validation server, especially given the redundancy between batch and single-file versions. The server could likely consolidate some overlapping tools without losing functionality, making the count feel somewhat heavy for the domain scope.
Completeness5/5
The toolset provides comprehensive coverage for TwinCAT validation workflows including validation (single/batch), fixing (single/batch), policy management, knowledge retrieval, skeleton generation, and specialized operations like method extraction. There are no obvious gaps - it supports the full lifecycle from creation to troubleshooting to verification.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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 provided, the description carries the full burden of behavioral disclosure. It hints at performance characteristics ('Quick') and purpose ('import readiness'), but fails to disclose what validation rules are applied, what the output schema contains, error handling behavior, or whether this is read-only vs. potentially modifying state.
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 brief (two sentences) and front-loads the core purpose. However, the 'Args:' formatting is more typical of code documentation than tool descriptions, and the second sentence is incomplete (missing enforcement_mode documentation). It is appropriately sized but structurally suboptimal.
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 presence of an output schema, the description correctly omits return value details. However, it is incomplete due to missing parameter documentation (enforcement_mode) and lack of sibling differentiation context. With 0% schema coverage and 2 parameters, the description fails to provide sufficient semantic coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It documents only the 'file_path' parameter ('Path to TwinCAT file') but completely omits the 'enforcement_mode' parameter, leaving its purpose and valid values (default: 'strict') unexplained despite being functionally significant.
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 this performs a 'validation check for TwinCAT import readiness,' specifying the verb (validate), resource (TwinCAT file), and scope (import readiness). It distinguishes from siblings like 'validate_file' or 'validate_batch' by specifying the import context, though it could further clarify the distinction from 'check_specific'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 its numerous validation siblings (validate_file, validate_batch, check_specific, get_validation_summary). There is no mention of prerequisites, when-not-to-use conditions, or alternative tools.
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 carries the full burden but fails to disclose key behavioral traits. It does not indicate whether the tool modifies the TwinCAT file (though likely read-only given 'autofix' siblings exist), what the output schema contains, or how to interpret the 'enforcement_mode' parameter's behavior.
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 appropriately concise with a clear imperative sentence followed by an Args section. Structure is front-loaded with the purpose statement first. The only inefficiency is the omission of the 'enforcement_mode' parameter from the Args list.
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 0% schema coverage and no annotations, the description is insufficient for a 3-parameter tool. It fails to document the 'enforcement_mode' parameter and provides no context on return values (though an output schema exists, the agent still needs to know what the tool conceptually returns) or side effects.
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?
The Args section adds semantic value for 'file_path' (specifying it is a TwinCAT file) and 'check_names' (clarifying they are check IDs), partially compensating for the 0% schema description coverage. However, it completely omits the third parameter 'enforcement_mode' (default: 'strict'), leaving its behavioral impact unexplained.
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 'Run[s] specific validation checks on a TwinCAT file,' providing a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'validate_file' or 'validate_batch,' leaving the agent to infer the distinction from the word 'specific' and the required 'check_names' parameter.
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 alternatives like 'validate_file' (likely full validation) or 'check_specific' (targeted validation). The description does not state prerequisites (e.g., needing valid check IDs) or exclusions.
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 carries full behavioral disclosure burden. While 'Get' implies read-only access, the description fails to clarify whether this triggers validation computation or retrieves cached results, what the health score represents (scale/format), or error handling behavior.
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?
Extremely concise with no redundant text. The two-sentence structure (purpose statement followed by Args documentation) is efficient and appropriately front-loaded, though brevity sacrifices contextual richness.
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 15 sibling tools including multiple validation variants, the description is insufficient for tool selection. The existence of an output schema reduces the need for return value documentation, but the crowded namespace demands explicit comparison criteria that are absent.
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?
Compensates effectively for 0% schema description coverage by specifying that file_path represents a 'Path to TwinCAT file' (adding domain context 'TwinCAT' that the schema lacks). The Args structure efficiently documents the single parameter's semantics.
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 uses specific verbs ('Get') and clearly identifies the resource ('high-level file quality summary with health score'). However, it lacks explicit differentiation from validation-related siblings like 'validate_file' or 'check_specific', leaving ambiguity about whether this retrieves cached data or performs live analysis.
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 provided on when to use this tool versus the numerous validation alternatives (validate_file, validate_batch, check_specific). No prerequisites, constraints, or selection criteria are mentioned.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool searches for the 'nearest' policy file (describing resolution behavior) and 'return[s] normalized policy' (describing output). However, it fails to clarify whether this is a read-only operation, what 'normalized' specifically entails (schema enforcement, default injection?), or error behavior when no policy file exists.
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, efficient sentence of twelve words. It front-loads the action ('Lint'), specifies the target resource, and concludes with the return value. There is no redundant or extraneous text; every word contributes to understanding the tool's function.
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 presence of an output schema, the description appropriately does not detail return values. However, with zero schema parameter descriptions and two parameters to document, the description should have explicitly mapped 'target_path' to the directory search behavior and defined the 'strict' flag. The omission of edge case handling (no policy file found) also leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to compensate. While the word 'nearest' implicitly suggests that target_path controls the search starting directory, it does not explicitly document this mapping, nor does it explain what the empty string default signifies (current working directory?). The 'strict' parameter is completely undocumented in both schema and description.
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 lints '.twincat-validator.json policy keys/types' and returns a 'normalized policy.' It identifies the specific resource (the policy file) and action (linting/normalizing), distinguishing it from siblings like validate_file or get_effective_oop_policy which operate on code or retrieve computed policies rather than linting the configuration file itself.
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 mentions 'nearest' which implies directory tree traversal behavior, hinting that target_path determines the search starting point. However, it provides no explicit guidance on when to use this tool versus siblings like get_effective_oop_policy or validate_file, nor does it explain the consequences of the 'strict' parameter or when one might want to disable it.
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?
Discloses specific complex behaviors (contract violation handling, implicit file creation, orchestration hints for agents) but fails to explicitly state the fundamental safety profile: that this is a destructive file-modifying operation. Given zero annotations, this omission is significant despite the detailed parameter explanations.
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?
Appropriately structured with a clear one-line summary followed by detailed Args documentation. Length is justified given 10 parameters with zero schema descriptions. Indented Args format is readable, though slightly non-standard for MCP.
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?
Handles high complexity reasonably well given lack of annotations and schema descriptions, but gaps remain: missing enforcement_mode parameter, no mention of how to discover valid 'fix IDs' for fixes_to_apply, and no warning about destructive side effects despite output schema existing.
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?
With 0% schema coverage, the Args section compensates heavily for 9/10 parameters with detailed semantics (e.g., profile options, strict_contract behavior). However, it completely omits the 'enforcement_mode' parameter present in the schema, leaving that parameter undocumented.
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?
Clear specific verb ('fix') and resource ('TwinCAT XML issues'). Distinguishes from validation/suggestion siblings by emphasizing automatic fixing action, though could explicitly contrast with autofix_batch for 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 explicit guidance on when to choose this over siblings (autofix_batch for multiple files, suggest_fixes for preview-only) or prerequisites. The 'Automatically' prefix implies hands-off repair but doesn't state conditions like 'use when file is corrupt but parseable'.
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?
No annotations provided, so description carries full burden. Adds 'canonical deterministic' behavioral context, but omits critical safety profile (read-only vs. destructive), side effects, or whether output is returned vs. written to disk. Lacks disclosure of rate limits or auth requirements.
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?
Uses Args section efficiently to document constraints. Information is front-loaded with the purpose statement. Missing parameter is a content omission, not a structural verbosity issue.
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?
Adequate for a 3-parameter tool with existing output schema (return values need not be explained). However, missing enforcement_mode parameter and lack of usage context or behavioral safety disclosure prevents a higher score.
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 has 0% description coverage. Description compensates well for file_type (valid extensions, dot formatting) and subtype (conditional valid values), but completely omits enforcement_mode parameter, leaving one-third of the interface undocumented.
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?
Clear specific verb (Generate) and resource (TwinCAT XML skeleton), with 'deterministic' clarifying output consistency. However, it does not explicitly distinguish from sibling tools like extract_methods_to_xml or process_twincat_single.
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?
Provides no guidance on when to use this generator versus processing/validation siblings (e.g., process_twincat_single, validate_file). No mention of prerequisites, workflow position, or when generation is preferred over extraction.
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?
With no annotations provided, the description must carry the full burden. It discloses key behavioral traits like 'Create backup files before fixing' and 'Auto-create missing interface/DUT dependencies,' which hint at destructive file modifications. However, it never explicitly states that this is a destructive write operation or describes error-handling behavior (e.g., fail-fast vs. continue-on-error).
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 uses a standard Args block format appropriate for a complex tool with 11 parameters. Information is efficiently organized with minimal redundancy. The structure is slightly compromised by the omission of the `enforcement_mode` parameter from the Args list.
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 high complexity (11 parameters, 0% schema coverage) and presence of an output schema, the description adequately compensates for the schema's lack of descriptions on most parameters. However, the missing parameter documentation and lack of sibling-tool context leave noticeable gaps for a tool of this sophistication.
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 (titles only), so the description's Args block carries the full load. It provides rich semantic detail for 10 of 11 parameters (e.g., explaining that `intent_profile` inspects files for EXTENDS/IMPLEMENTS, or that `ctx` is injected automatically). It fails to document the `enforcement_mode` parameter at all, which prevents a perfect score.
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 opening sentence clearly states the tool 'Automatically fix[es] multiple TwinCAT files matching glob patterns,' providing a specific verb (fix), resource (TwinCAT files), and scope (batch/multiple). However, it does not explicitly differentiate from the sibling tool `autofix_file` (single-file vs. batch) or define what 'fix' encompasses (formatting, validation, or both).
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 alternatives like `autofix_file` or `validate_batch`. There are no prerequisites mentioned (e.g., whether validation should be run first) and no warnings about when not to use it.
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?
With no annotations provided, the description carries the full burden. It discloses the backup creation behavior ('Create .bak backup when content changes'), implying file modification, but lacks explicit disclosure that it modifies the input file in-place, error handling behavior, or output format details despite the existence of an output schema.
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?
Appropriately concise with a clear single-sentence purpose statement followed by a structured Args block. No redundant text, though the Args section repeats information that ideally would be in the schema (necessary given 0% coverage).
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?
Adequate for a 2-parameter tool with an output schema (which excuses return value documentation). However, given this is a file-modifying mutation tool with no annotations, the description should explicitly state the modification behavior rather than implying it only through the backup parameter.
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?
Excellent compensation for 0% schema description coverage. The Args section documents both parameters: 'file_path' includes the specific '.TcPOU' extension context, and 'create_backup' explains the conditional backup behavior ('when content changes'). Provides the semantic meaning missing from the bare schema.
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 specific transformation: extracting inline METHOD blocks from main ST (Structured Text) into dedicated <Method> XML elements. It identifies the specific file format (.TcPOU) and operation type, though it doesn't explicitly differentiate from the generic 'process_twincat_single' sibling.
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 provided on when to use this tool versus alternatives like 'process_twincat_single' or 'autofix_file'. Missing prerequisites (e.g., when extraction is appropriate) and exclusion criteria (e.g., files without inline methods).
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It signals read-only intent via 'Get' and adds the important behavioral context that this resolves 'effective' (inherited/merged) policies rather than just local ones. However, it omits safety confirmations (read-only assurance), side effects, or computational cost of resolving effective policies.
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 appropriately compact with two sentences. The first states purpose immediately; the second documents the single parameter using a standard Args format. No extraneous information is present, though the 'Args:' structure is slightly formal for MCP descriptions.
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 simple getter tool with one optional parameter and an existing output schema (per context signals), the description is adequately complete. It covers the parameter semantics sufficiently and does not need to describe return values since an output schema exists.
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?
Given 0% schema description coverage, the description effectively compensates by explaining that target_path is optional and documenting the default behavior (current working directory). This adds essential semantic meaning beyond the raw schema which only indicates a string type with empty default.
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 specific action ('Get') and resource ('effective OOP validation policy') with scope ('for a file or directory target'). The term 'effective' distinguishes it from siblings like 'lint_oop_policy' or 'get_validation_summary' by implying resolution of inherited/cascading policies, though it could explicitly contrast with validation tools.
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 provides implicit usage guidance by explaining the default behavior when target_path is omitted (uses current working directory). However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_validation_summary' or 'lint_oop_policy', or prerequisites for the target path.
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?
No annotations are provided, so the description carries the full burden. It adds the behavioral trait that recommendations are 'prioritized' (ranked by importance). However, it omits disclosure of safety properties (read-only vs destructive), idempotency, or side effects, though the existence of an output_schema reduces the need to describe return values.
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 appropriately brief and front-loaded with the main purpose. The Args section is justified given the schema's lack of descriptions. The structure mixes narrative and docstring styles, which is functional but slightly less integrated than ideal.
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 has only one parameter, has an output_schema (covering return values), and the description establishes the workflow link to 'validate_file()', the definition is sufficiently complete. The description adequately compensates for the schema coverage gap.
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?
With 0% schema description coverage, the description compensates effectively by specifying that 'validation_result' is a 'JSON string from validate_file()'. This provides critical semantic context (format and provenance) that the schema lacks, though it could further clarify the expected structure of the JSON content.
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 'Generate[s] prioritized fix recommendations from validation results', specifying the verb (generate), output (recommendations), and input source (validation results). The term 'prioritized' adds specificity, and the purpose distinguishes it from sibling 'autofix_*' tools by implying suggestion rather than application.
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 Args section mentions the input comes from 'validate_file()', implying a workflow sequence (validate → suggest). However, it lacks explicit guidance on when to use this versus 'autofix_file' or 'autofix_batch' (i.e., when manual review is preferred over automatic fixing).
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 full burden. It discloses that the tool runs 'twice' (key behavioral trait), but fails to clarify whether the tool is read-only or destructive. The create_backup parameter mentions 'before fixing', implying mutation, which contradicts the 'verify' name and 'report' verb without explanation. It also does not describe what 'strict batch orchestration' entails or what happens if idempotence fails.
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 one-line summary followed by an organized Args block. Every section serves a purpose: the summary establishes purpose, the Args compensate for missing schema documentation. It is appropriately verbose given the complexity, though the include_sections description is lengthy (necessary for the enumerated valid values and mode-specific behavior).
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 presence of an output schema, the description appropriately focuses on input parameters and response modes rather than return values. However, it lacks critical behavioral context regarding side effects (mutation vs. read-only) and does not explain the mechanism of the idempotence comparison (e.g., what constitutes a difference between the two runs).
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 0% schema description coverage, the description comprehensively compensates by documenting all 7 parameters in the Args section. It provides specific enum values (e.g., 'all', 'critical', 'style' for validation_level), examples (e.g., ['*.TcPOU'] for file_patterns), default indicators (e.g., 'summary' default for response_mode), and detailed constraints (e.g., include_sections only works in summary mode).
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 the tool 'Run strict batch orchestration twice and report per-file idempotence stability', providing a specific verb (run/report), resource (batch orchestration), and unique scope (twice/idempotence). This clearly distinguishes it from siblings like validate_batch or autofix_batch by emphasizing the double-run determinism check.
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 implies usage through the idempotence/determinism context—you use this when you need to verify stability across multiple runs. However, it lacks explicit guidance on when to choose this over validate_batch or autofix_batch, and does not specify prerequisites or exclusions (e.g., whether it requires specific file states).
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?
With no annotations provided, the description carries the full burden. It successfully discloses behavioral details like 'per-file progress notifications' for the ctx parameter and the OOP detection logic ('scanned for EXTENDS/IMPLEMENTS'). However, it fails to state whether the operation is read-only or destructive—a critical omission given the presence of 'autofix_batch' as a sibling—and doesn't mention performance characteristics or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line purpose followed by an Args section. Every sentence adds value, explaining either the tool's purpose or parameter semantics. The format is scannable and front-loaded, though the Args block could be slightly more concise.
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 tool's complexity (6 parameters with validation logic and output schema), the description is adequate but incomplete. The missing 'enforcement_mode' documentation and lack of sibling comparison context prevent a higher score, though the presence of an output schema reduces the description's burden for return value documentation.
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?
Despite 0% schema description coverage, the Args section provides rich semantic detail for 5 of 6 parameters: file_patterns includes an example ('*.TcPOU'), validation_level enumerates options, and intent_profile explains the auto-detection algorithm. However, it completely omits the 'enforcement_mode' parameter present in the schema, creating a documentation 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 opens with a clear, specific statement: 'Validate multiple TwinCAT files matching glob patterns.' It specifies the verb (validate), resource (TwinCAT files), and mechanism (glob patterns), effectively distinguishing it from the sibling tool 'validate_file' through the 'multiple' and 'glob patterns' qualifiers.
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 implies batch usage through the 'glob patterns' and 'multiple' qualifiers, but provides no explicit guidance on when to use this tool versus 'validate_file' or other siblings. It also lacks guidance on selecting between validation_level options ('all', 'critical', 'style') or when to override the 'auto' intent_profile.
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?
No annotations provided, so description carries full burden. Documents the multi-step workflow and param effects (especially intent_profile logic), but fails to explicitly disclose destructive behavior (file modification) despite mentioning 'create_backup' and 'autofix_file'. Missing safety warnings or side-effect disclosure.
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?
Well-structured with clear sections: purpose statement, numbered workflow steps, and Args list. Every sentence earns its place; detailed parameter documentation is justified given zero schema coverage. Front-loaded with the workflow summary.
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 high complexity (6 params, multi-step workflow) and 0% schema coverage, description adequately covers parameter semantics and workflow steps. Has output schema (per context signals) so return values needn't be explained. Minor gaps: lacks explicit destructive warning and comparison to batch sibling process_twincat_batch.
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% description coverage, but the Args section comprehensively documents all 6 parameters. Provides enum values for validation_level, enforcement_mode, and intent_profile, plus detailed behavioral logic for intent_profile (procedural vs OOP vs auto resolution). Fully compensates for schema poverty.
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?
States specific verb+resource ('Run... single-file TwinCAT workflow') and distinguishes from siblings by mentioning it comprises validate_file, autofix_file, and suggest_fixes steps. 'Enforced deterministic' adds flavor but could be clearer about the end goal (fixing vs validating).
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?
Lists internal steps (validate_file, autofix_file, suggest_fixes) implying this is the composite pipeline tool, but lacks explicit when-to-use guidance versus calling steps individually or versus process_twincat_batch sibling. 'Only if still unsafe' provides conditional logic but no explicit alternatives.
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 carries the full burden. It successfully discloses the 3-step pipeline, the file-modification nature (implied by 'autofix' and 'backup' parameters), and complex behavioral traits like `intent_profile` auto-detection. It lacks explicit safety warnings about mutation, though the backup option hints at risk.
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?
Well-structured with a front-loaded summary, clear step enumeration, and organized Args section. It is appropriately sized given the 9 undocumented parameters, though dense. The 'include_sections' parameter description is particularly verbose but necessary given the 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 high complexity (9 params, workflow logic) and poor schema coverage, the description is comprehensive. It covers all parameters and explains the OOP vs Procedural logic. Since an output schema exists, omitting return value descriptions is acceptable. Minor gap: no mention of error handling behavior if autofix fails.
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 schema has 0% description coverage (titles only). The Args section fully compensates by providing detailed semantics for all 9 parameters, including enum values ('all'/'critical'/'style'), examples (['*.TcPOU']), and behavioral context (response modes, intent profile logic). This is exemplary compensation for schema deficiency.
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 opens with a specific verb ('Run') and resource ('TwinCAT workflow'), and the enumerated steps (validate/autofix/validate) clearly distinguish this composite tool from siblings like `validate_batch` or `autofix_batch` alone. However, it assumes domain knowledge of 'deterministic' without referencing the sibling `verify_determinism_batch`.
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 three-step workflow implies this is for comprehensive batch processing, but there is no explicit guidance on when to choose this over `process_twincat_single` or standalone `validate_batch`. The description explains 'what' it does but not 'when' to prefer it.
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 carries the full burden. It successfully discloses behavioral traits: it explains the resolution logic for 'auto' intent detection (EXTENDS/IMPLEMENTS → oop), details the differences between output profiles (Full vs LLM strict), and describes the return structure. It does not mention side effects or authorization requirements.
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 uses a clear docstring structure (Args/Returns) with good information density. Every sentence earns its place, explaining either parameter semantics or output format. Minor verbosity in the intent_profile bullet points is justified by the complexity of the concept.
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 5 parameters (one undocumented) and no annotations, the description is nearly complete. It compensates for the lack of schema descriptions for most parameters and provides detailed output documentation (acting as output schema). Deducted one point for the missing 'enforcement_mode' parameter explanation.
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%, requiring the description to compensate. It provides detailed semantic meaning for 4 of 5 parameters: validation_level options, profile behavior, and extensive detail on intent_profile including resolution rules. However, it completely omits the 'enforcement_mode' parameter present in 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 opens with a specific verb ('Validate') and resource ('TwinCAT file'), clearly stating the tool's function. The word 'single' effectively distinguishes it from the sibling 'validate_batch' tool.
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?
While the description explains parameter-specific usage (e.g., when to use 'full' vs 'llm_strict' profiles, or 'procedural' vs 'oop' intent), it lacks explicit guidance on when to choose this tool over siblings like 'validate_for_import' or 'autofix_file'. The 'single' qualifier provides implied context but no explicit alternatives are named.
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 carries the full burden and successfully discloses complex behavioral traits: stage-dependent routing logic, default value implications ('omitted: defaults to oop'), and parameter interaction effects ('In troubleshooting stage... value has no routing effect'). It lacks explicit safety declarations (read-only status) which prevents 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear Stages/Args/Returns sections and front-loaded with the core purpose. While lengthy, the detail is justified by the complex parameter interactions and conditional logic; every sentence provides necessary behavioral context given the lack of schema annotations.
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?
For a tool with complex routing logic and 7 parameters, the description is complete. It explains the stage-based workflows, parameter interdependencies, default behaviors, and summarizes the return structure (JSON with effective_oop_policy, entries, etc.), providing sufficient context for correct invocation despite no output schema being provided in the structured fields.
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 0% schema description coverage, the Args section comprehensively documents all 7 parameters. It explains valid values, conditional requirements (e.g., check_ids required/ignored by stage), and semantic intent (e.g., include_examples 'Set False to save tokens'), fully compensating for the schema's lack of descriptions.
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 opens with a specific verb ('Get') + resource ('curated knowledge base entries and OOP policy') + scope ('workflow stage'), clearly defining the tool's function. It implicitly distinguishes itself from sibling `get_effective_oop_policy` by emphasizing the knowledge base entries and stage-scoping behavior.
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 defines when to use each stage: 'pre_generation' for 'generating TwinCAT XML from scratch' and 'troubleshooting' for 'blocker lists after orchestration'. It clearly states parameter dependencies (e.g., 'check_ids: required for troubleshooting, ignored for pre_generation'), providing clear guardrails for invocation.
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-validator-mcp MCP server](https://glama.ai/mcp/servers/agenticcontrolio/twincat-validator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/agenticcontrolio/twincat-validator-mcp)

Score Badge

Copy to your README.md:

[![twincat-validator-mcp MCP server](https://glama.ai/mcp/servers/agenticcontrolio/twincat-validator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/agenticcontrolio/twincat-validator-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/agenticcontrolio/twincat-validator-mcp'

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