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

With no annotations provided, the description carries the full burden. It explicitly discloses a significant side effect: 'Kills CLASS 2 IDE before running.' This is critical behavioral information. It also implies the tool modifies project state (batch operations). It does not disclose reversibility or other side effects, but the IDE kill is a major disclosure that goes beyond typical expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the purpose and scope front-loaded. The first sentence states the primary function and lists representative operations; the second sentence warns about the IDE kill. There is no fluff or redundant content. It is efficient and well-structured for an agent scanning descriptions.

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

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

Given the tool's complexity (25 operation types, nested oneOf schema), the description provides the essential high-level context and the critical side effect. The schema carries detailed parameter information, so the description does not need to enumerate every operation. It might mention that operations are applied in order, but the schema already labels the array as 'Ordered list'. The description is sufficient for an agent to understand the tool's role and its main hazard.

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

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

Schema description coverage is 100% for the three top-level parameters (dry_run, lcp_path, operations). The schema already documents these, including a description for operations listing all available types. The tool description adds minimal extra meaning—it lists examples of operations, but these are already present in the schema. Thus, the description does not significantly augment parameter understanding beyond the baseline.

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

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

The description clearly states the tool's purpose: to run CLASS 2 batch engine operations. It lists specific operation categories (create/delete/rename networks, add/remove/rename objects, etc.) which distinguishes it from editing files directly. The verb 'Run' and resource 'CLASS 2 batch engine operations' are specific and unambiguous, and the scope is well-defined.

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

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

The description gives a clear usage condition: operations that cannot be done by editing files directly. This implies when to use this tool versus file editing. It does not explicitly name sibling tools like build_project or manage_class2, but the condition is a reasonable guideline. The mention of killing the IDE also warns about a side effect that affects when to use it.

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

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

Discloses important side effects: compilation kills the CLASS 2 IDE and download pings the PLC first. However, it does not explain consequences of ping failure, loader behavior, or whether state changes are reversible, leaving some behavioral aspects undocumented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise and front-loaded. The core purpose is stated in the first sentence, followed by clear behavioral warnings. No redundant or extraneous content.

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

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

Adequately covers inputs and key side effects, but with no output schema it does not describe expected return values, success/failure indications, or error handling. Given the moderate complexity and multiple parameters, this leaves some contextual gaps.

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

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

Schema descriptions already cover all parameters, and the description adds useful semantic details such as 'compile only', 'download only', default timeout, and using the connection saved in the .lss file. This enriches parameter understanding beyond the basic schema.

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

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

States a specific action: compiles a CLASS 2 project or downloads it to the PLC, clearly distinguishing the two main operations. The resource and verbs are explicit and differentiate this tool from related siblings.

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

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

Describes what the tool does but provides no explicit guidance on when to choose this tool over alternatives like apply_project_changes, deploy_all, or manage_class2. No use cases or selection criteria are mentioned.

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

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

The description discloses the additional behavior of pinging the target PLC before start/stop. However, it does not describe error handling or side effects, which would be expected without annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, with the primary action stated first and the additional behavioral detail in the second sentence. No unnecessary content.

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

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

The tool is simple with a single action parameter, and the description covers the core functionality. It doesn't specify return values, but given no output schema, that is not a major gap.

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

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

The input schema already provides full descriptions for all parameters, and the tool description does not add further semantic context beyond what is already in the schema.

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

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

The description uses a specific verb ('Start, stop, or query') and a clear object ('PLC runtime state'), making it distinct from sibling tools that deal with values, diagnostics, or project management.

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

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

It clearly states the tool's purpose but does not explicitly mention when to prefer this over sibling tools like lasal_status or plc_values. The ping note is more of a behavioral detail than a usage guideline.

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

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

The description transparently lists the main side effects (downloading to PLC, starting PLC, downloading Visu, starting HMI runtime, updating stations). Since no annotations are provided, the description carries the burden, and it does so reasonably well, though it does not explicitly warn about overwriting target systems.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the pipeline sequence and immediately notes that every step is optional. 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.

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

Given the rich input schema (15 parameters, all described), the brief description is sufficient to convey the overall purpose and flow. It does not need to repeat parameter details, and the pipeline steps align well with the boolean flags in the schema.

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

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

The input schema provides descriptions for 100% of parameters, so the baseline applies. The description itself adds little beyond the schema, but the schema's parameter descriptions are detailed and sufficient.

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

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

