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

No annotations are provided, so the description carries the full behavioral disclosure burden. It states the basic copy action but does not reveal whether the host destination is overwritten, whether directories are supported, or whether VMware Tools must be running.

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?

One sentence, front-loaded with the core action, and every word contributes. There is no filler, redundancy, or 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 minimally adequate for a simple copy operation: it identifies the source, destination, and direction, and the schema covers the parameters. However, with no annotations and no output schema, useful context such as overwrite behavior and VMware Tools prerequisites is missing.

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%, so the input schema already documents all three parameters. The description adds no parameter-specific detail beyond the schema, matching the baseline of 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?

The description uses a specific verb ('Copy') with a clear source and destination: from the guest VM to the host machine. It unambiguously distinguishes this tool from file_copy_to_guest, which performs the reverse transfer.

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 the tool: when a file needs to be transferred from the guest to the host. However, it does not explicitly discuss alternatives or exclusions, such as using guest_read_file for reading content instead of copying a file.

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 present, so the description carries the full behavioral burden. It only states the basic copy action and does not disclose whether existing files are overwritten, whether the VM must be running or have guest tools installed, or what happens on failure.

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, efficient sentence with no filler. It front-loads the action and direction, and every word contributes to understanding the tool's purpose.

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 three-parameter operation, the description and schema provide enough to attempt a call, but important contextual details are missing: overwrite behavior, guest-side prerequisites, and whether the operation returns any result. The absence of annotations makes these gaps more significant.

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%, so the input schema already documents all three parameters clearly. The description reinforces the host-to-guest direction but adds no parameter-level meaning beyond what the schema properties already provide.

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 ('Copy'), a specific resource ('a file'), and an unambiguous direction ('from the host machine to the guest VM'). This clearly distinguishes it from the sibling tool file_copy_from_guest, which moves in the opposite direction.

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 makes the core usage context clear: this is the tool to use when transferring a file from host to guest. It does not explicitly name alternatives or state when not to use it, but the directionality itself is strong contextual guidance.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It states that a temporary file is created and its path returned, but it does not explain lifecycle, whether the file persists after VM operations, whether guest tools are required, or what failure modes exist. For a mutating operation this is a notable gap.

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 sentence with no filler and front-loads the core action. It communicates purpose and result efficiently, though it omits some useful behavioral 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?

For a one-parameter tool this is minimal but functional: it tells what happens and what is returned. However, with no annotations, no output schema, and no usage guidance, the description leaves uncertainty about temporary-file lifecycle and operational prerequisites, so it is only marginally 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?

The input schema has 100% description coverage for its single parameter ('VM name or .vmx path'). The description adds no additional parameter semantics, so the baseline of 3 is appropriate because the schema already documents the parameter 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 states a clear verb ('Create'), a specific resource ('a temporary file inside the guest VM'), and the result ('return its path'). It is not a tautology and is distinguishable from sibling file tools by emphasizing temporary file creation, though it does not explicitly name or contrast with 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?

No guidance is provided about when to use this tool versus alternatives like file_copy_to_guest, guest_read_file, or guest_directory_create. The agent is left to infer the appropriate context from the name and description alone.

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 disclose behavioral traits itself. It only states that a file is deleted, without noting that deletion is permanent, that it may fail if the path is a directory, or that it requires guest cooperation. This is a meaningful gap for a destructive operation.

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 clear sentence with no filler. It is front-loaded with the action and resource, making it easy to scan and process.

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 the tool is simple, the description omits important context for correct invocation and expectation-setting: no mention of reversibility, failure conditions, or runtime requirements. For a destructive guest operation with no annotations, this is insufficiently 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%, so the parameters are already fully documented in the schema. The tool description adds no extra parameter meaning, but the baseline of 3 applies because the schema carries the informational burden.

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 ('Delete') and resource ('a file inside the guest VM'), which clearly distinguishes it from sibling tools like guest_read_file, guest_rename_file, or file_copy_to_guest. The scope is explicit and 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 gives no guidance on when to use this tool versus alternatives such as guest_run_command with rm, or how to handle cases like deleting directories vs files. There is no mention of prerequisites like the VM being powered on or VMware Tools being installed.

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 are absent, so the description must carry the behavioral burden. It only states that a directory is created; it does not disclose behavior when the directory already exists, whether parent directories are created, or other 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.

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

