control-expert-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have clearly distinct purposes, with descriptions that specify their exact scope. A few pairs like get_dtm_dataset/get_master_dtm_dataset and set_dtm_dataset/set_master_dtm_dataset could cause confusion, but descriptions clarify the distinction.
Naming Consistency4/5Tool names predominantly follow a verb_noun snake_case pattern (e.g., add_drop, create_section, list_variables). A few names like configure_cpu_ethernet are longer, and some use different verb prefixes (e.g., new_project, change_cpu), but overall the pattern is consistent.
Tool Count3/552 tools is high for a single server, but the domain of PLC configuration and programming is complex, justifying many tools. The number is borderline; some tools could be consolidated (e.g., multiple DTM-related tools), but the granularity aids clarity.
Completeness5/5The tool set covers the full project lifecycle, hardware configuration, programming, variable management, simulation, and settings. All major operations are present, and there are no obvious gaps for the intended domain.
Average 3.8/5 across 52 of 52 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only says 'delete', omitting any behavioral traits like reversibility, permissions, 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise but severely under-specified. It lacks critical information despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, or parameter details, the description is incomplete. The agent cannot reliably invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Two required parameters with 0% schema coverage and no explanation in description. 'task' and 'section' are undefined, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'program section from a task'. It distinguishes from siblings like create_section (create) and read_section (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., delete vs modify). No prerequisites or context provided.
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 provided, so description must carry burden. It states 'remove' but does not disclose destructive behavior, reversibility, permissions needed, or side effects. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but omits necessary details. Lacks structure to cover essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, 0% schema coverage, and no output schema, the description is severely incomplete. Does not explain return value or post-removal state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the meaning or purpose of parameters like rack, drop, bus beyond implying slot location. Agent has no guidance on how to use these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'remove' and resource 'module at a rack slot', which is clear and distinct from siblings like add_io_module and replace_io_module. However, it could be more specific that it is an IO module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., replace_io_module). No prerequisites or context for usage provided.
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?
Without annotations, the description must disclose behavioral traits. It only implies a write operation ('Set') but does not clarify whether changes are immediate, require a reboot, or affect other network settings. No details about authorization or side effects are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and additional context that could be included without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, no output schema, and no annotations, the description is too sparse. It omits important details like return values, potential errors, and behavior when parameters are invalid. An agent would lack sufficient context to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description should add meaning to the parameters. It mentions 'static IP configuration' which hints at ip_address, subnet_mask, and gateway, but does not explain the 'name' parameter or provide format constraints. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'static IP configuration of a logical Ethernet network'. It distinguishes the tool's purpose from siblings like 'configure_cpu_ethernet' which likely involves more than IP configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as 'add_network' or 'configure_cpu_ethernet'. There is no mention of required context or preconditions.
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 provided, so description must disclose behavior. It only states 'delete' without explaining permanence, error handling (e.g., if table doesn't exist), or side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but under-specified. A single sentence lacks enough detail for an AI agent to use the tool correctly, especially without schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers the core purpose. However, it omits behavioral details like error conditions and required permissions, making it only marginally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the only parameter 'name'. The description adds only 'by name', but doesn't explain format, case sensitivity, or how to obtain the name (e.g., from list_animation_tables).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (animation table), and the method (by name). It distinguishes from sibling tools like create_animation_table or list_animation_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, prerequisites (e.g., table must exist), or when not to use it. No mention of alternatives for handling animation tables.
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 must disclose behavioral traits. It mentions deletion of children but lacks warnings about irreversibility, permission requirements, 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy, but it is under-specified. It is concise but could include more useful detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter, the description provides the basic action but lacks completeness on error handling, confirmation, or data persistence implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'by name', adding minimal meaning. The parameter 'name' is not explained beyond being a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete', the resource 'DTM (and its children)', and the method 'by name'. It distinguishes from sibling tools like add_dtm or list_dtms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like list_dtms or get_dtm_control_parameters. No prerequisites or conditions are mentioned.
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, and the description does not disclose any behavioral traits beyond the fact that it performs deletion. Information about reversibility, permissions, or side effects is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is slightly under-specified; a bit more detail would improve it without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is too brief. It does not explain what happens upon deletion or clarify the context of 'global variable'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'name' parameter. The description adds minimal meaning—it states deletion by name but does not explain the nature or constraints of the name (e.g., case sensitivity, scope).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and clearly identifies the resource ('global variable by name'). It distinguishes from sibling tools like create_variable, update_variable, and list_variables by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are there any prerequisites or when-not-to-use scenarios 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?
No annotations provided, so description must bear burden. It discloses output format (XML) and compatibility with import_xml, which is helpful. However, it doesn't state side effects, authentication, or error behavior. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Information is front-loaded. Could benefit from brief parameter descriptions, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description lacks detail on return format specifics, error conditions, and prerequisites. With no annotations, more behavioral context is needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description does not explain the two required parameters ('task' and 'section'). No additional meaning is added beyond their names. Agent would need external knowledge to use correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads a program section as Control Expert XML, using specific verb 'Read' and resource 'program section'. It distinguishes from siblings like create_section and delete_section by focusing on reading existing logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use. Implicitly it's for reading section logic, but lacks alternatives or context like 'use import_xml for writing'. Siblings listed but not compared.
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 must disclose behavioral traits. It only says 'Replace' without mentioning side effects, authorization needs, or whether the change is reversible. The lack of safety or context makes it insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is both concise and informative, with no wasted words. It effectively communicates the core action and provides an example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema), the description is mostly adequate but lacks details about return values, success indicators, or constraints on when a CPU can be replaced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description partially compensates with an example ('BMX P34 2020' + '02.70') that gives format and context for the two parameters, but does not fully explain their meaning or sources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Replace the project's CPU with another from the hardware catalog' with a concrete example. This is a specific verb+resource pair that distinguishes it from sibling tools like 'configure_cpu_ethernet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or what prerequisites exist. The description only states what it does, not when it's appropriate.
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 partially discloses type_name and address formats, but fails to mention side effects (e.g., duplication errors), triggers (e.g., rebuild), or permission requirements. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, with key information front-loaded. Every sentence adds value. Could be slightly improved with structured list, but perfectly adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is incomplete. Missing details on error handling, return values, and constraints beyond type_name and address. Leaves many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds meaning: explains type_name (IEC types, arrays, DDT/DFB) and address (topological address). However, it does not clarify name, comment, or initial_value syntax or constraints, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a global variable' with specific verb and resource. It distinguishes from siblings like update_variable and delete_variable by explicitly focusing on creation. Additional details on type_name and address add precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like update_variable or list_variables. The context of 'global variable creation' is implied but there's no mention of prerequisites or exclusions, leaving the agent to infer usage from purpose.
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?
The description indicates a read-only operation ('Read'), which is consistent with the tool's purpose. However, without annotations, it does not disclose any additional behavioral traits like permissions, side effects, or limitations. The detail on output is helpful but does not fully compensate for the lack of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and output details. However, it could be more structured by explicitly listing the parameter's role or breaking into bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a good overview of the return value (XML content), compensating for the lack of an output schema. However, it fails to explain the parameter, which is a gap for a simple tool with one input. No error scenarios or completion cues are mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'name' is required but the description provides no explanation of its meaning or expected value (e.g., the name of the DTM). With 0% schema description coverage, the description should clarify this but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: reading control parameters of a master/communication DTM. It details the output as XML with specific fields (Modbus TCP I/O scanner lines, IP, unit id, etc.), and distinguishes from sibling tools like set_dtm_control_parameters which writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_dtm_dataset or set_dtm_control_parameters. The description does not include prerequisites, conditions, 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, the description should fully disclose behavioral traits. It only says 'Import' without detailing if it overwrites, requires permissions, or side effects on the device.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no wasted words, front-loaded with the key action. Could add more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing prerequisites, return value, error handling, and format expectations. For a 2-param mutation tool with no output schema, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not clarify what 'name' and 'xml' represent, leaving the agent to infer from the tool purpose alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Import' and the resource 'slave DTM configuration dataset', contrasting with siblings like get_dtm_dataset (export) and set_master_dtm_dataset (master vs slave).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies that the dataset should be previously exported with get_dtm_dataset and possibly modified, giving clear context for usage. However, it does not explicitly state when to use alternatives like set_master_dtm_dataset.
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 fully disclose behavioral traits. It mentions that bus is a substring and drop is a topo number, but does not state whether the operation is idempotent, what happens if the bus does not exist, or any side effects. For a modifiable tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the action and example, the second gives usage workflow. It is efficient and front-loaded, though the first sentence could be slightly more concise. Overall, it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no output schema, no annotations), the description covers purpose and basic parameter info, but lacks details on part_number and version, error conditions, return value, or safety implications. It is somewhat complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains 'bus' and 'drop' (e.g., bus substring, drop topo number), but leaves 'part_number' and 'version' unexplained. This partial coverage adds some value but does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a drop to a bus, provides a concrete example (remote X80 EIO drop on M580), and distinguishes itself from sibling tools like add_rack and add_io_module by positioning these as subsequent steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context by noting that bus is a substring from get_hardware and that drop is the topo number. It also guides the user to use add_rack and add_io_module afterward, but lacks explicit when-not-to-use guidance 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lacks details on side effects, idempotency, permissions, or constraints (e.g., what if rack already exists?). Only mentions the action and workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the second is long with a parenthetical. Still concise and front-loaded, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 4 required, no output schema, and no annotations, the description is incomplete. It lacks details on parameter constraints, post-conditions, and error scenarios for a hardware configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description mentions part_number example and default version but does not explain bus, drop, rack, or their valid values. The workflow hint references bus and drop but not as parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a rack to a drop, with an example ('BME XBP 1200' in a remote EIO drop). It differentiates from siblings like add_io_module by describing a workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use this tool (add rack) and then use add_io_module with specific instructions (set drop/bus to target the remote rack; remote drops start with a CRA adapter). Tells the user exactly how to proceed.
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?
Without annotations, the description carries the burden and does well by detailing the internal XML structure (SlaveDevice, ModbusTCP, ManagedModbusRequest). It implies a read-only operation via 'Read'. However, it does not disclose prerequisites (e.g., project must be open) or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the first clearly stating the purpose. The second sentence is dense but informative, covering key XML elements. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return structure (XML elements and attributes like SlaveDevice, ManagedModbusRequest). Missing details on output format (string vs. object) and error handling, but sufficient for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'dtm' has no schema description, but the description adds meaning: 'dtm defaults to the first (CPU) DTM node'. This tells the agent what the parameter represents and its default behavior, which is valuable beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the master/CPU DTM dataset XML and specifies its content (Modbus TCP scan lines). It mentions the 'first (CPU) DTM node' default, but does not explicitly differentiate from sibling 'get_dtm_dataset', though the naming implies a distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'get_dtm_dataset' or 'set_master_dtm_dataset'. The description only hints at usage via the 'dtm' parameter default, but lacks when-to-use or when-not-to-use instructions.
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?
Describes return value (build state, output text) and default behavior. With no annotations, it covers key aspects but lacks details on side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with parameter behavior, then return and usage context. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main aspects: purpose, parameter, return values, prerequisite. Lacks output format details but sufficient for a simple tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains the single boolean parameter clearly: default false for incremental, true for full rebuild. Adds meaning beyond the schema which only provides name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool builds a project (incremental or full rebuild). Mentions prerequisite for transferring, distinguishing it from analysis tools. However, no explicit comparison to sibling tools like analyze_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: incremental by default, full rebuild on parameter, prerequisite for transfer. But no when-not-to-use or alternatives given.
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 carry the full burden of behavioral disclosure. It implies a read operation ('list') but does not explicitly state that it is read-only, requires no permissions, or has no side effects. More transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without any redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is sufficiently complete. It explains the scope (user data types, DFB and DDT, with versions) and does not require additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema description coverage is 100%. The description adds value by explaining what kinds of data types are listed (DFB and DDT), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('user data types'), and specifies the subtypes ('DFB types and DDTs (structured/array types)') with version info. It distinguishes from sibling tools that deal with other entities like variables or networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any prerequisites or exclusions. It simply states what it does, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: reload from exchange archive, project becomes unsaved, validation rules for GUIDs and indices, and the need to subsequently build and save. It does not cover authorization or error handling, but the side effects are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long with a full XML example and detailed rules. While front-loaded with the purpose, it could be more concise by summarizing the XML structure, but the detail is useful for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and no output schema, the description explains the outcome (project reloaded, unsaved) and next steps (build_project, save_project). It also references where the result appears (get_dtm_control_parameters), providing good contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description fails to explain the 'xml' and 'dtm' parameters. The XML snippet suggests the format but does not map to the parameters, leaving the agent unclear about what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Write back a modified master DTM dataset (adds/edits Modbus scan lines) and reload the project', which is a specific verb and resource, clearly distinguishing it from siblings like set_dtm_dataset or get_master_dtm_dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed instructions on how to construct the Modbus request node and states that after the call the project is reloaded and unsaved, advising to run build_project and save_project. It does not explicitly mention when not to use it or alternatives, but the context is clear.
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 exist, so the description carries full burden. It discloses that the tool creates .xef or .zef files and affects the full application, but it doesn't mention side effects like overwriting files, permission requirements, or whether the project must be open. This is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, fitting in one sentence that covers the main action and use cases. It could be slightly improved by separating the usage guidance into a second sentence, but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides good context about formats and use cases. However, it lacks details on file path format, overwrite behavior, and any constraints, which would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'path' is not explained in the description. Despite 0% schema description coverage, the description does not clarify that 'path' is the output file destination. This is a significant omission for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'export' and the resource 'full application', specifying the output formats .xef and .zef XML exchange file. This distinguishes it from sibling tools like export_xml that likely export different formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool: 'useful for backup, diffing, or migrating between Control Expert versions.' It does not explicitly mention when not to use it or compare with alternatives, but the context is clear.
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. Discloses it is a read operation listing tables, but does not mention permissions, scope (e.g., current project only), or output format. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Front-loaded with verb and noun, parenthetical adds clarity without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers the core purpose. Could optionally specify the return structure (e.g., table names only), but overall sufficient for an agent to decide when to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist. Description adds value by defining what animation tables are, which aids understanding of the tool's purpose. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'list' and resource 'animation tables', with an explanatory parenthetical defining them as 'watch tables used to monitor and force variable values online'. Differentiates from sibling tools like 'create_animation_table' and 'delete_animation_table'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'get_project_structure' or 'list_variables'. No context about prerequisites or typical use cases.
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 the description must cover behavior. It states the tool lists variables (read-only), but doesn't disclose potential performance implications, pagination behavior beyond the max_results parameter, or whether the list is exhaustive. The filter behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence front-loads the core purpose and returned fields. The second adds specific filter detail. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema, the description is adequate. It lists the returned fields and filter behavior. Sibling tools are mainly mutation tools, so purpose is clear. Could mention that it returns only top-level (non-array/nested) variables, but global scope is already stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explicitly explains name_filter's substring matching behavior, adding value. However, max_results is not mentioned, leaving the agent to infer its purpose from the default value and name. Missing explanation of max_results limits completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List global variables' with specific fields (type, comment, address, initial value). This distinguishes from sibling tools like create_variable, update_variable, etc., which are mutation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes name_filter's case-insensitive substring match, giving clear guidance on when to use the filter. However, no explicit when-not or alternatives are mentioned, and there's no mention of other filtering or sorting options.
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 and discloses key behaviors: closing the previous project without saving (destructive) and the long opening time. Additional details like success/failure indication or authentication requirements would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences cover purpose, formats, side effect, and timing. No redundancy or unnecessary detail; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core purpose, side effects, and timing, but lacks details on return value, error behavior, prerequisites (e.g., file existence, permissions), and any post-open state. For a simple open tool, it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no information about the 'path' parameter beyond the schema's type and name. It does not explain allowed path formats, relative vs. absolute paths, or file location constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a Control Expert project file, lists supported formats (.stu, .sta, .xef/.zef), and notes the side effect of closing any previously open project. This distinguishes it from sibling tools like close_project, new_project, or save_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to open existing project files and provides format support. It also alerts users to the expected duration (30-120 s). However, it does not explicitly state when not to use it or mention alternatives like new_project for creating projects.
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, description adds value by stating modules are kept if new rack has same slots. It could mention what happens if slots differ or if rack isn't changed (e.g., error handling), but current info is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and example. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 7 params, no output schema. Description provides a good overview but lacks details on parameter meanings and edge-case behavior (e.g., mismatched slots). Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only implicitly explains part numbers/versions through example. Parameters like rack, drop, bus are not explained, leaving gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it replaces a rack in place, preserving modules where slots match, with an example. This differentiates it from siblings like add_rack or replace_io_module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (changing rack model) but does not explicitly instruct when to use this tool over alternatives (e.g., add_rack). No when-not or prerequisites 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?
No annotations are provided. The description discloses that only non-empty arguments are applied and how to clear attributes. It does not cover side effects, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the purpose, and the second provides crucial usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core update semantics and clearing method, but with 5 parameters and no output schema, it omits return values, validation, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds general behavior about argument application and clearing. It lacks per-parameter details (e.g., what 'address' or 'initial_value' represent), only partially compensating for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update attributes of an existing variable,' which uses a specific verb and resource. It distinguishes from sibling tools like create_variable and delete_variable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage instructions: 'Only the non-empty arguments are applied' and how to clear an attribute by passing a single space. However, it lacks guidance on when not to use this tool or alternatives.
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, the description carries full burden. It indicates a creation operation but does not disclose idempotency, error handling, or permissions. The listing of language options adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that convey essential information without waste. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main purpose, language options, and follow-up action. Missing details like return value, duplicate behavior, or prerequisite that the task must exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the 'language' parameter is explained with valid values. The 'task' and 'name' parameters are not described in the description, and the schema provides no descriptions, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (empty program section), and the context (in a task). It distinguishes this from sibling tools like delete_section and read_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to create a section and a follow-up action (import_xml). However, it does not explicitly exclude scenarios or mention prerequisites like task existence.
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 exist, so description carries full burden. It explains creation action and periodicity effect but omits details like side effects, error conditions, or return value. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core action and then add parameter details. No redundant words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers primary functionality but lacks context on project status requirements, return values, and constraints. For a creation tool with no output schema, some additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description compensates by enumerating task_type values and explaining periodicity_ms behavior (makes task periodic if >0). This adds meaningful context beyond raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Add a task to the project' and lists valid task_type values (MAST, FAST, AUX0..AUX3, SAFE). Differentiates from sibling tools that create other entities like sections or variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides allowed values for task_type but lacks explicit guidance on when to use this tool versus alternatives. No mention of prerequisites like project state or when periodic tasks are appropriate.
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, the description carries the burden of disclosure. It correctly identifies the operation as a read (non-destructive) but does not mention potential side effects, permissions, or rate limits. The context about .xef files is helpful but not sufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource. Every sentence adds value: the first states purpose, the second provides identifier context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description covers the input well but does not specify what the return value looks like. An agent might need to infer the output format. It is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 'ident' as a project setting identifier, gives concrete examples, and describes where to find them (exported .xef file). 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and resource 'project setting value by its identifier', with examples like 'unity.multiAssign'. It clearly distinguishes from sibling tool 'set_project_settings' which writes settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading settings by ident, but does not explicitly state when to use this tool versus alternatives like 'set_project_settings'. No exclusions or prerequisites 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?
The description discloses a key constraint (exact match required) and the fact that the slot is preserved. However, it lacks details on permissions, irreversibility, or side effects. With no annotations, the transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the core action, a key feature, a prerequisite, and an example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and a critical constraint, but given the complexity (8 parameters) and lack of output schema, it omits details on parameter semantics for drop and bus, and on post-replacement behavior. It is adequate for an experienced agent but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for five required parameters (slot, old_part_number, old_version, new_part_number, new_version) and mentions rack via the example, but it does not explain drop and bus. Given 0% schema coverage, the description partially compensates but remains incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces a module in place while keeping the slot, which distinguishes it from siblings like remove_io_module (removal) and add_io_module (adding to a new slot). The example of swapping the default power supply reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: the old part number and version must match the current module exactly, and it references get_hardware for verification. It does not explicitly state when not to use this tool, but the context is sufficient for an agent to infer appropriate usage.
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 states 'list', which implies a read-only operation, but does not explicitly confirm non-destructive behavior, permissions, or output format. The lack of annotations is compensated somewhat by the clear verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the verb and resource. No unnecessary words, and every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the resource type and what information is returned ('IP service configuration where available'). However, without an output schema, the return format is not fully described, but it is adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description does not add parameter semantics because there are none to describe. Schema description coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'logical networks', specifies the types (Premium/Quantum: Ethernet, Modbus Plus, Fipway), and mentions the included information (IP service configuration). This distinguishes it from sibling tools like 'add_network' or 'set_network_ip'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'list' implies a read operation, and sibling tools like 'add_network' and 'set_network_ip' serve as alternatives for modifications. However, there is no explicit guidance on when to use this tool versus other list tools (e.g., 'list_variables') or 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, the description carries the full burden. It explains the build parameter's effect (rebuilding DTM→PLC control info) and recommends reading first, implying potential overwrite risk. However, it does not state whether the tool is destructive (e.g., overwrites without confirmation) or describe other side effects, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the main action and key detail, then providing additional context. Every sentence serves a purpose without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides sufficient context for an agent: it explains the action, format, a key parameter effect, and a safety recommendation. It lacks explicit details on what name refers to and the exact format of the XML, but overall it is reasonably complete for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 xml parameter as CetControlParameterInput XML, the build parameter as controlling rebuild, and mentions 'mirror the schema' for xml structure. However, it does not define the name parameter or provide full detail on format or constraints, adding some but not complete meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a master DTM's control parameters, specifying the XML format and purpose (scanner sizing and %MW mapping). It distinguishes from the sibling get_dtm_control_parameters by indicating it is for writing, and includes a caution to read first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to read current values with get_dtm_control_parameters first and mirror the schema, providing clear context for safe usage. It implies when to use (when writing control parameters) and offers a precaution, but does not explicitly state when not to use or list alternatives beyond the read tool.
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 explains the tool creates or replaces section logic, describes the syntax of st_source and the declare parameter, and notes that FB instances must be declared. This adds valuable behavioral context, though it omits details like permissions 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of five sentences, efficiently conveying purpose, syntax, and follow-up. It is front-loaded with the main action and uses examples sparingly. No unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, no annotations, no output schema), the description covers core aspects but lacks explicit prerequisites (e.g., open project) and error handling. The mention of build_project helps, but overall completeness is adequate with gaps in setup and result expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds meaning for st_source (raw ST syntax) and declare (comma-separated name:TYPE list with examples), but task and section are only implied as identifiers for the section location. This partial coverage is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a program section in IEC 61131-3 Structured Text, distinguishing it from XML-based tools. It specifies the action (write/create/replace) and the resource (program section), making the 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (plain ST, no XML required) and mentions a necessary follow-up (run build_project). However, it does not explicitly differentiate from sibling tools like create_section or export_xml, though the ST focus implies alternatives.
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, the description carries full burden. It discloses that large exports go to a temp file and returns a path instead of inline XML. However, it doesn't specify if the tool is destructive, read-only, or any permission requirements. The output format (inline XML vs file path) is partially described but lacks details on how to retrieve the file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a few sentences to convey all critical information. No wasted words, and the structure (inline list of kind options) is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so description should cover return values. It mentions inline XML for small exports and file path for large ones, but doesn't specify the exact format of the path or potential error conditions. Given the complexity and lack of schema coverage, it's moderately complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates well. It explains the kind parameter in detail and clarifies when name and task are required (for dfb and section). This adds meaning beyond the schema, though task and name are not fully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports project content as Control Expert XML and returns it inline. It details the different kinds of export (variables, program, configuration, dfb, section), which distinguishes it from siblings like export_project and import_xml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use each kind parameter, including requirements for dfb (requires name) and section (requires task and name). It also mentions handling of large exports via temp file. However, it lacks explicit when-not-to-use or alternative tools.
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 the full burden. It discloses the XML structure containing Modbus scan lines and hints at the editing workflow. However, it does not mention safety, permissions, or side effects, which would be expected for a read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes useful technical detail without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and absence of output schema, the description is mostly complete, covering purpose, data structure, and related tool. However, it lacks specifics on output format (e.g., plain XML string vs file) and prerequisites like DTM existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only vaguely implies that 'name' identifies the DTM, but does not explain what the parameter represents or any constraints. The description fails to add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Export) and the resource (DTM's full configuration dataset). It distinguishes itself from sibling tools like set_dtm_dataset by mentioning the XML content and the write-back process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the use case for M580 master DTMs, providing context. It implicitly suggests when to use (export) and references set_dtm_dataset for writing back, but does not explicitly state when not to use or compare with alternatives like get_master_dtm_dataset.
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. Description lists returned information but does not disclose behavioral traits such as side effects, authentication requirements, or rate limits. Partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no unnecessary words. Efficiently communicates the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with no parameters and no output schema, the description adequately explains the return content. Complete given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is 100%. Description adds value by specifying what status details are returned, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the current session status' and lists specific return fields (server version, project openness, file path, CPU, version, build state), distinguishing it from sibling tools that perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like get_project_structure or get_hardware. Usage is implied but not differentiated.
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 the action (add to slot) and defaults, but does not describe conflict behavior (e.g., if slot occupied), error conditions, or whether the operation is reversible. Without annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with purpose, followed by constraints and examples. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects for a 6-parameter tool: purpose, parameter constraints, defaults, and topology reference. Lacks return value or error handling, but adequate for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning for part_number and version via examples, clarifies slot, and notes defaults for rack/drop/bus. Missing explicit explanation of drop negative value or bus string format, but sufficient for agent usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a hardware module to a rack slot, with specific examples (IO, communication). It distinguishes from sibling tools like remove_io_module and replace_io_module by focusing on addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on matching part_number and version to the hardware catalog, slot position, and defaults for rack/drop/bus. Refers to get_hardware for topology. Lacks explicit exclusions or alternatives but covers primary use context.
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 full burden. It reveals the tool creates a logical network (a write operation) and gives platform-specific behavior. However, it lacks details on failure modes, permissions, or side effects. The behavioral context is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose and scope, second gives exclusion and alternative. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is fairly complete. It explains the tool's function, when to use it, and provides a parameter example. It lacks details on return values or error handling, but for a create tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 provides an example for 'family' ('Ethernet'), adding meaning beyond the schema. However, it offers no additional explanation for 'name'. The compensation is partial but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('logical network'), specifies target platforms (Premium/Quantum), and gives an example for the 'family' parameter ('Ethernet'). It also differentiates from sibling tools by explicitly stating when not to use it (M340/M580).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (Premium/Quantum platforms) and when not to (M340/M580), with an alternative action ('configure communication on modules/DTMs instead'). This provides clear guidance and distinguishes from siblings.
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. Description discloses that it fills table with variables and shows live values, but does not mention any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with example, front-loaded action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for simple tool with two parameters. No output schema, but purpose and usage are sufficiently explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions for parameters. Description adds meaning: explains 'variables' as comma-separated list with example, improving understanding beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'create' and resource 'animation table', with specification that it can also add to existing table. Distinguishes from sibling tools like delete_animation_table and list_animation_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States that table shows live values when project online, implying when to use (online monitoring). Does not explicitly exclude alternatives but context is clear.
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 provided, so description carries full burden. It discloses that the tool returns a tree structure with part numbers, versions, and addresses, and implies no side effects for a 'get' tool. Good, but could mention permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, well-structured, no fluff. Lists all key elements efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description detailed enough to understand return values. For a simple listing tool, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (empty schema, 100% coverage). Description adds no parameter info needed. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists the full hardware configuration including CPU, bus-drop-rack-module tree, part numbers, versions, and topological addresses. It distinguishes itself from sibling tools like get_project_structure or get_dtm_* by specifying the hardware focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. The description implies it's for overall hardware tree, but does not mention exclusions or compare to other listing tools. Score 3 as usage is implied but not explicitly clarified.
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 burden. It clearly states the tool lists DTM topology with specific attributes, implying read-only behavior. It does not mention any side effects, performance, or limitations, but for a simple list tool this is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and resource, with no superfluous words. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides the essential information for a list tool: what is listed and with which attributes. It could mention if the list is flat or hierarchical, but overall it is complete enough for an agent to understand its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no param information to add. According to guidelines, 0 parameters gives a baseline of 4, and the description meets this expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'DTM topology' and specifies included items (communication/master DTMs and slave devices) with attributes. It clearly distinguishes from siblings like 'get_hardware' or 'get_project_structure' by focusing on DTM browser view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 like 'get_hardware' or 'get_project_structure'. While the purpose is clear, the lack of contextual usage instructions limits its helpfulness.
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 covers key behaviors: project reload from patched archive and unsaved state requiring subsequent build/save. Does not mention side effects or permissions but adequate given context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, examples, critical warning. No fluff, front-loaded, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param tool with no output schema, description covers purpose, parameter examples, and essential post-conditions. Minor gaps in error handling but adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description adds common idents and value types (strings), compensating well. Could clarify object structure more explicitly but provides sufficient examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'project settings' with scope 'one or more'. It distinguishes from sibling tools like get_project_setting (read) and build_project/save_project (subsequent steps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for modifying settings but does not explicitly contrast with get_project_setting or mention when not to use. Provides post-condition guidance (unsaved, needs build/save) which is helpful but no alternatives named.
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, the description carries full burden for behavioral traits. The description states it stops a process, but does not disclose potential side effects (e.g., data loss, cleanup, permissions). For a simple action, this may suffice, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence of 5 words. It is front-loaded and contains no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, straightforward action), the description is mostly complete. However, it lacks information about return values or confirmation of success. Still sufficient for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline for '0 params' is 4. The description does not need to add parameter meaning as none exist. Schema coverage is 100% vacuously.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop the PLC simulator process' uses a specific verb ('stop') and a clear resource ('PLC simulator process'), distinguishing it from siblings like 'start_simulator'. It is unambiguous and precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use or exclusions are stated, the context is clear: this tool is for stopping the simulator. The sibling tool 'start_simulator' implies the opposite action, so usage context is inferable. A slight improvement would be to explicitly contrast with start_simulator.
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 provided, but description discloses creation behavior and hierarchy. Does not mention permissions or side effects, but covers what the tool does adequately for a non-destructive add operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with two paragraphs; front-loaded key action, then examples. No fluff, but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, description covers main use cases and parameter roles. Does not explain return values or error conditions, but acceptable for an add tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, description explains device_type_name (catalog entry) and parent_dtm (empty/name) well, but omits protocol_id, prog_id, version. Required params are covered, but not all six.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a DTM to the project topology', specifies top-level vs slave, and distinguishes from sibling tools like delete_dtm and list_dtms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use parent_dtm (empty for top-level, set for slave) and provides follow-up steps (set_dtm_address, etc.). Differentiates from other add tools targeting different resources.
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?
Description discloses the key behavioral nuance: unsaved changes are discarded when save=False. No annotations are provided, so the description carries the burden for transparency. It does not mention what happens after close, but the basic behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no wasted words. Information is front-loaded: first sentence states the action, second explains the parameter's impact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one boolean parameter and no output schema, the description is largely complete. It could mention the post-close state (e.g., no project open), but that is inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining the save parameter and its effect on unsaved changes. This adds essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool closes the open project, with an optional save before closing. Verb 'close' and resource 'open project' are specific and align with sibling tools like open_project and save_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you want to close the project. However, no explicit contrast with alternatives like save_project or new_project is provided, nor is there guidance on 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the returned guide is validated against a live build and provides example section, implying a non-destructive read operation. Could be more explicit about read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but a bit verbose with workflow details. It is front-loaded with 'REQUIRED READING' and structured, though some sentences could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description provides thorough context: what the output contains, workflow, and cross-reference to another tool, making it complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage; the description mentions example languages ('ST', 'LD', 'FBD', 'SFC', 'IL') but does not explicitly describe the 'language' parameter, leaving it unclear what values are acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the authoring guide for a Control Expert language, including XML structure rules and a complete example. It distinguishes from siblings by mentioning write_st_logic for ST.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is required reading before writing logic, provides a step-by-step workflow, and advises to prefer write_st_logic for ST, making usage context very clear.
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 behavioral traits like import modes (overwrite, keep_existing, rename) and strict schema validation. It could further detail side effects or permissions but covers key aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, front-loaded with purpose, and uses a list format for kinds. Minor redundancy exists but is acceptable for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers kind, mode, and usage tip, but lacks return value or confirmation of success. No output schema exists, so description should hint at what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds comprehensive meaning for all parameters: kind enumerates allowed values, xml_content/file_path sourcing, task requirement for sections, and import_mode values. This fully compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports Control Expert XML into the open project, listing specific kinds and import modes. It distinguishes itself from siblings like export_xml through explicit purpose and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context as the main way to write program logic and bulk content, and includes a tip to export first. However, it does not explicitly state when not to use or compare to alternative tools.
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. Discloses that the tool performs a save (write operation) and distinguishes between save-in-place and save-as. Does not detail overwrite behavior or validation of path, but sufficient for a save tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, every sentence provides essential information with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description fully covers the tool's operation and parameter usage, with no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% but the description explains the parameter's purpose and format (ending in .stu), adding significant value beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it saves the open project and distinguishes between first save/save-copy (with path) and save-in-place (empty path). This differentiates it from siblings like export_project or new_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to provide a path (first save or save copy) and when to leave it empty (save in place). Could mention alternatives like export_project for other formats, but still clear.
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 burden of behavioral disclosure. It accurately states that the tool lists (read-only) and details the content, but does not explicitly declare it is read-only or discuss any potential side effects. This is sufficient given the tool's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that communicates all essential information without unnecessary words. Every part contributes to understanding the tool's output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides a complete overview of what the tool returns, which is sufficient for an agent to understand its purpose and output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, and the description coverage is 100%. The description adds value by explaining what is returned, meeting the baseline for 0-parameter tools. No parameter detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'List' and resource 'program structure' are clear. It specifies exactly what is listed (tasks, scan settings, sections, IEC language, counts) and distinguishes itself from siblings like 'get_hardware' or 'get_language_reference' by focusing on the overall structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states when to use (when you need to list the program structure), but does not explicitly mention when not to use or provide direct comparisons to alternatives. However, the context is clear, warranting a 4.
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 that the project exists only in memory until saved, which is a critical behavioral trait. It also specifies exact match requirements for cpu_part_number.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description covers creation, persistence, and parameter constraints fully. An agent can use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining that cpu_part_number must match the catalog and providing examples, requiring cpu_version, and noting the default for project_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new project from scratch for a given PLC CPU.' with specific verb and resource. It distinguishes from sibling tools like save_project and open_project by specifying the creation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool and includes important follow-up action (call save_project). It does not explicitly state when not to use it, but the context is sufficient.
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 carries full burden and excellently discloses key behavioral traits: setting gateway/subnet rewrites the project archive, project is reloaded and unsaved, requiring follow-up with build_project and save_project. Also mentions domain mismatch warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the core purpose then providing necessary details. It is slightly long but every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description covers parameter formats, side effects, and prerequisites well. It doesn't explain return values or error cases, but overall is fairly complete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage), but the description adds meaning for address (protocol-specific format), gateway (IP domain constraint), and subnet. The 'name' parameter is not explained, but it's reasonably inferable as identifier. Overall good compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting a slave DTM's bus address, distinguishing between Modbus TCP/EtherNet/IP and fieldbus protocols. It differentiates from siblings like set_network_ip by focusing on DTM address configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (for setting address or optionally gateway/subnet), but does not explicitly mention alternatives or when not to use it. It gives a clear usage scenario with protocol-specific details.
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 action and possible states. However, it omits details about side effects (e.g., focusing, error conditions) or that it's non-destructive. Still adequate for a simple UI action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first specifies the action and purpose, second enumerates states. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose and parameter values. Lacks mention of behavior when already visible or error handling, but is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, leaving the parameter 'state' undocumented. The description fully compensates by listing the four valid values (show_normal, show_maximized, minimize, restore), adding essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Make visible' and the resource 'Control Expert window', distinctly differentiating from all sibling tools which focus on project and hardware 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the purpose 'so a human can watch or take over', implying when to use, but lacks explicit when-not or alternative guidance. Since no other sibling provides UI visibility, absence of exclusions is acceptable.
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?
Describes what sim.exe does, registry modification when enforce_security=False, and potential blocking if security is enabled without password-protected app. Lacks idempotency and error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, parameter behavior, and usage restriction. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter, and usage constraint. Lacks return value specification and prerequisites (e.g., Control Expert installation). Despite that, sufficiently complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains the 'enforce_security' parameter: default false, its effect on registry, and why it avoids a warning dialog. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool starts the Control Expert PLC simulator (sim.exe) for plc_connect to reach it. Distinguishes itself by focusing on starting, unlike sibling stop_simulator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly restricts use to 'only on a local test machine.' Explains default behavior and when enforce_security matters. No explicit comparison to non-sibling tools, but context is clear.
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?
Discloses it does not generate code and is faster, adding context beyond the lack of annotations. Could mention non-destructive nature, but sufficient for analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately covers purpose and usage. Could optionally mention error behavior, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Description adds no parameter info, but baseline is 4 due to zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs syntax/semantic analysis without generating code, distinguishing it from build_project. The verb 'analyze' and resource 'project' are specific and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using it to validate edits and notes it's faster than a build, providing clear guidance on when to use vs. siblings like build_project.
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, but description fully discloses behavioral traits: updates all stored copies, reloads project, leaves project unsaved, requires build_project and save_project, and mentions failure condition when service flags are disabled for CRA. Transparent about destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise given the complexity, starting with main purpose and then necessary details. Slightly dense but no wasted sentences. Could be broken into bullet points for clarity, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, 0 required, no output schema, and no annotations, description covers the core functionality, parameter meanings, side effects, and an error case. It does not explain return value or validation, but given the tool's nature (configuration action), that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must compensate. It explains main IP, subnet, gateway, ip_a/b/d, and service flags with their meanings. Service flag default -1 is explained. However, does not specify IP format or valid ranges, but covers semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it configures the M580 CPU's embedded Ethernet, listing specific parameters (main IP, subnet, gateway, HSBY addresses, service flags). It is specific and distinguishes itself from sibling tools by providing unique functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: for configuring CPU Ethernet and service flags. States service argument encoding (-1 unchanged, 0 disable, 1 enable). Warns about requirement for remote EIO drop's CRA and side effects (project reload, unsaved). Gives alternative for slave device gateway-domain warning (use set_dtm_address).
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/apexsotjo-blip/control-expert-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server