The description clearly identifies the tool as a full deploy pipeline and enumerates the exact sequence of steps it performs (compile, download PLC, start PLC, verify state, update Visu stations, download Visu, start HMI runtime). This distinguishes it from the individual sibling tools that handle only one step.

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

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

The description provides clear context: it is a full deployment pipeline, and each step is optional via flags, making it suitable for both full and partial deployments. It does not explicitly name alternative single-step tools, but the pipeline nature is clear enough for an agent to infer when to use it.

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

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

With no annotations provided, the description bears the full burden. It transparently lists all supported actions (open, screenshot, console, eval, click, type, wait, close) and clarifies that it runs headless. It does not detail side effects like session cleanup or potential interference, but the action list gives a clear behavioral model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, a single paragraph that lists actions and includes a high-priority usage directive. Every sentence adds value; there is no fluff or redundancy. The structure is clean and immediately readable.

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

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

While no output schema is provided, the action names imply return types (e.g., screenshot returns an image, console returns logs). The description does not explicitly state return formats, but the tool's purpose and action list provide enough context for an agent to use it correctly in most scenarios.

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

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

The schema covers 100% of parameters with descriptions. Each parameter is tied to specific actions (e.g., 'url' for open, 'clear' for console, 'expression' for eval), adding meaningful context beyond the schema structure. The nested 'viewport' object is also described, making the semantics clear.

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

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

The description clearly states the tool's purpose: automating a headless Edge browser to test the HMI. It lists specific actions and gives a concrete directive ('ALWAYS use this after deploy'), which distinguishes it from sibling tools like hmi_runtime or visu_project that focus on the runtime environment rather than browser-based visual verification.

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

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

The description explicitly says when to use the tool ('ALWAYS use this after deploy to visually verify the HMI works'), providing strong contextual guidance. It does not mention alternatives or when not to use it, but the explicit directive covers the primary scenario sufficiently.

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

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

No annotations, so description must disclose side effects. It explicitly mentions publishing, copying webroot, and spawning the DataService, which are relevant side effects. Does not mention potential cleanup on stop, but acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant information, well-structured.

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

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

Complete for the tool's purpose; no output schema, so no need to explain returns. Mentions service name and interaction pointer.

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

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

Schema covers all parameters with descriptions; description adds no additional semantics beyond restating publishFirst. Baseline 3.

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

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

States a specific verb (start/stop/check), the resource (local HMI web simulation, LasalVISUDataService), and differentiates from hmi_browser by pointing to it for interaction. Clear and specific.

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

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

Provides a hint to use hmi_browser for interaction after starting, but does not explicitly compare with lars_runtime or other management tools. Implicit usage context is clear, but explicit differentiation is lacking.

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

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

The description explicitly discloses side effects and destructive behaviors: list auto-cleans stale workspaces, start auto-creates workspaces, remove deletes workspace configs, gc deletes unreferenced workspaces (with a dry_run option to preview), set_station_target modifies .lss files, and target_pc switches compile targets. Even though no annotations are provided, the description carries the full burden and does so thoroughly, including the lazy cleanup behavior and the fact that changes alter station configuration.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, with a clear structure: an overall purpose sentence, a key architectural note (one workspace per station), and a colon-separated action list. Each sentence earns its place, though the repetition of action names in the initial summary and the action enum description is slightly redundant. It's not overly verbose for the complexity of the tool, but a more compact phrasing could improve clarity.

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

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

The description covers the tool's role within the broader ecosystem (e.g., interaction with build_project and deploy_all after set_station_target, the port separation between PLC and HMI). It also explains the purpose of the less obvious actions like target_pc and restore. There is no output schema, so return values are not specified, but the description is sufficient for an agent to understand when and why to call this tool and what side effects to expect.

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

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

The schema already provides descriptions for all seven parameters (100% coverage), so the baseline is 3. The tool description adds extra meaning beyond the schema: it explains the action parameter's semantics in detail (e.g., the auto-clean behavior of list, the auto-create behavior of start, and the lazy criteria for gc). This enrichment of parameter meaning, especially for action with its eight enum values, justifies a 4.

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

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

The description clearly states the tool's purpose: managing local LARS simulation instances, with a specific note about one workspace per station (PLC + HMI) running on separate ports. The list of actions (list, setup, start, stop, remove, gc, etc.) immediately distinguishes this from sibling tools like control_plc or hmi_runtime, which focus on other aspects of the runtime environment.

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

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

