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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return format (e.g., 'installed', 'running') but omits the optional vm_password parameter and any required VM state, leaving some behavioral gaps.

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 short and front-loaded with the purpose. However, the 'Args' block repeats schema information and could be removed, making it slightly less efficient than ideal.

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 low-complexity tool, the description covers the core purpose and return value. It lacks mention of the optional vm_password, any prerequest VM state, and differentiation from sibling tools, making it adequate but not thorough.

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 provides 100% coverage for both parameters, so the description adds no extra meaning. It redundantly lists vmx_path but omits vm_password entirely, which is slightly below the baseline given the schema is complete.

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 checks VMware Tools status in a VM's guest OS, using a specific verb and resource. However, it does not distinguish this from sibling tools like fusion_get_vm_info, so it stops short of full differentiation.

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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites (e.g., VM must be running) or exclusions. The usage is only implied by the verb 'check', with no context.

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 only adds that it returns a confirmation message on success, which is minimal. It does not disclose behavior for encrypted VMs (the optional vm_password parameter), name conflicts, or whether the VM needs to be powered on. Annotations already indicate it is not read-only, but the description provides little extra 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.

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

The description is brief and front-loaded with the purpose. However, the Args section duplicates schema information and is somewhat redundant, but it remains compact and 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?

The tool has no output schema, so the description should clarify expected behavior. It mentions a confirmation message but lacks details about error handling, prerequisites (e.g., VM existence), or relationship to sibling snapshot operations. The optional vm_password parameter is not addressed in the description, making it incomplete for encrypted VMs.

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 describes all three parameters with 100% coverage. The description's Args section merely repeats the schema entries and omits the vm_password parameter entirely, providing no additional semantic meaning beyond 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 clearly states 'Create a new snapshot of a VMware Fusion virtual machine', identifying the specific verb and resource. This distinguishes it from sibling tools like revert, delete, and list snapshots.

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 for creating snapshots by its very purpose, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. It is a self-explanatory create operation, so the usage is implied rather than explicitly guided.

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 goes beyond annotations by explicitly warning that the snapshot and its state are permanently removed and cannot be undone. It also states the return value (confirmation message). This adds critical behavioral context for a destructive action, aligning with the destructiveHint=true annotation.

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 and well-structured: purpose statement, warning, argument list, and return value. Every sentence contributes necessary information with no redundancy. The warning is appropriately prominent.

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?

Despite lacking an output schema, the description states the return type (confirmation message). It covers the destructive nature, irreversibility, and required parameters. For a simple delete tool with good annotations and schema coverage, the description is complete and self-sufficient.

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 all parameters with descriptions (100% coverage), so the baseline is 3. The description repeats the two main parameters (vmx_path, snapshot_name) but does not add significant new meaning beyond the schema. The optional vm_password parameter is not mentioned in the description, but the schema covers it adequately.

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 action ('Delete a snapshot') and the target resource ('from a VMware Fusion virtual machine'). It distinguishes itself from sibling tools like fusion_create_snapshot and fusion_revert_snapshot by specifying deletion.

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 (delete a snapshot) and a warning, but does not explicitly mention when to use this tool versus alternatives, nor any exclusions. It implies usage through its direct action statement, which is sufficient for a straightforward delete operation.

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 adds context beyond annotations by specifying the wait behavior and the dependency on VMware Tools. It does not contradict the readOnlyHint or idempotentHint. Minor omission: it does not mention the vm_password parameter.

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 and well-structured with Args and Returns sections. Every sentence contributes to clarity, with no redundant content beyond the schema.

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 simple nature and the presence of annotations, the description adequately covers prerequisites, wait behavior, and return value. However, the omission of vm_password from the Args list is a small completeness gap, even though the schema documents it.

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 all three parameters (100% coverage), so the baseline is 3. The description's Args section duplicates the schema information for vmx_path and wait, and omits vm_password entirely, adding no extra semantic value.

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 function: retrieving the IP address of a VMware Fusion guest. The verb 'Get' and resource 'IP address' are specific and differentiate it from sibling tools like fusion_get_vm_info or fusion_list_running.

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 provides explicit operational prerequisites: the VM must be running and VMware Tools installed. It does not explicitly discuss when not to use 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.

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