Single sentence with no filler; it front-loads the action and object. The description is appropriately sized for a simple tool definition, even though other dimensions lack depth.

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 two-parameter creation tool, the schema plus description provide a usable baseline for invocation. However, missing behavior around existing paths and the optional vm default leaves non-trivial gaps for an agent deciding how to call 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?

Schema description coverage is 100%, so the parameters are already well documented. The description adds little beyond the schema; 'inside the guest VM' essentially restates the guest_path schema description.

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 ('Create') and resource ('directory') with a clear location ('inside the guest VM'). This distinguishes it from file copy/delete/rename operations, though it does not explicitly name sibling 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?

No guidance on when to use this tool versus alternatives such as guest_directory_exists or guest_list_directory. There is no mention of prerequisites, whether the VM must be running, or when this should be preferred over file operations.

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 present, so the description carries the transparency burden. 'Check if...exists' conveys a read-only predicate, but it does not state whether the result is a boolean, how missing or inaccessible paths are handled, or explicitly that no changes are made to the guest. This is adequate but minimal.

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

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

A single clear sentence with no filler. The key scope, directory, and guest location are all front-loaded, and the description is appropriately sized for a simple predicate tool.

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 existence check the description is mostly sufficient, and the schema fully documents parameters. However, there is no output schema and no explicit statement of the return format or error behavior, leaving a small but real gap for an agent deciding whether the tool's result is reliable.

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 both parameters with descriptions, so the description does not need to repeat them. It adds no extra meaning beyond identifying guest_path as a directory to check.

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 and resource: 'Check if a directory exists inside the guest VM.' It is unambiguous and differentiates itself from sibling file tools like guest_file_exists by explicitly saying 'directory' instead of 'file'.

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 action implies use when verifying a guest directory's existence before a dependent step, but the description gives no explicit when-to-use, when-not-to-use, or alternative guidance. It is easy to infer but not stated.

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 the full disclosure burden, but it only restates the existence check. It does not state whether the tool returns a boolean, raises an error for missing files, how directories are treated, or whether VMware Tools is required.

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?

One sentence, front-loaded with the verb and resource, with zero filler. It is as concise as a tool definition should be.

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 check tool, the core purpose is conveyed, but there is no output schema and no stated return/error convention. The optional vm parameter's default behavior is also not explained, leaving minor gaps for correct invocation.

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%: vm and guest_path are both described meaningfully in the schema. The tool description adds no extra parameter detail, which is acceptable at the 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?

Description uses a specific verb ('check if exists') and resource ('file inside guest VM'), making it clearly distinguishable from sibling guest_directory_exists and read/delete/rename variants. No ambiguity about what the tool does.

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 wording implies it should be used as a prerequisite check before reading, deleting, or copying guest files, but no explicit when-to-use or when-not-to-use guidance is given. Sibling tools are not referenced, so an agent must infer selection.

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 does clearly state the destructive action: killing a process inside the guest VM. However, it omits other useful behavioral context such as irreversibility, whether VMware Tools are required, or what happens when the PID is invalid.

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, focused sentence with no filler. The key action, target, and required identifier are all front-loaded and immediately usable.

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 two-parameter tool with no output schema or nested objects, the description plus the input schema cover the core call correctly. It is slightly incomplete in that it does not mention the guest-side requirements or the effect of a failed kill, but the essential context for invoking the tool is present.

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 documents both parameters with full coverage, including the pid description referencing guest_process_list. The tool description adds little beyond restating that the operation uses a PID, so it does not meaningfully enhance what the schema already provides.

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 'Kill' and identifies the exact resource: a process inside the guest VM, selected by PID. It is not a tautology of the title and clearly distinguishes this from sibling tools like guest_process_list or guest_run_command.

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 phrase 'by its PID' implies the caller must already know which process to target, and the schema's pid description even points to guest_process_list. However, the description does not explicitly state when to use this tool instead of alternatives, nor does it mention prerequisites like guest tools or listing the process first.

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?

There are no annotations, so the description carries the full burden. It discloses that the operation is a listing, but does not mention whether it is recursive, whether hidden files are included, whether the VM must be running, or whether VMware Tools are required. These are meaningful gaps for a guest VM operation.

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 states the operation and target in an efficient way. There is no redundancy or filler.

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 two-parameter list operation, the description is minimally viable, but it lacks any note about output behavior, prerequisites, or edge cases. With no output schema or annotations, a bit more context would help the agent know what 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?