The description provides usage context for each action (e.g., 'start' auto-creates the workspace if unconfigured, 'gc' runs lazy garbage collection with specific retention rules). It also explains a cross-tool interaction: after set_station_target, build_project/control_plc/plc_values/deploy_all operate on the LARS instance. While it doesn't explicitly contrast with every sibling, the action semantics and the note about when to use this tool relative to others are clear enough for an agent to decide when to invoke it.

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

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

Since there are no annotations provided, the description carries the burden of transparency. It describes the tool as a check/status operation, implying read-only behavior without side effects. While it does not explicitly state 'read-only' or list potential side effects, the nature of the checks strongly suggests it is safe and non-mutating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, covering the tool's functionality and usage in a single sentence. It lists the key checks without unnecessary detail, and it is well-structured for quick comprehension by an agent.

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

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

Given the lack of parameters and output schema, the description provides sufficient context for an agent to understand what the tool does and when to call it. It does not describe return values or prerequisites, but these are not necessary for a status-check tool. The description is complete enough for its purpose.

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

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

The tool has no parameters, so there is nothing for the description to add beyond the empty schema. The baseline for 0 parameters is 4, and the description adequately conveys that no input is required. No additional parameter information is needed.

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

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

The description clearly states the tool's purpose: checking project selection, station discovery, PLC/HMI reachability, engine paths, running processes, and HMI runtime health. It also differentiates itself by indicating it is for orientation and diagnosing connection issues, which distinguishes 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.

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

The description provides explicit guidance on when to use the tool: 'Call to orient or diagnose connection issues.' This is a clear usage scenario, though it does not name specific alternative tools. The context of sibling tools implies that this is the go-to for status checks, which is sufficient.

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

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

The description discloses the primary behavior (open/close) and hints at a side effect (interference with batch operations if left open). However, it does not detail potential consequences like unsaved data loss, process termination, or confirmation prompts, and there are no annotations to supplement this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using only two sentences to convey purpose and a usage warning. It is well-structured and front-loaded, with no unnecessary detail.

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

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

The description is complete enough for the agent to know when and why to use the tool, especially with the batch operation warning. It does not mention return values or output, but since there is no output schema, this omission is acceptable.

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

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

The main description adds no additional meaning to the parameters beyond what is already in the schema. The schema covers both 'action' and 'lcp_path' with clear descriptions, so the baseline is appropriate; no extra parameter guidance is provided.

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

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

The description clearly states the tool's purpose: to open or close the LASAL CLASS 2 IDE GUI. It uses a specific verb ('open or close') and names the resource exactly, differentiating it from sibling tools like manage_visudesigner.

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

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

The description provides direct guidance on when to use the tool (open/close the IDE) and includes a specific caution: 'Close before running batch operations.' This gives the agent a practical condition, though it does not explicitly compare with alternatives.

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

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

No annotations are provided, so the description must carry the burden. It states the actions (open/close) and gives a reason for closing (before automated operations). However, it does not disclose potential side effects like unsaved changes being lost or the process being killed abruptly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with the purpose stated in the first sentence and usage guidance in the second. No fluff, front-loaded information, and easy to parse.

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

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

For a simple open/close tool with no output schema, the description provides sufficient context: what it does, when to use it (close before automated ops), and the parameters. It could mention the necessity of a project being selected, but that is inferable from the sibling tool 'select_project' and the optional 'lvp_path'.

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

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

The schema fully describes both parameters: 'action' with enum values and 'lvp_path' with a clear purpose. The main description adds context for when 'lvp_path' should be omitted. Since schema coverage is 100% and descriptions are meaningful, this is above the baseline.

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

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

The description clearly states the tool's purpose: 'Open or close the VISUDesigner GUI.' It identifies the specific resource (VISUDesigner GUI) and the action (open/close), distinguishing it from sibling tools like build_project or deploy_all.

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

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

Provides explicit usage guidance: 'Close before running automated visu operations.' This tells the agent when to use the 'close' action. The open action is implied as the natural counterpart. Could be slightly more explicit about when opening is needed, but the guidance is clear enough.

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

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

With no annotations, the description carries full responsibility for disclosing behavior. It does not mention that actions like file_delete or file_upload modify or delete data, nor does it warn about potential side effects or required permissions. The description is neutral and lacks transparency about the impact of certain actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that efficiently lists the three diagnostic categories without unnecessary words. It is well-structured and immediately understandable.

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

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