Annotations already mark this as read-only and idempotent. The description adds useful context beyond annotations by specifying that it reads the .vmx configuration file and checks running status, plus it lists the returned fields. This clarifies the underlying mechanism without contradicting any 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?

The description is well-structured and front-loaded with a clear purpose, followed by behavior, args, and returns. However, the Args section is incomplete since it omits vm_password, which slightly undermines the otherwise clean structure.

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 read-only tool, the description adequately covers what it does, what it reads, and what it returns. It lacks details about error behavior (e.g., missing file or encrypted VM without password), but the annotations and schema cover the overall safety and required parameters.

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%, so the schema fully describes both parameters. The description's Args section only mentions vmx_path and omits vm_password, but the schema covers the password requirement. No additional parameter semantics are provided beyond the structured 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 clearly states this tool gets detailed information about a specific VMware Fusion VM by reading the .vmx file and checking running status. It distinguishes from sibling list tools by focusing on a single VM's config and status, though it doesn't explicitly name alternatives.

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 read-only nature and 'detailed information' imply when to use it, and the sibling list shows alternatives are listing/starting/snapshot tools. However, there is no explicit guidance on when not to use it or how it compares to related tools like fusion_get_ip or fusion_check_tools.

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?

Annotations already mark this as read-only, idempotent, and non-destructive, so the description only needs to add behavioral context. It does so by specifying the scanned directories, the optional extra_dir parameter, and the return structure. This adds meaningful detail beyond annotations without contradicting them.

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 well-structured with clear Args and Returns sections, and it avoids unnecessary detail. The first two sentences are slightly redundant ('Discover all' vs 'Scans'), but overall the text is concise and front-loaded.

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 read-only discovery tool with one optional parameter, the description adequately covers the default search locations, the return format, and the optional directory. It does not specify behavior for inaccessible paths or non-standard installations, but given the annotations and simple schema, this is sufficient.

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 the single optional parameter extra_dir with a description, and the description's Args section repeats that same meaning. No additional parameter semantics, such as default behavior or edge cases, are provided, so it meets the baseline for high schema coverage.

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 discovers all VMware Fusion VMs by scanning for .vmx files. It distinguishes from siblings like fusion_list_running through the 'all' scope, but does not explicitly name the alternative or contrast with it.

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 explains what the tool does but offers no guidance on when to choose it over alternatives such as fusion_list_running. There is no mention of exclusions, prerequisites, or situational use cases.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the behavioral detail that VMs started by other users (e.g., root) are not shown unless run with sudo, which is important for users to interpret results. This goes beyond the structured 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?

The description is concise: it states the purpose, enumerates the return fields, and adds a caveat in a bulleted list. The structure is front-loaded with the main action and easy to scan.

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 simplicity (0 parameters, no output schema), the description fully covers what is returned and the important usage caveat. It is complete enough for an agent to select and invoke it correctly.

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 accepts zero parameters per the input schema, and the description appropriately does not need to add parameter semantics. The baseline score of 4 applies because schema coverage is 100% and no parameters exist.

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 the specific verb 'List' with the resource 'currently running VMware Fusion virtual machines,' clearly distinguishing this from sibling tools like fusion_list_all. It also states the return values (count, paths, display names), 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.

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

The description clarifies that only VMs started by the current user are shown, which is a useful context for when to invoke this tool. However, it does not explicitly mention alternatives like fusion_list_all for listing stopped or all VMs, so there is no direct comparison or exclusion.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return format (total and snapshots array), which is useful behavioral context. It does not add further details like whether the VM must be powered off, or how encrypted VMs are handled, but annotations lower the burden.

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 and well-structured with 'Args' and 'Returns' sections. It states exactly what is needed and what is returned. However, it omits the vm_password parameter from the 'Args' section, which is a minor completeness issue, but the structure is otherwise efficient.

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, read-only list operation, the description provides the essential return structure (total and snapshots). The schema fills in parameter details. It lacks explicit notes on encrypted VMs or error behavior, but these are less critical for a non-destructive list tool. Overall, it is sufficiently complete for the tool's 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 input schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description mentions vmx_path but omits vm_password, which appears in the schema. No additional parameter semantics beyond the schema are provided, so the description does not elevate 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 function: 'List all snapshots of a VMware Fusion virtual machine.' This is a specific verb+resource combination that distinguishes it from sibling tools like create_snapshot, revert_snapshot, and delete_snapshot. The word 'all' also clarifies the scope.

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?