Schema description coverage is 100%, so both 'vm' and 'guest_path' are already documented in the schema. The description adds no additional parameter semantics, which is acceptable given full schema coverage, but it does nothing to enrich the parameter meaning.

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 ('List') and a specific resource ('contents of a directory inside the guest VM'), clearly distinguishing it from file reading, existence checks, and directory creation. It is immediately 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?

No guidance is given about when to use this tool versus alternatives like guest_directory_exists, guest_read_file, or guest_directory_create. The context is clear for a simple listing operation, but no exclusions or alternative routing are provided.

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 the full burden. It clearly conveys a read-only listing action and an authentication requirement, but it does not explicitly state that no guest state is modified, nor does it disclose failure conditions such as needing VMware Tools to be running.

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 consists of two short sentences, with the core action front-loaded and the prerequisite in a clear second sentence. There is no redundancy or filler; every word contributes.

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 tool, the core purpose is stated, but because there is no output schema the description does not specify what the process list looks like (e.g., names, PIDs, details). It also omits mention of the need for VMware Tools inside the guest, which is a relevant prerequisite given the sibling tool vm_check_tools.

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 only parameter vm is fully described in the input schema as 'VM name or .vmx path' (100% coverage), so the schema already provides the necessary meaning. The description adds no further parameter details, so the baseline score of 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 (list) and resource (running processes inside the guest VM), making the tool's function immediately clear. This distinguishes it from sibling tools like guest_run_command or guest_kill_process, which perform different actions on guest processes.

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 includes a necessary prerequisite ('Requires guest credentials'), which gives some usage context. However, it does not say when to choose this tool over alternatives such as guest_run_command or guest_kill_process, and no exclusions are provided.

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 the burden of revealing behavior. It explicitly discloses the temporary-copy workflow and cleanup ('Copies to host, reads, then cleans up'), which is valuable non-obvious context beyond just 'read file.' It does not mention failure cleanup or return behavior, but the core mutation/side-effect profile is clear.

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 one focused sentence that front-loads the operation and then concisely explains the temporary copy lifecycle. Every phrase 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 two-parameter read operation, the description covers purpose and mechanism. However, without an output schema it does not explicitly state the return value (file contents) or error/edge-case behavior, so an agent must infer the output from the tool name and verb.

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 the parameter descriptions already define 'vm' and 'guest_path' adequately. The description adds no parameter-specific detail, so the baseline score applies.

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 ('Read') and resource ('a file inside the guest VM'), and its mechanism — 'Copies to host, reads, then cleans up' — sets it apart from sibling operations like file_copy_from_guest or guest_file_exists. The intent is unambiguous even without opening the schema.

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 about when to choose this over alternatives, such as file_copy_from_guest for a persistent copy or guest_file_exists for existence checks. The description states what the tool does but provides no selection 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?

No annotations are provided, so the description carries the behavioral burden. It clearly communicates the core mutation, but does not disclose overwrite behavior, failure conditions, or prerequisites. The old-path-replaced-by-new-path semantics are reasonably inferable, but side effects are not fully specified.

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 with an active verb and clear object. It avoids repeating schema property names or adding filler, so 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 low-complexity tool with complete parameter schemas, the definition is minimally usable. However, with no annotations and no output schema, it leaves out behavioral details and alternative-selection guidance, so it is adequate rather than fully 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?

Schema description coverage is 100%, so the parameters are already well documented by the schema. The description does not add extra semantic detail beyond the rename/move action, which is acceptable given the schema's completeness.

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 concrete operation—'Rename or move a file inside the guest VM'—and clearly identifies both the resource and scope. This distinguishes it from sibling file operations like copy, read, delete, and listing 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?

No guidance is given about when to use this tool versus alternatives such as file_copy_to_guest, file_copy_from_guest, or guest_delete_file. Prerequisites like guest tools or path validity are also not 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?