Given that the schema fully documents all parameters and there is no output schema, the description does not need to explain return values. However, because the tool combines multiple actions (trace, file ops, code analysis), a bit more contextual guidance on when each action applies would improve completeness, but it is not strictly required.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond the schema, but since the schema is fully documented, it meets the minimum standard.

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

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

The description clearly states the tool runs PLC diagnostics and enumerates three categories: trace recording, file operations, and static code analysis. It is specific enough to understand the tool's primary function, though it does not explicitly differentiate from sibling tools.

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

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

The description gives a general purpose but offers no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or exclusions for using the tool.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It does mention reading/writing live values and automatic type coercion, but it does not disclose side effects of writes, permission requirements, or error behavior. It is not contradictory, but it is not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, well-structured, and front-loaded with the primary purpose. It avoids unnecessary detail while still covering key operational constraints and parameter semantics.

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

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

The description gives enough context for typical usage: it specifies the operating context (running PLC), the channel naming format, the read/write distinction, and type handling. Since there is no output schema, the absence of return format details is acceptable, though more error handling context would improve completeness.

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

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

Schema coverage is 100% and descriptions add helpful context beyond the schema, such as 'read only', 'write only', the format for channel paths, and behavior when lcp_path or connection are omitted. The type coercion note clarifies how string values are interpreted.

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

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

The description clearly states the tool's purpose with a specific verb pair ('Read or write') and resource ('live channel values on a running PLC'). It also defines the channel naming format, distinguishing it from broader or more general PLC tools.

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

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

The description implies usage through the read/write action and 'running PLC' context, but it does not explicitly name alternative tools or state when this tool should be chosen over siblings like plc_diagnostics or control_plc. Guidance is present but not fully explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the primary side effect: setting the active project and affecting all other tools. It does not mention persistence, validation errors, or reversibility, but for a simple setter the description is transparent about its impact on global state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. The core purpose is front-loaded, and the usage instruction is appended concisely. Every word earns its place.

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

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

For a simple one-parameter setter with no output schema, the description is nearly complete. It explains what it does, when to call it, and the schema covers the parameter requirements. It could optionally mention what happens on invalid input, but that is minor given the low complexity.

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

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

The single parameter 'path' is fully documented in the schema (100% coverage), including the requirement that the folder must contain a .lsm file. The description adds no additional parameter semantics, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Set') and resource ('active LASAL project') with a clear scope ('by directory path'). It explicitly distinguishes itself from siblings by saying 'Call first — all other tools default to this project', so an agent can tell it apart from the other project-related tools.

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

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

The description explicitly says 'Call first — all other tools default to this project', providing clear when-to-use guidance. It implies that this tool should be invoked before any other tool that depends on project context, leaving no ambiguity about ordering.

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

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

The description states that apply_changes 'loads the project, runs operations, saves, and closes' and that download 'pushes the project to an HMI without saving content changes', which are useful behavioral details. However, with no annotations provided, it doesn't cover side effects like whether operations are atomic, whether text list revisions auto-increment, or whether a failed operation leaves the project partially modified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact paragraph that front-loads the core purpose and gives the key scoping constraint (apply_changes vs download) before the alternative instruction. It is dense but not bloated given the tool's complexity, and the second sentence adds critical guidance without excess.

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

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

For a highly complex tool with a large operations enum and 6 parameters, the description gives the essential action-level guidance and the main alternative path (direct file editing). It lacks details on output/return behavior and error cases, and the schema's nested operation objects carry most of the per-operation semantics, so the description alone is not fully self-sufficient but is reasonable given the schema coverage.

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

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

The schema covers 100% of parameters with descriptions, but the top-level description adds value by clarifying the key action parameter ('apply_changes' vs 'download'), the lvp_path auto-detection behavior, and the connection string format with the 'TCPIP:' prefix. It also explains that flags are download-only, which is a semantic distinction not fully obvious from the schema alone.

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

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

The description names a specific tool (VISUDesigner engine) and a clear verb ('Run VISUDesigner engine operations'), then enumerates the operation categories. It distinguishes itself from direct dashboard JSON editing via the last sentence, though it doesn't name a specific sibling tool.

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

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

The description explicitly contrasts with 'direct dashboard JSON editing' by saying 'for direct dashboard JSON editing, edit the files in the project directly.' This provides a clear when-to-use/when-not-to-use boundary, though it doesn't list alternative sibling tools by name.

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