Usage is implied by the tool's name and description—one would list snapshots before performing snapshot management operations like revert or delete. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites, so it stops at implied usage.

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?

Annotations already declare destructiveHint=true, confirming the destructive nature. The description adds value by distinguishing 'soft' (graceful) and 'hard' (forced) modes and noting returns a confirmation message. However, it does not explicitly warn about potential data loss on hard reset or mention handling of encrypted VMs (vm_password). With annotations covering the safety profile, this is 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.

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

The description is concise and well-structured: purpose, args, returns. No filler words. It is front-loaded with the main action. However, it is incomplete (missing vm_password), which slightly detracts from the efficiency of the structure, earning a 4 instead of 5.

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 destructive tool with no output schema, the description should explain more context: prerequisites, risks, and all inputs. It does explain return values and mode differences but omits the password parameter and provides no guidance on when to use this tool versus siblings. The missing usage guidance and parameter make it incomplete for a moderately complex operational task.

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%, so baseline is 3. However, the description lists only vmx_path and mode, omitting vm_password entirely. This is misleading because it suggests only two parameters exist, especially since encrypted VMs may require the password. It adds a bit of semantic detail for mode (soft/hard) but fails to acknowledge the third parameter, which is a significant gap.

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 'Reset (reboot) a VMware Fusion virtual machine' with a specific verb and resource. It distinguishes itself from sibling tools like fusion_start_vm, fusion_stop_vm, and fusion_suspend_vm by the reset action. The scope is unambiguous.

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?

There is no guidance on when to use reset versus stop/start/suspend or other alternatives. No prerequisites are mentioned (e.g., the VM must be running or Fusion must be open). The description focuses on mechanics but not on decision-making, leaving the agent without clear usage criteria.

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 warns that the operation discards any changes since the snapshot, adding behavioral context beyond the destructiveHint=true annotation. It also states the return value is a confirmation message.

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 compact, with a clear purpose sentence, a warning, and a structured argument list. The Args and Returns sections are slightly redundant with the schema but remain useful.

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?

With a destructive operation, the description adequately warns and covers the two required parameters. It does not mention the optional vm_password, but schema provides that, and the return behavior is disclosed.

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 all parameters with descriptions (100% coverage). The description repeats the two required parameters but adds no new meaning and omits the optional vm_password.

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 the specific verb 'revert' with 'a VMware Fusion virtual machine to a previous snapshot', clearly distinguishing it from sibling tools like create/delete/list snapshots.

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 when to use it (to roll back a VM to a snapshot) but provides no explicit guidance on alternatives or exclusions, such as when to use fusion_reset_vm instead.

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 key behavioral traits: the dependency on VMware Tools, the no_wait option's effect on return timing, and that it returns program output or confirmation. Annotations provide no safety hints (all false), so the description carries the transparency burden and handles it well, though it could mention side effects like process execution in the guest.

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 well-structured with a clear purpose statement, a requirements note, a bullet-like Args list, and a Returns section. It is succinct, front-loaded, and every sentence contributes useful information without redundancy.

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 7-parameter tool with no output schema, the description covers the essential context: purpose, prerequisite (VMware Tools), parameter meanings, and return behavior. It does not explain error scenarios or whether the VM must be running, but these are reasonable gaps given the tool's specificity and the sibling context.

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%, with all parameters documented. The description repeats most parameter meanings but adds contextual detail like 'Full path' and 'Arguments to pass'. However, it omits the vm_password parameter from its Args list, though the schema covers it. This provides marginal added value beyond 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 clearly states 'Run a program inside a VMware Fusion guest OS' with a specific verb and resource. It is distinct from sibling tools like fusion_start_vm or fusion_list_snapshots, which cover different operations.

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 clear context by noting 'Requires VMware Tools to be installed and running in the guest' and listing the function's purpose. It does not explicitly mention alternatives, but the sibling tools are semantically distinct, so usage is unambiguous.

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?