No annotations are provided, so the description carries the disclosure burden. It does disclose the stdout return, automatic shell selection, and VMware Tools requirement, but it leaves unstated how failures are reported, whether stderr/exit codes are included, and the fact that arbitrary shell commands can modify guest 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 concise sentences with no filler. The main behavior is front-loaded, and the second sentence adds only necessary environmental and shell-selection details.

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 schema fully documents all parameters and the description covers prerequisites, output (stdout), and shell behavior, the tool is mostly complete to invoke correctly. The main missing context is failure/exit-code semantics and explicit differentiation from guest_run_program, but these are not critical for basic invocation.

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 covers all parameters at 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that 'command' is a shell command rather than a program path and that the shell auto-selects based on guest OS type, which reinforces the 'shell' parameter behavior.

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: 'Execute a shell command inside the guest VM and return stdout.' It names a specific verb, resource, and expected output. The 'shell command' phrasing also helps distinguish it from the sibling guest_run_program.

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 useful prerequisites and context: guest credentials must be configured and VMware Tools must be running, and shell selection depends on guest OS. However, it does not explicitly explain when to use this tool over guest_run_program or provide exclusions or alternative routing.

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 full burden of behavioral disclosure. It adds only that the launch can be asynchronous and that a full path is required, both of which are already present in the schema. It does not describe return behavior, stdout/stderr, default waiting behavior, or failure semantics.

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 the primary action front-loaded and no filler. It is efficient, though its brevity leaves important behavioral and selection details uncovered.

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 tool with five parameters, no output schema, and no annotations, this description is too thin. It leaves timeout_seconds undocumented, does not describe expected return behavior, and does not explain when to prefer this over guest_run_command.

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 80%, so the baseline is 3. The description repeats the full-path requirement for program but does not add meaning for timeout_seconds, argument passing, or how no_wait interacts with the overall execution.

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 and object: 'Launch a program inside the guest VM' and adds the requirement of a full path. It is clear about the resource, but does not explicitly differentiate from the sibling guest_run_command, so it stops short of 5.

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 no when-to-use guidance, exclusions, or alternatives. The mention of no_wait and full path is a capability note, not selection guidance, and the close sibling guest_run_command could easily be chosen 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds a meaningful prerequisite (macOS Accessibility permission for VMware Fusion) and hints at its GUI-interaction nature. However, it does not disclose whether keystrokes are delivered to the foreground guest application, whether VMware Tools are required, or what happens if the guest is busy or not ready.

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 no filler: the first states the action, the second gives a usage scenario and a prerequisite. Information is front-loaded and every sentence 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 two-parameter tool with no output schema, the description covers the main essentials: what it does, when to use it, and a key permission requirement. It could be slightly more complete by noting that keystrokes go to the guest's current UI focus, but the given context is largely sufficient for correct invocation.

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 both parameters (vm and keystrokes), so schema coverage is 100%. The description adds little beyond restating that keystrokes are sent to the guest; it does not clarify formatting, special keys, or timing. A baseline of 3 is appropriate because the schema handles parameter documentation 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 states a specific action ('Send keystrokes') and target ('guest VM'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools by explicitly tying it to 'GUI automation' rather than command/program execution tools like guest_run_command.

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 context: 'Useful for GUI automation when combined with vm_capture_screen.' This tells the agent when the tool is appropriate. However, it does not explicitly explain when to prefer guest_run_command or guest_run_program instead, though the GUI-automation framing partially implies this distinction.

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 burden of behavioral disclosure. It discloses the return/save behavior and the credential requirement, which go beyond the tool name and input schema. It stops short of detailing side effects of saving to host_path or setup implications of guest credentials, but the core behavior is 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?

Two concise sentences: the first states the action and output format, the second states the alternative save behavior and key prerequisite. All information is front-loaded and there is no filler.

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 core invocation aspects: target VM, optional host path, output handling, and credential prerequisite. However, it does not clarify the apparent optionality of vm given the schema reports no required parameters, nor does it explain how guest credentials are configured. This leaves some correctness ambiguity for an autonomous agent.

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 documents both parameters fully, including the host_path fallback behavior. The description reinforces the output format (base64 PNG) but adds no meaningful new semantics for the vm parameter, so the baseline score of 3 applies.

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 action and resource: 'Capture a screenshot of the VM screen.' It further distinguishes the tool by explaining output behavior (base64-encoded PNG vs. saving to a host path), so there is no ambiguity about what it does.

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 prerequisite ('Requires guest credentials in config') and indicates when saving vs. returning output is used, but it does not explicitly state when to prefer this tool over alternatives. There are no screenshot-related siblings, so usage context is mostly implicit.

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 discloses the possible return values, which is helpful, but does not explain the meaning of each state, error conditions, or whether the operation is read-only. Since the tool is a simple check, the impact is limited, but more context 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.

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

The description is a single, dense sentence that front-loads the action and immediately specifies the output values. Every word earns its place, with no unnecessary information.

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 state-check tool with one parameter and no output schema, the description is mostly complete. It lists the possible return values, which is essential since there is no output schema. However, it does not explain the conditions that lead to each state or mention error scenarios, which would help an agent handle unexpected situations.

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 only parameter, 'vm', is already fully described in the schema as 'VM name or .vmx path'. The tool description adds no additional meaning to the parameter, so the baseline of 3 applies due to 100% 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 action ('Check'), the resource ('VMware Tools state in the guest'), and the expected return values ('unknown', 'installed', or 'running'). This distinguishes it from sibling tools like vm_status (VM power state) and vm_get_ip (network address).

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 no explicit guidance on when to use this tool versus alternatives. The purpose makes it obvious it should be used to check guest tools status, likely before executing guest operations, but this is only implied and not stated.

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 main behavioral burden. It conveys a non-mutating read action and the 'running' precondition, but it does not disclose what happens when the guest has no VMware Tools, whether the IP may be unavailable initially, or how the optional waiting behavior interacts with that.

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 precise sentence with no filler, no repetition, and the key resource is front-loaded. 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?

Given the low complexity, 100% schema parameter coverage, and no output schema, the description plus schema is nearly complete. The agent knows what to retrieve, what the VM parameter means, and that wait can poll for the IP, though a bit more behavioral context would make it fully self-contained.

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%, so the baseline is 3 because the schema already documents the vm and wait parameters. The description itself adds no parameter-level meaning beyond saying the subject is a VM.

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 and resource: 'Get the IP address' of a virtual machine. This is clearly distinct from lifecycle and guest-command siblings, though it does not explicitly name or contrast any 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 phrase 'of a running virtual machine' implies a precondition and suggests this is a read-only network retrieval tool. However, it provides no explicit when-to-use or when-not-to-use guidance, no named alternatives, and no exclusions.

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 burden of behavioral disclosure. It clearly discloses the default filtering behavior and the effect of all=true, which is meaningful beyond the schema. It does not mention potential errors or permissions, but for a read-only listing operation the key 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.

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

The description is two short sentences with no filler. The primary action comes first, followed by the important default behavior and the parameter action. 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 tool with one optional boolean parameter and no output schema, the description covers what the agent needs to invoke it correctly: the default behavior and when to set all=true. It does not describe the return format in detail, but 'List virtual machines' makes the high-level output clear.

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 adds value by explaining the default outcome ('By default shows only running VMs') and by linking all=true to 'configured VMs from config', which clarifies the practical meaning of the parameter beyond its schema description.

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 opens with a specific verb and resource ('List virtual machines') and immediately distinguishes itself from the many sibling tools by scoping behavior: default is running VMs only, with an option for configured VMs. There is no ambiguity about what this tool does.

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 gives clear usage context: by default you get running VMs, and you should pass all=true if you want configured VMs from config. It does not explicitly name alternatives or when-not-to-use, but the guidance is sufficient for a simple listing tool with one optional boolean parameter.

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 the full burden of behavioral disclosure. It clarifis that the operation is not a shutdown, but it does not explain what pausing does (e.g., freezes execution, keeps memory state), whether it is reversible, or what errors or side effects may occur.

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 efficient sentence with no filler. It front-loads the action and adds one useful qualifier, making it well structured for a tool with only one optional parameter.

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 and the schema covers its lone parameter, so the description does not need much. However, without annotations or an output schema, it lacks guidance on how to resume a paused VM and what state the VM enters, leaving some ambiguity for an agent.

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%, so the baseline applies. The description itself adds no parameter details, but the schema already documents that vm accepts a name or .vmx path and defaults to default_vm.

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 clear verb and resource: pause a virtual machine. The phrase 'without shutting it down' distinguishes it from vm_stop, but it does not differentiate it from thge similarly named sibling vm_suspend, so it does not fully disambiguate among 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?

There is no explicit guidance about when to use vm_pause versus the closely related siblings vm_suspend, vm_stop, or vm_unpause. The only implication is that the VM must be running, but no althernative selection criteria are provided.

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's verb 'Read' conveys the key non-mutating behavior, which is important for safe tool selection. It does not describe error cases, prerequisites, or return behavior, but for a read primitive the core behavior is clear.

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?

A single, front-loaded sentence with no filler. It is appropriately sized for a simple read tool.

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 three-parameter read tool with fully documented schema fields, the description plus schema supplies what an agent needs to invoke it. It could be more complete by naming the write counterpart and return value, but those are low-risk omissions.

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%; each parameter, especially var_type, has a meaningful description. The tool description itself adds no parameter detail, so the baseline 3 applies.

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 clear action (read) on a clear resource (a variable from VM state), and the title reinforces it. It does not explicitly contrast with sibling vm_write_variable, so it stops short of full sibling 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 on when to choose this over alternatives; it does not mention vm_write_variable or other variable/guest-state tools. The only usage signal is implied by the verb 'read'.

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 the full burden. It does disclose one meaningful behavioral trait: 'soft' runs shutdown scripts first, implying 'hard' does not. However, it does not mention potential data loss, abruptness of hard reset, or any prerequisites like guest tools.

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 compact sentences with the core action front-loaded and the mode detail second. No filler or redundant phrasing.

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 2-optional-parameter tool with no annotations and no output schema, the description covers the essential action and one mode behavior. Gaps remain around hard-mode semantics and side effects, but the description is sufficient for basic invocation.

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 documents 'vm' well, but 'mode' only has an enum with no description. The description compensates partially by explaining what 'soft' does, though it leaves 'hard' undefined. Since schema description coverage is 50%, the additional mode context helps but is incomplete.

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 virtual machine,' which is a specific verb and resource. The parenthetical 'reboot' helps distinguish it from stop/start operations, though it does not explicitly name or 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 mention of 'soft' running shutdown scripts first implies a graceful vs. forced reset, giving some context for choosing a mode. However, there is no explicit guidance on when to use this tool versus alternatives like vm_stop or vm_start, nor any exclusions.

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 the behavioral burden, and it does disclose a real edge-case failure ('may fail on running encrypted VMs due to vmrun limitations') plus a mitigation. Minor omissions such as success response or side effects on existing snapshots keep it just below a 5.

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

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

Two focused sentences with no filler. The core action is front-loaded, and the two warnings are placed immediately after, each earning 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 two-parameter snapshot operation without an output schema, the description covers the main action, naming rules, and a failure mode. It does not explain why vm is optional or what happens if omitted, but this is a minor gap given the schema's clarity.

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 parameters are well documented structurally. The description adds extra semantics by constraining snapshot_name (no '/') and relating VM state to success, going beyond the bare 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 ('Create') and resource ('snapshot of a virtual machine'), making the action unambiguous. It also distinguishes itself from sibling snapshot operations (revert, list, delete) by the create verb.

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 gives concrete operational guidance: avoid '/' in snapshot names, and stop running encrypted VMs before snapshotting if needed. It doesn't explicitly discuss alternatives, but the create-vs-management distinction among siblings is self-evident.

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 that the action is destructive, which is implied by 'delete,' but with no annotations it carries full responsibility for behavioral context. It does not state irreversibility, what happens to child snapshots by default, or any side effects on the VM.

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?

A single clear sentence with no filler. It front-loads the core action and resource immediately.

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 schema covers all parameters with descriptions and defaults, and the purpose is clear. However, without annotations or an output schema, the description leaves behavioral and usage context thin for a destructive VM operation.

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%, so parameters like snapshot_name, vm, and delete_children are already documented. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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 an unambiguous verb and resource: delete a snapshot from a VM. It is clearly distinct from create/revert/list snapshot operations, though it does not explicitly name those 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?

No guidance is given about when to use this tool instead of vm_snapshot_create, vm_snapshot_revert, or vm_snapshot_list. The description does not mention prerequisites, when deleting children is appropriate, or when not to delete a snapshot.

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 present, so the description carries the behavioral burden. 'List' implies a read-only operation and 'tree format' indicates output structure, but the description does not address VM power state requirements, error conditions, or behavior when the vm parameter is omitted.

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 ten-word sentence with the action front-loaded and no filler. Every element—'all', 'virtual machine', 'tree format'—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?

The tool is simple, but the description says 'of a virtual machine' while the schema marks vm as optional, leaving the no-vm case unexplained. With no output schema, a bit more detail about what the tree contains would make the tool more self-contained.

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% because the only parameter, vm, is described as 'VM name or .vmx path'. The description adds no parameter-level details beyond what the schema already provides, so the baseline of 3 applies.

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 'List' and a clear resource 'snapshots of a virtual machine', plus the 'tree format' detail. It is easily distinguished from sibling operations like vm_snapshot_create, vm_snapshot_revert, and vm_snapshot_delete.

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 makes the primary use case clear: call this when you need to view the snapshots of a VM. It provides no explicit exclusions or alternative tool names, but no other sibling performs this exact function, so 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.

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the VM will be in a suspended state after revert and that auto_start can power it back on. However, it does not mention that the operation discards current state changes or any prerequisites (e.g., VM must be stopped). This is partial transparency.

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 no fluff. The purpose is front-loaded, the behavioral consequence is stated second, and the auto_start tip is integrated efficiently. Every word contributes to 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?

For a mutation tool with no annotations and no output schema, the description covers the core action, the resulting VM state, and the key parameter behavior. It could be improved by explicitly warning about data loss (discarding changes since the snapshot), but the essentials are present. Considering the schema fully documents parameters, it is fairly 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%, so the baseline is 3. The description adds minimal semantic value: it restates the purpose of auto_start ('power it back on') which is already in the schema. It does not elaborate on vm or snapshot_name beyond what the schema provides, so no significant extra meaning is added.

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 'Revert' targeting a VM to a snapshot, which clearly distinguishes this from sibling snapshot operations (create, list, delete) and general VM controls. It leaves no ambiguity about the action performed.

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: you use it to revert a VM to a snapshot. However, it does not explicitly contrast with alternative operations like vm_snapshot_create or vm_snapshot_delete, nor does it state when not to use it. The guidance is implicit rather than 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Start a VMware virtual machine,' with no mention of side effects, default GUI behavior, whether it waits for boot, or what happens on failure.

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, front-loaded sentence with no filler or repetition beyond the title. It is highly concise, even if it sacrifices informative content, which is penalized in other dimensions.

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 lifecycle-changing operation with no annotations and no output schema, this description is too thin. It does not explain the power-state transition, the headless/GUI option, the wait-for-IP behavior, or how this relates to guest operations and other VM lifecycle tools.

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 the schema already explains vm, gui, and wait_for_ip clearly. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema does the necessary work.

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 clear verb ('Start') and a specific resource ('a VMware virtual machine'), so the core action is unambiguous. It is distinguishable from sibling tools like vm_stop or vm_reset by the verb, though it does not explicitly contrast itself with them.

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 about when to use this tool versus alternatives like vm_suspend, vm_reset, or vm_unpause. The description does not mention prerequisites, state requirements, or typical scenarios, so the agent receives no routing help.

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 are absent, so the description must disclose behavioral traits itself. It implies a read-only retrieval but doesn't say whether a powered-off VM yields a status without an IP, whether the VM must exist, or whether any state change occurs.

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?

One sentence with no filler; the key outputs are stated up front. It earns its place and is 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 one-parameter read tool this is mostly adequate, but with no output schema it stops short of describing return format or edge cases (e.g., null IP, offline states). A short note about the distinction from vm_get_ip would make it 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?

The schema already documents the single parameter completely ('VM name from config, or full .vmx path. Uses default_vm if omitted'). The description adds no parameter semantics beyond the generic 'virtual machine' phrase, so baseline 3 applies.

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 ('Get') and identifies the resource and result ('running status and IP address of a virtual machine'). It clearly states the tool's purpose but doesn't distinguish it from the sibling vm_get_ip, which covers the IP part of the result.

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 given about when to call this tool versus vm_get_ip, vm_list, or vm_check_tools. The description only states what it does, leaving the agent to infer selection criteria. This is a clear gap given related siblings.

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 the behavioral burden. It does disclose the main behavioral distinction between a graceful shutdown attempt and a forced power-off. Still, it omits important side effects such as possible data loss in 'hard' mode, behavior if the VM is already stopped, or prerequisites like guest tools for 'soft' mode.

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 short sentences with no redundancy. The core purpose is front-loaded, and the mode details are stated efficiently without wasted words.

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?

This is a simple tool with two optional parameters and high schema coverage, and the description covers the core purpose and mode semantics. However, it does not mention failure behavior, preconditions, or post-conditions, and there is no annotation or output schema to fill that 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics by explaining that 'soft' attempts graceful shutdown and 'hard' forces power off, which the schema's generic 'Shutdown mode' description does not convey. It adds nothing for the vm parameter, but the schema already covers it well.

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 (stop) and resource (virtual machine), and it distinguishes the two shutdown modes. It does not explicitly differentiate vm_stop from siblings like vm_suspend or vm_pause, but the verb 'stop' makes 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 gives mode-selection guidance: 'soft' attempts graceful shutdown and 'hard' forces power off. However, it does not say when vm_stop is preferred over alternatives such as vm_suspend, vm_pause, or vm_reset, and it gives no exclusion 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?

There are no annotations, so the description carries the full behavioral disclosure burden. It does disclose a key trait (state is saved to disk) and a concrete risk (encrypted VMs may not resume via vmrun), but it omits mode semantics, reversibility, and what happens to the VM after suspension beyond the warning.

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 no filler; the action is stated first and the warning is a meaningful, necessary addition. Every sentence 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?

The core purpose and a critical caveat are present, and no parameters are required, so a default invocation is feasible. But mode semantics are unexplained and there is no guidance distinguishing suspend from vm_pause, leaving the definition only minimally 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 only 50%: the vm parameter is documented, but mode is just an enum without explanation. The description adds no meaning for soft vs hard modes, so the agent has to guess which mode to use or what the difference is.

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 operation and resource — suspending a virtual machine — and clarifies the defining behavior: preserving current state to disk. The warning also explicitly positions it against vm_stop, helping distinguish it from power-off and other VM-state-changing 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?

The warning gives an explicit when-not-to-use condition (encrypted VMs) and names vm_stop as the safer alternative, which is strong routing guidance. However, it does not contrast with vm_pause or describe when suspend should be preferred over pause or reset.

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 only states the primary action and does not mention whether the operation waits for completion, what permissions are needed, whether it is reversible, or what side effects occur if the VM is already running. For a state-changing operation, this is a significant gap.

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?

One sentence with zero filler words. It is appropriately sized for the tool's simplicity and states the core action immediately.

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 (one optional parameter, no output schema), and the description gives the essential action. However, because there are no annotations and no output schema, the description leaves out behavioral details like result handling and failure modes, so it is only minimally complete for a state-changing tool.

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 the single parameter 'vm' fully (100% coverage), including its type and meaning. The description adds no additional parameter-level information, so the baseline score of 3 applies.

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 ('Resume') and a clear resource ('a paused virtual machine'), so an agent can tell it is the inverse of vm_pause. It does not explicitly differentiate itself from related siblings such as vm_start or vm_suspend, but the state transition is clear enough.

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 phrase 'paused virtual machine' implicitly states the prerequisite state for use, which gives some context. However, it does not explicitly say when to use this tool over alternatives like vm_start or vm_suspend, nor does it describe what happens if the VM is not already paused.

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 full burden of behavioral disclosure. It only implies a mutating write operation and does not mention persistence semantics, side effects, required VM state, permissions, or failure behavior. The schema's var_type descriptions cover some details, but those are structured fields, not the tool description.

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 short sentence with no filler or redundant elaboration. It front-loads the verb and object, though it is so brief that it sacrifices useful 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?

For a mutating tool with no annotations, no output schema, and an important var_type enum, the description is incomplete. It omits when the operation applies, what the different variable categories imply for behavior, and what the caller should expect after invocation.

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%, so the input schema already documents all parameters and the var_type enum meanings. The description adds no parameter-level explanation beyond what the schema provides, which matches the baseline of 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?

The description states a clear verb and resource: 'Write a variable' to 'the VM state.' This is specific enough to identify the operation, though it does not name the var_type distinctions or explicitly differentiate it from sibling tools such as vm_read_variable.

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 about when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. The agent must infer usage entirely from the name and schema, since the description only says 'Write a variable to the VM state.'

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