Annotations already provide safety traits (idempotent, non-destructive, non-read-only). The description adds useful behavioral context beyond annotations: the nogui flag for headless start, the return confirmation message, and the fact that vmx_path must be absolute. No contradictions detected.

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 compact and well-organized: a one-sentence purpose, an Args list, and a Returns note. Every sentence carries essential information, with no filler or redundancy.

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 start-VM tool, the description covers purpose, arguments, and return value. The absence of an output schema is mitigated by the explicit 'Confirmation message on success'. It could mention failure scenarios or prerequisites, but given the low complexity and strong schema/annotations, it is sufficiently complete.

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 all three parameters, so the baseline is 3. The description repeats key parameter semantics (absolute path, headless behavior) but adds no new meaning beyond what the schema already provides. vm_password is only in the schema, not the description, which is fine given complete schema coverage.

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?

Description uses specific verb 'Start (power on)' and resource 'VMware Fusion virtual machine'. It clearly distinguishes from sibling operations like stop, suspend, reset, and snapshot management, leaving no ambiguity about the tool's function.

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 clearly implies use when a VM needs to be powered on, and the sibling list provides obvious alternatives (stop, suspend, reset). However, it doesn't explicitly state when not to use it or mention prerequisites (e.g., VMware Fusion running), so it stops short of a full 5.

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?

Annotations already mark the operation as destructive and non-read-only. The description adds valuable behavioral detail by explaining the graceful soft shutdown versus forced hard power-off, and states that a confirmation message is returned. It does not mention vm_password or idempotency, but those are partially covered by annotations and schema.

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 compact and well-structured, with a clear purpose line followed by Args and Returns sections in just six short lines. Every sentence earns its place without redundancy.

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 stop operation with full schema coverage and strong annotations, the description covers purpose, mode behavior, and return value. It lacks alternative guidance and does not mention the vm_password field in Args, but the schema compensates for that. Overall, it is sufficient for an agent to use the tool correctly.

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%, so the baseline is 3. The description's Args section repeats the vmx_path and mode descriptions from the schema but omits vm_password entirely. Since the schema already fully describes all parameters, the description adds no new semantic value beyond what's structured.

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 opening line 'Stop (power off) a VMware Fusion virtual machine' uses a specific verb and resource, clearly identifying the action. It distinguishes itself from sibling tools like fusion_start_vm, fusion_suspend_vm, and fusion_reset_vm by naming the exact operation.

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 does not provide explicit guidance on when to use this tool versus alternatives like suspend or reset. The only usage context is the mode parameter ('soft' vs 'hard'), which is parameter-level detail rather than tool-selection guidance. No exclusions or alternative tool references are given.

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?

Annotations already declare idempotentHint and destructiveHint, so the bar is lower. The description adds that the VM must be running and that state is saved to disk, which is useful. However, it does not mention error conditions, effects on unsaved guest data, or behavior if the VM is already suspended. No contradiction with 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?

The description is brief and well-organized: a one-sentence purpose, a short Args list, and a Returns note. Every word earns its place. No verbosity or redundant 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?

Given the simple operation, good schema coverage, and annotations, the description is mostly sufficient. It states the purpose, necessary inputs, and return value. It lacks explicit distinction from fusion_stop_vm and does not mention resuming later, but these are minor gaps for a tool of this simplicity.

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%, and both parameters have clear descriptions. The description repeats vmx_path but adds no extra semantic value beyond what the schema provides. vm_password is not mentioned in the description, but the schema handles it adequately.

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 ('Suspend') and resource ('VMware Fusion virtual machine'), and adds a key distinguishing behavior: 'Saves the VM's state to disk.' This clearly separates it from sibling tools like stop or reset, which do not preserve state.

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?

Usage is implied by 'Suspend a running VM' and the state-saving behavior, but there is no explicit guidance on when to use suspend over alternatives like stop or reset, nor any exclusion such as 'do not use if the VM is not running.' The description relies on the agent to infer context.

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