windows98-mcp

by ido-pluto

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.6.2
Disambiguation4/5
Most tools have clearly distinct purposes (filesystem, shell, process, input, window, clipboard). Some closely related groups like shell_write/shell_terminate/shell_close and mouse_down/mouse_up/mouse_click could cause initial confusion, but descriptions resolve it.
Naming Consistency4/5
All names use lowercase with underscores and generally follow a noun_verb pattern (file_push, mouse_move, process_list). A few attribute-style names (vm_status, system_info, vm_capabilities) deviate from the verb-led convention, but the style is consistent overall.
Tool Count2/5
At 48 tools, the server is far beyond the typical well-scoped range. Many operations are hyper-granular (8 mouse tools, 5 keyboard tools, 5 shell tools) and could be consolidated, making the surface area heavy for an agent to navigate.
Completeness5/5
The tool surface thoroughly covers Windows 98 remote control: filesystem operations, shell execution/interactive sessions, process management, UI input (mouse and keyboard), screen/window capture, clipboard, window management, reboot/shutdown, and VM lease handling. No obvious gaps for the stated purpose.
Average 4.2/5 across 48 of 48 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant behavioral trait: the VM remains locked by this session and requires a subsequent vm_unlock call. This goes beyond the annotations, which only indicate read-only/idempotent/destructive hints. It adds real operational context that an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first gives the purpose, the second gives a critical behavioral instruction. It is tightly worded, front-loaded, and every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose and a key side-effect (locking) are covered, but the description omits details about parameter semantics, return values, and error behavior. Given the lack of an output schema, this leaves the agent with some uncertainty, though the operation is simple enough that a minimum-viable description is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to explain the parameters. It does not mention 'path' or 'recursive' beyond the tool name. The semantics of 'path' (guest filesystem path) and 'recursive' (whether to create parent directories) are left to the agent's inference from standard mkdir behavior, which is not explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create a guest directory,' a clear verb+resource statement that distinguishes this tool from filesystem siblings like fs_move, fs_delete, and fs_list. The action is unambiguous and the resource (a directory on the guest) is specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternative fs operations. There are no explicit exclusion conditions or alternative tool references. The only usage-related note is the sequencing requirement to call vm_unlock after finishing, which is helpful but does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant side effect not captured in annotations: the VM remains locked by this session and requires vm_unlock. It also clarifies the actions (press, hold, release) matching the schema enum, adding behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a front-loaded action and examples, plus a critical side-effect note. No wasted words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple input tool with no output schema, the description covers core functionality, key examples, action variants, and the locking side effect. It lacks error handling or return information, but these are less critical for a fire-and-forget key press tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description coverage (0%), but the description compensates by giving example key values (ENTER, CTRL, LEFT, F1) and naming the actions. It doesn't exhaustively explain the 'key' parameter format or case sensitivity, but provides useful semantics beyond the bare string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool presses, holds, or releases a named key with concrete examples (ENTER, CTRL, LEFT, F1). It differentiates from siblings by specifying 'named key' as opposed to keycodes or hotkeys, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over keyboard_type, keyboard_hotkey, or keyboard_keycode. It only mentions a follow-up action (vm_unlock) but no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the VM remains locked by this session and instructs calling vm_unlock when finished. This is a critical behavioral side-effect not captured in the structured metadata. It also implies the command works outside the guest agent's ready state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, both front-loaded with the core action and critical caveat. Every word earns its place, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and the essential locking behavior, but lacks parameter details and edge cases (e.g., key format, action semantics). Given the tool's simplicity and absence of an output schema, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters. There is no explanation of what constitutes a valid 'key' in QMP qcode format, the meaning of the 'action' enum values (down, up, press), or how vm_id is used. With 0% schema description coverage, the description fails to compensate completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a QMP qcode key event, with a specific timing context (before or after guest-agent startup). This distinguishes it from sibling keyboard tools that likely use the guest agent, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before or after guest-agent startup' indicates when this tool is appropriate, such as when the guest agent is not yet running. It doesn't provide explicit when-not guidance or mention alternative tools, but the timing context is a clear usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant behavioral trait beyond annotations: the VM remains locked by this session and must be unlocked. This is critical context. However, it doesn't discuss potential side effects of the arbitrary command, though annotations indicate non-destructive tool-level behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The first sentence defines the operation, the second provides essential locking instructions. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter descriptions, the description is incomplete for an arbitrary-command tool. It fails to mention the return format or that the command can have arbitrary effects. The lock note is valuable but not enough for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is zero schema description coverage, and the tool description adds no parameter-level detail. The names 'vm_id' and 'command' are self-explanatory, but no syntax, examples, or format guidance for the HMP command is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an HMP command via QMP's human-monitor-command, using a specific verb and resource. It distinguishes itself from sibling qemu_qmp_execute by specifying HMP rather than QMP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The lock note ('call vm_unlock when finished') gives a clear usage directive, but no explicit when-to-use vs alternatives or exclusions. The purpose implies HMP use, but it doesn't compare to qemu_qmp_execute or other VM tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide no guidance, so the description carries the transparency burden. It discloses a key side effect: the VM remains locked by this session and requires vm_unlock. This is valuable behavioral context beyond the structured fields, although it does not describe return format or potential command 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose, the second gives a critical usage condition. No wasted words, and the lock warning is front-loaded enough to catch attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic command execution tool with no output schema and low schema coverage, the description is incomplete. It lacks information about return values, error handling, how to format the command and arguments, and what 'advanced' means. The lock warning is useful but does not fill the main gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain vm_id, command, or arguments. It only says 'advanced QMP command' without elaborating on how to structure parameters. This leaves the agent without any semantic guidance beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Run), the resource (advanced QMP command), and the target (managed VM's local broker-owned QMP endpoint). It is distinct from siblings like qemu_hmp_command (which executes HMP commands) and qemu_vm_command_preview (which likely previews commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the VM remains locked by this session and instructs to call vm_unlock when finished, providing important context for use. However, it does not explicitly mention when to use this over alternatives or include exclusions like 'use qemu_hmp_command for simpler HMP commands.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds a non-obvious behavioral detail: 'VM remains locked by this session; call vm_unlock when finished.' This goes beyond annotations by informing the agent of a side effect (session lock) and a required follow-up action. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first is action-focused and front-loaded. The second provides an important behavioral caveat. Every word earns its place, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description is nearly complete. It states the operation, clarifies the parameter's meaning, and discloses the locking side effect. The only gap is not describing the return metadata (e.g., what fields are included), but this is somewhat inferable from the tool name 'stat'. The lock/unlock context adds critical operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'path' has 0% schema description coverage. The description clarifies that the path is a 'guest filesystem path', which adds meaning beyond the raw schema field. However, it does not elaborate on path format, absolute vs relative, or expected behavior for missing paths. This is minimal compensation for the coverage gap, but not rich enough to warrant a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Read metadata') on a specific resource ('guest filesystem path'). This distinguishes it from sibling tools like fs_list (which lists directory contents) and fs_mkdir/fs_move/fs_delete (which mutate the filesystem). The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or alternatives. It does not mention that fs_list would be used for listing entries or that other fs_* siblings are for mutations. The locking note ('call vm_unlock when finished') is about post-operation session management, not tool selection, so it does not help an agent choose between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only, but the description discloses a critical side effect: the VM remains locked and requires vm_unlock to be called. It also specifies the release order behavior. This goes beyond annotations and adds significant value. However, it doesn't mention other potential side effects or error conditions, so a 5 would be too generous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and the warning is concise. There is no redundant phrasing or filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the core behavior plus the critical lock side effect. However, it lacks details on valid key names and when to choose this over other keyboard tools. Since there is no output schema, the absence of return-value explanation is acceptable. Overall it is minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that the array order determines press order (and reverse for release), which is useful. However, it does not clarify what constitutes a 'named key', provide examples, or reference sibling keyboard tools for naming conventions. With 0% schema description coverage, this omission leaves the parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: pressing named keys sequentially and releasing in reverse order. This distinguishes it from siblings like keyboard_key (single key press) and keyboard_type (text entry). The mention of VM lock adds additional context without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides the core behavior but does not explicitly say when to use this tool versus alternatives like input_batch or keyboard_key. The lock note implies a session context, but there are no clear 'when to use' or 'instead of X' statements. It offers less guidance than the high-standard examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the important behavioral detail that the VM remains locked and requires vm_unlock when finished, which is not conveyed by the annotations. It also correctly implies a non-read-only action, consistent with readOnlyHint=false. However, it does not discuss other behaviors like event queuing or repeat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and adding the essential lock warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four optional parameters and no output schema, and the description provides minimal guidance beyond the key input type and lock state. The schema supplies types and bounds, but the description leaves the meaning of 'action' and 'extended' implicit, making it adequate but not thorough for a low-level input tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description only mentions 'virtual-key or scan-code', which maps to the virtual_key and scan_code parameters, but leaves action (down/up/press) and extended undocumented. The enum and defaults in the schema provide some structure, but the description does not explain their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Send a low-level Win32 virtual-key or scan-code input event', clearly stating the verb (send), resource (keyboard input), and scope (low-level virtual-key/scan-code). This distinguishes it from siblings like keyboard_type or keyboard_key for higher-level input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'low-level Win32' but does not explicitly compare with sibling tools such as keyboard_type or keyboard_hotkey. The VM locking note provides context that this is part of a locked session requiring vm_unlock, but no when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, but the description adds a key behavioral consequence: the VM remains locked by the session and requires vm_unlock. This is valuable context beyond the annotations, though it does not detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first defines the operation, the second states a critical post-condition. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and lock behavior, but lacks parameter guidance and does not direct the user to qemu_vm_trash_list to find VM IDs. For a simple one-parameter tool, it is partially complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the vm_id parameter. With 0% schema coverage, the agent has no guidance on what value to supply or how to discover it, leaving the parameter completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (restore), resource (managed VM), and source (broker trash). It distinguishes from siblings like qemu_vm_trash_empty and qemu_vm_snapshot_restore by specifying 'from broker trash' and mentioning the lock behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you want to recover a VM from trash and provides a concrete follow-up action (call vm_unlock). However, it does not explicitly mention alternatives like qemu_vm_trash_list for finding the vm_id, so it lacks exclusions but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses output ordering, error screenshot behavior, and the VM lock side effect, adding context beyond the annotations. It does not cover timeout or permission details, but the lock and output specifics are valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and a concise lock warning. Every word earns its place, no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core execution, output, and lock behavior, but omits parameter semantics for optional parameters and does not detail return format beyond ordered output. Given the tool's complexity and absence of output schema, this leaves noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain any parameters. It only implies the 'command' parameter via 'Run a command', leaving cwd, timeout_ms, and screenshot_on_error completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a command to completion and captures ordered stdout+stderr output, with a screenshot on error. This distinguishes it from interactive shell tools like shell_start and shell_read, specifying a concrete verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context that the command runs to completion and that the VM remains locked until vm_unlock is called, indicating when to use it and the follow-up action. However, it does not explicitly name alternatives for interactive sessions or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by disclosing that the session holds a VM lock and that vm_unlock should be called afterward. This is not inferable from destructiveHint=true alone. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. The first sentence states the primary purpose, and the second adds critical lock context. It is front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a simple one-parameter tool, the description covers the core purpose and lock behavior. However, it omits details about the session_id provenance, error handling, or what happens if the session doesn't exist. The annotations partially compensate, but completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the session_id parameter semantics, such as where it comes from or how it is used. The description only implicitly maps session_id to the running shell session, which is insufficient given the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb ('Terminate') and resource ('running interactive shell session'). It distinguishes the tool from siblings like shell_write, shell_read, and shell_start by focusing on termination, and the mention of VM lock adds unique context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context (VM remains locked, call vm_unlock when finished) but does not explicitly state when to use this tool versus alternatives like shell_close or process_kill. The usage guidance is implicit rather than explicit, with no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond annotations by noting that the VM remains locked and the user must call vm_unlock afterward, which is critical for session state management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the output fields, and the second conveys the essential lock/unlock workflow. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return fields and the critical lock context, but it omits any explanation of the visible_only parameter. Since there is no output schema, this gap is significant enough to make the description only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter visible_only is not mentioned in the description, and the schema provides no description coverage (0%). The agent must infer its semantics purely from the name, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists windows and enumerates the exact metadata returned (handle, title, class, process, visibility, enabled state, screen rectangle). This distinguishes it from sibling tools like window_focus or window_capture by specifying its output scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the VM remains locked by this session and instructs to call vm_unlock when finished. While it does not explicitly name alternatives or state when not to use it, the listing purpose is unambiguous and the workflow context is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant behavioral trait not captured by annotations: 'VM remains locked by this session; call vm_unlock when finished.' It also notes the text is 'basic QEMU monitor-compatible', setting expectations on scope. Annotations do not contradict this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, the second gives a critical follow-up instruction. No wasted words; it is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and no output schema, the description covers the main operation, target, and the important lock side-effect. It omits preconditions like VM running or error handling, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. It implicitly refers to 'text' but does not explain vm_id or any parameter-specific constraints, failing to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Type basic QEMU monitor-compatible text into the active QEMU display.' It uses a specific verb and resource, and the mention of 'QEMU monitor-compatible' distinguishes it from generic siblings like keyboard_type and qemu_keyboard_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (typing into the active QEMU display) and mentions the resulting lock, but it does not explicitly compare to alternatives or state when not to use this tool. The reference to 'QEMU monitor-compatible' hints at differentiation but without direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations by disclosing the lock side-effect: 'VM remains locked by this session; call vm_unlock when finished.' This informs the agent about a persistent state change that must be managed, which is not captured by readOnlyHint, destructiveHint, or idempotentHint. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the action and target clearly, while the second adds essential lock-release guidance. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move action, the description is adequate but leaves gaps: it does not state whether the VM must already be locked before invoking this tool, nor does it mention failure cases (e.g., invalid coordinates, VM not running). The lock-release instruction is helpful, but prerequisites and return behavior are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes x and y as 'Zero-based physical screen coordinate,' but vm_id lacks a description. The description 'to a running QEMU VM' clarifies the role of vm_id, and 'absolute' adds coordinate semantics, but it does not elaborate on expected values, units, or coordinate system boundaries beyond the schema's min/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Send absolute QMP mouse coordinates to a running QEMU VM.' It identifies the verb (send), resource (QEMU VM mouse), and distinguishes from sibling tools like qemu_mouse_click by specifying 'move' and 'absolute QMP mouse coordinates.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving a mouse within a QEMU VM but does not explicitly state when to use this tool instead of alternatives such as mouse_move or qemu_qmp_execute. It provides lifecycle guidance about lock release ('call vm_unlock when finished') but lacks explicit exclusion criteria or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructive=true and readOnly=false, but the description adds valuable behavioral context beyond those flags. It discloses that the VM is created locked by this session, that disk_path is broker-host-local, and that remote-media upload is not yet supported. This gives the agent important operational knowledge about post-conditions and limitations without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds meaningful information. There is no fluff or repetition. It efficiently communicates the action, a constraint, and an important post-condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a clear high-level description, the tool is complex with 13 parameters, nested objects, and no output schema. The description covers the high-level behavior and locking but omits any guidance on parameter semantics, possible return values, failure modes, or lifecycle interactions with other qemu_vm_* tools like qemu_vm_start. It is not sufficiently complete for the schema's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level explanations beyond mentioning disk_path. With 13 parameters, including nested objects like overrides and profile_overrides, the description does not compensate for the missing schema documentation. The agent is left with no guidance on what cpus, memory, profile, acceleration, or other fields mean or how they should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Import a broker-local disk into a new managed qcow2 QEMU VM.' It uses a specific verb ('Import') and resource ('new managed qcow2 QEMU VM'), which distinguishes it from sibling tools like qemu_vm_start, qemu_vm_update, or qemu_vm_delete. The additional context about disk_source being broker-local further clarifies the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by specifying that disk_path must be broker-local and that remote-media upload is unavailable. It also gives a concrete follow-up instruction: 'call vm_unlock when finished.' While it doesn't explicitly name alternative tools or conditions where another tool should be used, the context is sufficient for selecting this tool for local-disk VM creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the generic annotations, the description discloses validation behavior, batched execution, and a lock lifecycle ('VM remains locked by this session; call vm_unlock when finished'). It does not explain failure semantics or partial execution, but the added lock context is meaningful value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences convey the core purpose and critical lock requirement with no filler or redundancy. Every sentence contributes necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (many action types, three parameters, no output schema), and the description covers the main purpose and lock handling. However, it omits details such as validation failure behavior, whether the sequence is atomic, and what the tool returns or how errors are reported, leaving meaningful gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no direct explanation of the top-level parameters (actions, stop_on_error, screenshot_after). With 0% schema description coverage, the description should compensate but only offers a general list of action categories. This is insufficient for the tool's parameter complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Execute') and names the exact resource categories (mouse, keyboard, delay, clipboard, focus) while noting the batch behavior ('sequence in one guest round trip'). This clearly distinguishes it from the individual sibling input tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use the tool (for executing a multi-action sequence in one round trip) and gives important workflow context: the VM remains locked and vm_unlock must be called when finished. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnly=false, destructive=false, and idempotent=false, which are minimal. The description adds meaningful behavioral context by disclosing the VM lock state and the need to unlock. It does not contradict annotations, but could also mention whether the mouse button is released at the end.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the main action front-loaded and the lock reminder as a secondary note. Every word contributes value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary action and the lock requirement, but lacks details about how steps, duration_ms, or button affect the drag behavior. It also does not state whether the button is released after the drag. Given the tool's moderate complexity and minimal annotations, this is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes the four coordinate parameters (from_x, from_y, to_x, to_y) with 'Zero-based physical screen coordinate.' The description does not add meaning for the undocumented parameters steps, button, or duration_ms, leaving their effects unclear. With 57% schema coverage, some compensation from the description was expected but not provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drag between exact pixel coordinates while holding the selected mouse button'), identifying both the operation and its resource. This distinguishes it from sibling tools like mouse_move, mouse_click, and mouse_down/up, which have different behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting that the VM remains locked and instructs to call vm_unlock when finished. However, it does not explicitly mention when to use this tool over alternatives like mouse_move or input_batch, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by disclosing that the VM lock persists after waiting and that an explicit vm_unlock is required. It also mentions 'bounded period,' which implies a timeout behavior. However, it does not detail what happens on timeout (e.g., whether it errors or returns normally), leaving a small transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the primary purpose, the second a crucial side note about the VM lock. There is no filler or redundancy, and the information is front-loaded for easy parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and the lock behavior, but omits timeout semantics and return value expectations. Given no output schema, the agent is left to guess what happens on timeout or what the tool returns. This is a moderate gap for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, and the description does not explicitly explain process_id or timeout_ms. 'Bounded period' hints at timeout but does not name the parameter or specify units. With 0% schema coverage, the description fails to adequately compensate for the lack of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wait for a process to exit') and the bounded nature of the wait. This distinguishes it from siblings like process_kill (which terminates) and process_list (which enumerates), and from vm_wait which likely waits on VM-level states. The verb-resource pairing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 you need to block until a process exits) and provides a critical condition: the VM remains locked by this session, so vm_unlock must be called afterwards. It does not explicitly name alternative tools or exclusions, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and non-destructive behavior. The description adds a non-obvious side effect: the VM remains locked by the session and requires vm_unlock. This is valuable transparency beyond the annotations, though it does not describe error states or what happens if the controller has already started.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states what the tool does and when, the second discloses the locking behavior and required next step. No wasted words, all content is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, timing, and lock behavior, but with no output schema it fails to explain what the capture returns (e.g., image data, file path). It also omits error behavior for invalid timing (after controller start) or already-locked VMs. Adequate for a simple tool but leaves important usage gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention vm_id at all. The parameter name and pattern in the schema provide some basic meaning, but the description adds no additional context about how to identify the VM or any special format requirements beyond the pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Capture') and resource ('QEMU framebuffer') with a precise timing condition ('before the Windows controller has started'). This distinguishes it from the generic 'screen_capture' sibling and other QEMU tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear precondition ('before the Windows controller has started') and a required follow-up ('call vm_unlock when finished'). However, it does not explicitly mention when not to use it or contrast with alternative tools like screen_capture, which would strengthen the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds a critical, non-obvious behavioral trait: the VM remains locked after the preview, requiring a separate unlock call. This goes beyond the annotations and is essential for safe usage, earning a top score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core purpose, followed by a crucial side-effect warning. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, no output schema), the description adequately covers purpose, state-change guarantee, and lock behavior, but leaves a significant gap in parameter semantics and return value format. The lock warning is a strong addition, but the lack of any parameter hints makes the description only minimally complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 12 parameters with no descriptions (0% coverage), and the description provides no parameter information whatsoever. For a command-preview tool, the meaning of parameters like 'overrides', 'profile_overrides', or 'extra_args' is not explained, leaving the agent without guidance on how to use them effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Preview') and resource ('managed QEMU command'), and clarifies the tool's non-mutating nature ('without changing VM state'). This clearly distinguishes it from sibling tools that start, modify, or delete VMs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for inspecting a command before execution, and it explicitly notes that the VM remains locked and instructs the user to call vm_unlock when finished. This provides clear post-usage guidance, though it does not explicitly name alternative tools like qemu_vm_start or qemu_vm_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description exposes the session-locking side effect and the need for vm_unlock, plus technical details (QMP, guest TCP network). Annotations only state non-readonly and non-destructive, so this adds meaningful context. It doesn't mention what happens if the VM is already running or whether the call blocks, but the lock disclosure is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence structure. The first sentence names the operation and key features; the second delivers the essential locking and unlock requirement. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a VM start operation the description covers the primary action and the lock contract, but omits error behavior (e.g., VM already running or invalid ID), return expectations, and explicit parameter semantics. Since there is no output schema, some indication of what to expect after execution would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explicitly explain vm_id. The only clue is the tool name and 'Start a managed QEMU VM', which allows inference, but the description should compensate by stating that vm_id must reference an existing managed VM. It does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a managed QEMU VM with QMP and guest TCP networking. This is a specific verb+resource and distinguishes this operation from sibling tools like qemu_vm_create, qemu_vm_shutdown, and qemu_vm_restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the VM remains locked and instructs the caller to invoke vm_unlock when finished. It does not explicitly compare against alternatives or specify preconditions like 'VM must be stopped', so it misses exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=true, but the description adds useful behavioral context beyond that: the VM must be stopped and remains locked, requiring a follow-up unlock. This is valuable operational nuance not present in the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause adds value: the scope of updates, the stopped requirement, and the lock/unlock instruction. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (12 params, nested objects, no output schema, destructive hint), the description covers the key precondition (stopped) and the post-requirement (unlock). However, it doesn't mention return value, failure modes, whether the update is a full replacement or merge, or what 'managed' implies. This leaves gaps for an agent needing to fully anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for explaining parameters. It only hints at 'accelerator policy' and 'any profile component', which loosely map to acceleration and profile-related parameters, but leaves the remaining 10+ parameters wholly unexplained. This is insufficient for a 12-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a 'stopped managed QEMU VM definition' with a specific verb and resource, and distinguishes it from siblings by emphasizing the stopped state and definition-level scope. It also mentions coverable areas like accelerator policy and profile components, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the VM must be stopped and that it remains locked by this session, requiring vm_unlock afterward. It provides clear context for when to invoke the tool, though it doesn't explicitly name alternative tools for comparison, the precondition and lock instruction are valuable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait that normal unlock refuses while terminals or transfers remain open, which goes beyond annotations (readOnlyHint=false, idempotentHint=true). This is useful context for agents to anticipate failures. However, it doesn't elaborate on the force parameter's effects, so not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose. Every word adds value, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core action and a key failing condition, but omits explicit explanation of the force parameter and the consequences of releasing the lease. Given the low schema coverage, this is a notable gap, though the overall context is still understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional boolean parameter 'force' with 0% description coverage. The description hints at the need for force by stating the normal unlock refusal, but never explicitly explains that force overrides this check. This leaves parameter semantics largely implied rather than defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Release this session's VM lease' – clearly identifying the verb and resource. It also distinguishes the tool from generic unlock by noting the refusal condition, differentiating it from vm_lock and other session tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to release the VM lease, with a caveat that it normally refuses under certain conditions. However, it doesn't explicitly name alternatives or exclude when NOT to use it, though it gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description adds valuable nuance: it states that unrelated host files are not deleted, clarifies the merge-copy nature, and discloses the VM lock side effect with a follow-up unlock instruction. This goes beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences front-loaded with the exact operation and its key guarantee. Every word adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, safety nuance, and lock lifecycle, but it omits the behavior of the overwrite parameter and provides no information about return values or error conditions. Without an output schema or richer parameter docs, these gaps reduce completeness for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by mapping 'guest directory' to guest_path and 'host path' to host_path. However, it fails to explain the overwrite parameter, which is critical for understanding merge-copy behavior, so the semantics remain incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Merge-copy' and clearly identifies the resource (guest directory) and target (allowed host path). It distinguishes from siblings like file_pull and directory_push by emphasizing merge-copy semantics and the explicit preservation of unrelated host files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: when copying a guest directory to the host while preserving existing files, and it warns that the VM remains locked, directing the agent to call vm_unlock afterward. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds important behavioral context: the VM remains locked by this session and a temporary-file commit mechanism is involved. It also notes 'allowed host path,' implying authorization constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence gives the core function, the second provides essential usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides purpose, lock/unlock obligations, and path restrictions. Given the simple parameter set and lack of output schema, this is mostly complete. The main gap is the undocumented overwrite semantics, but that is more of a parameter issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies guest_path and host_path indirectly ('guest file' and 'host path'), but completely omits the overwrite parameter and its behavior. This partial coverage is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Copy') and resource ('guest file to an allowed host path'). It also differentiates from siblings like file_push and directory_pull by indicating direction and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is for copying guest files to host paths, and the lock/unlock requirement is stated. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructive nature is covered. The description adds valuable behavioral context beyond annotations: the VM lock state and the need to explicitly unlock afterwards, which is not encoded in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and follows with the critical lock context. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with no output schema, the description adequately covers purpose and the lock constraint. However, it does not address failure scenarios (e.g., non-existent path, permission errors) or the behavior of recursive=false on directories, which could be inferred from the schema but not explicitly stated. Given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. While 'path' and 'recursive' are self-explanatory from names, the description does not clarify that recursive is required for deleting non-empty directories or any path constraints. It merely mentions 'file or directory' without explaining how the parameters map.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a guest file or directory.' with a specific verb and resource, and the distinction from siblings like fs_move and fs_mkdir is evident. The additional note about VM lock pertains to context, not purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating the VM remains locked and instructing to call vm_unlock when finished. This implies the tool is used as part of a locked-VM workflow and gives a prerequisite/after-action, though it does not explicitly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description discloses that the VM stays locked by this session, a crucial side effect requiring a follow-up action. This is valuable behavioral transparency, though it doesn't detail other side effects like overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and a critical usage warning. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move/rename tool with no output schema, the description covers the essential aspects: the action, the resource type, and the important lock behavior. It omits error conditions or return values, but these are not critical for a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain source, destination, and overwrite. It only vaguely implies these are paths via the move/rename context, and overwrite is entirely unmentioned. This leaves the agent with limited semantic guidance for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves or renames a guest file or directory, which is a specific action on a specific resource. This distinguishes it from sibling file operations like fs_delete or fs_mkdir.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides critical usage context: the VM remains locked after this operation and vm_unlock must be called. This tells the agent when to call it in a sequence, but it does not explicitly compare it to alternative file operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects beyond annotations: the drive persists as empty for future starts, and the VM remains locked by the session requiring vm_unlock. Annotations provide no positive hints (all false), so the description carries the burden and does so effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, and the main action is front-loaded. Every clause adds value, including the lock reminder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main behavior and a critical side effect (lock). Lacks detail on edge cases like 'if not running' or what happens if no CD-ROM is present, but for a single-param tool with no output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description never mentions vm_id. While vm_id is likely obvious as the VM identifier, the description fails to clarify its role or tie it to the tool's action. With a single parameter, the baseline is higher, but the description adds nothing about it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Eject the managed CD-ROM'), the resource (CD-ROM), and timing ('now when running'), plus the persistence behavior. This distinguishes it from siblings like qemu_media_mount or qemu_media_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'when running' and 'persist an empty drive for future starts'. It also warns about the lock and instructs to call vm_unlock. No explicit exclusions or alternatives, but usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds valuable behavioral context by disclosing that the VM remains locked and instructing to call vm_unlock, which goes beyond the structured annotations. It also notes persistence across starts, which is not evident from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loads the primary action, and includes necessary constraints without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core action, the VM running condition, persistence, and the lock/unlock lifecycle. It lacks details about possible failure modes or relationship to other media operations, but is reasonably complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for both parameters, and the description does not explain vm_id or media_id. It only mentions 'managed ISO', which hints at media_id but does not describe the parameters' format or role. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mount') with a clear resource ('managed ISO') and scope ('when the VM is running and persist it for future starts'). It clearly distinguishes from sibling tools like qemu_media_eject (ejects) and qemu_media_set_boot (sets boot order).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool ('when the VM is running') and provides a required follow-up action ('call vm_unlock when finished'). However, it does not explicitly mention alternatives or when not to use it, though the lock/unlock context gives clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses a critical side effect (VM remains locked, requiring vm_unlock) and a behavioral constraint (broker-local path resolution). This adds meaningful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core function, followed by critical constraints. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple copy operation with no output schema, the description covers the main behavioral requirements (broker-local resolution, lock handling). Some gaps remain, such as the optional media_id semantics and whether overwriting is possible, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains source_path (resolved on broker host); media_id and vm_id are left unclear. The description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Copy') and resource (broker-local .iso into the VM's managed media directory), distinguishing it from siblings like qemu_media_mount/eject/delete. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides key usage constraints: source_path resolved on broker host, remote upload not available, and VM lock/unlock requirement. It does not explicitly name alternative tools but gives enough context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint:true, but the description adds that the VM remains locked by this session and must be unlocked after deletion. This discloses lock-holding behavior and cleanup requirements, which is context beyond what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, starts with the action and resource, and includes the lock/unlock note without any wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no output schema, the description covers the key precondition (VM stopped), the lock state, and the unlock follow-up. It is concise but sufficiently complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two required parameters with no descriptions (schema coverage 0%), and the description does not explain them. The only hint is 'named snapshot' which maps to the 'name' parameter, but vm_id remains implicit. The description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Delete' with a specific resource 'named qcow2 internal disk snapshot' and a clear precondition 'while the VM is stopped.' This clearly distinguishes it from sibling tools like qemu_snapshot_create and qemu_snapshot_restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the condition under which to use the tool (VM stopped) and the required follow-up action ('call vm_unlock when finished'). While it doesn't explicitly mention alternatives, the stop condition and unlock instruction provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that the trash is recoverable, that only the three newest entries are retained, and that the VM remains locked requiring an explicit vm_unlock. These are important behavioral details that the annotations (destructiveHint=true) do not capture. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. It uses two sentences to convey the action, the retention constraint, and the critical lock/unlock contract—no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational context: recoverability, retention limit, and the lock lifecycle. It omits any explanation of the force parameter, which is a notable gap for a potential risk-mitigating option. Otherwise, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines vm_id and force with no descriptions, and the description adds no parameter-level meaning. In particular, the 'force' parameter semantics are entirely unexplained, leaving it ambiguous whether force bypasses locks or affects retention. The description should have addressed this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and clearly identifies the resource (managed QEMU VM) and destination (recoverable broker trash), distinguishing it from permanent deletion or other VM operations. It also notes the retention policy, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when you want to delete a VM but keep it recoverable) and explains the retention limitation. It does not explicitly compare against sibling tools like qemu_vm_trash_empty, but the recoverable nature and lock note provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/read-only status, but the description adds a valuable side effect: the VM remains locked by this session and requires calling vm_unlock. This goes beyond the structured metadata, though details like potential data loss are left implicit under the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct and front-loaded with the action, with no filler. Every word contributes to understanding the tool's purpose and consequences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, condition, and lock side effect, and the sparse schema plus annotations make this mostly sufficient. It doesn't address return values, but for a force-stop action that's acceptable and doesn't hinder selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for vm_id (0% coverage), and the description doesn't mention or explain the parameter, leaving the agent to infer that vm_id identifies the target VM. The pattern constraint is in the schema but lacks semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forces a QEMU VM to stop immediately and specifies the context where graceful shutdown isn't possible, distinguishing it from shutdown/restart tools. The verb 'stop' + resource 'VM' + condition is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear condition ('when graceful shutdown is not possible') and a follow-up action ('call vm_unlock when finished'), which guides usage. However, it doesn't explicitly name alternatives like qemu_vm_shutdown, so the when-not-to-use guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds important behavioral detail: the restart is graceful and the VM remains locked by the session, requiring vm_unlock. This goes beyond the structured hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core action, and the second sentence adds valuable lock lifecycle information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter restart tool, the description covers the action, the graceful nature, and the lock state. It does not mention output or waiting behavior, but the lack of an output schema and the simplicity of the operation make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention vm_id at all. The schema only provides type and pattern constraints; there is no semantic guidance for the parameter. For a single obvious parameter, this is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: "Gracefully stop then restart a managed QEMU VM." This clearly distinguishes it from sibling tools like qemu_vm_start (start only) or qemu_vm_shutdown (stop only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to restart a VM while keeping it locked. It includes a follow-up instruction to call vm_unlock when finished, but it does not explicitly name alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnly=false, destructive=false), but the description adds crucial behavioral context: the VM remains locked by this session, implying a session-scoped side effect and a required finalization step (vm_unlock). It also clarifies that this tool does not affect in-guest MCP control. This goes beyond annotation-provided information, though it doesn't cover repeat behavior or lock conflicts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences and front-loads the primary purpose in the first sentence. The second sentence adds essential scope and lock guidance without any filler or repetition. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool with one parameter and no output schema, the description covers the key aspects: what it does, session scope, locking, and the need to unlock. It does not mention potential errors, return values (none), or what happens if another VM is already selected, but these are not critical for such a basic operation. The guidance to call vm_unlock adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the vm_id parameter at all. While the parameter is a simple string with a pattern, the tool name implies it selects a VM, but the description should ideally specify that vm_id identifies the target VM (e.g., via qemu_vm_list). The description adds no additional meaning to the parameter beyond what the schema already exposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records the selected QEMU VM for the session's QEMU panel, distinguishing it from siblings like qemu_vm_list (listing) and qemu_vm_unselect (deselecting). The verb 'Record' and the specific resource ('managed QEMU VM selected in this MCP/Admin session's QEMU panel') make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use it: it's for session-level selection, not for in-guest control (explicitly stated as 'In-guest MCP control remains the agent's outbound TCP connection'). It also instructs to call vm_unlock when finished. However, it does not name alternative tools (e.g., qemu_vm_unselect) or explicitly state when not to use, leaving some room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by noting that the VM remains locked after closing, which is not conveyed by the idempotentHint or destructiveHint flags. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and immediately followed by a critical lock consideration. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple close operation with one parameter and no output schema, the description provides sufficient context: what it does, when to use it, and the subsequent required action. Annotations cover safety and idempotency, making this complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the single parameter, and the tool description does not explain where session_id comes from or its format. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('release') and a specific resource ('broker resources for a completed interactive shell session'), clearly distinguishing it from sibling tools like shell_terminate. It also conveys the session lifecycle context without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use it (for a completed session) and provides an important follow-up instruction ('call vm_unlock when finished'). It does not explicitly name alternative tools or exclusions, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it destructive and non-read-only. The description adds important behavioral context: the session locks the VM and requires explicit unlock via vm_unlock. It also clarifies the 'interactive redirected-pipe' nature, which goes beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence front-loads the primary action and output; the second provides a critical usage warning. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key aspects: what it starts, the return value, and the locking side-effect with unlock guidance. Given no output schema, it appropriately mentions the session ID. It could be improved by noting available sibling tools for interacting with the session, but this is not essential for the start operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, and the description does not explain 'command' or 'cwd'. While names hint at meaning (command as the shell command, cwd as working directory), the description adds no additional semantics, leaving ambiguity about how command is used in an interactive session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Start an interactive redirected-pipe shell session') and the resource (a shell session). It also mentions the return value (session ID), distinguishing it from siblings like shell_exec or shell_write by emphasizing 'interactive' and 'session'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting the VM lock and instructing to call vm_unlock when finished. However, it does not explicitly compare to alternatives (e.g., shell_exec for non-interactive use) or state when not to use it, so there is no direct exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, but the description adds important behavioral context: the VM remains locked by this session and the guest cannot reconnect until external restart. It also mandates calling vm_unlock, which is beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, two sentences long, with the purpose front-loaded and the lock caveat following immediately. Every sentence provides critical information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple tool with only two optional parameters and no output schema, the description covers the essential effect (shutdown), the critical lock state, and the required follow-up (vm_unlock). It omits parameter-specific behavior, but that is already penalized in parameter semantics. Overall, it is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the description does not explain the meaning of 'force' or 'delay_seconds'. The agent receives no guidance on how these parameters affect the shutdown, leaving a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'shuts down Windows 98', which is a specific verb+resource. It distinguishes itself from sibling tools like system_reboot by indicating a full shutdown with no automatic restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (full shutdown, not reboot) by stating that the guest cannot reconnect until the VM is started externally. However, it does not explicitly name alternative tools or say when not to use it, so it lacks an explicit when-not condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral side effect: 'VM remains locked by this session; call vm_unlock when finished.' This goes beyond the annotations (which only indicate readOnlyHint false) by informing the agent about the lock state and required follow-up action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a distinct purpose: the first states the action, the second provides the critical lock/unlock instruction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers the action, the target environment (Windows 98), and the session lock behavior that requires vm_unlock. It lacks an explicit return value, but none is needed for a setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'text' with no description. The tool description implies the parameter is the replacement clipboard text, but does not explicitly explain its format or any constraints. Since schema coverage is 0%, the description partially compensates by associating 'text' with clipboard text, but could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Replace Windows 98 clipboard text.' This is a specific verb+resource and distinguishes clipboard_set from clipboard_get and other input tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear context: the VM remains locked by this session and instructs to call vm_unlock when finished. However, it does not explicitly mention alternatives or when not to use it, so it's slightly below a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds behavioral context about the verified temporary-file commit and the VM lock state, going beyond the annotations. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core action and then provide the essential lock/unlock context. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no output schema, and presence of annotations, the description covers the key behavioral aspects: the copy operation, the safety mechanism, and the lock lifecycle. It lacks details on return values or failure modes but these are not necessary given the context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies host_path is the source and guest_path the destination, but does not detail overwrite semantics or the commit process's effect on parameters. Parameter names are self-explanatory but limited beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Copy' with clear resource relationship 'host file into the guest', and mentions 'verified temporary-file commit' which adds specificity. This distinguishes it from file_pull (guest to host) and directory_push.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that the VM remains locked and instructs to call vm_unlock when finished, which guides usage flow. While it doesn't explicitly name alternatives, it establishes when this tool is appropriate (while locked) and the required follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds significant behavioral context beyond annotations by revealing that the VM remains locked by the session and that vm_unlock must be called afterward. This is a non-obvious side-effect/requirement not captured in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the core action ('List a guest directory') and immediately follow with a necessary caveat about unlocking the VM. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and rich annotations, the description covers essential context: the target is a guest directory, recursion is optional, and the VM lock must be released afterward. It does not mention the return format, but given the name and action, that is reasonably implied. The lock-unlock note adds completeness that goes beyond typical list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate, and it partially does: 'guest directory' clarifies the `path` parameter, and 'optionally recursively' explains the `recursive` boolean. However, the description does not add details about path format, error behavior, or what the listing returns, leaving the semantics shallow. The names are self-explanatory, but the description adds just enough to reach a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'guest directory' with the optional recursive qualifier. It clearly distinguishes fs_list from sibling tools like fs_stat, fs_mkdir, or fs_delete, making its purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important contextual usage guidance by noting 'VM remains locked by this session; call vm_unlock when finished.' This tells the agent when it needs to follow up with vm_unlock, which is a clear usage directive. However, it does not explicitly name alternatives or describe when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include false hints, so the description carries the burden. It discloses two important behaviors: the VM remains locked after this call until vm_unlock, and the button must be released later. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the core action, and the second gives essential follow-up instructions. Information is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mouse input tool, the description covers the action, optional coordinates, necessary release, and the VM lock side effect. It lacks detail about return values, but no output schema exists and the tool is simple. The pairing with vm_unlock is a key completeness element.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents x and y as 'Zero-based physical screen coordinate.' The description adds that moving to coordinates is optional, but does not explain the button parameter, which is only covered by its enum. With 67% schema coverage, the description offers modest added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Hold a mouse button down' with optional coordinate movement. This distinguishes it from siblings like mouse_click, mouse_up, and mouse_move, which perform related but different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context by instructing to 'Always release it later' and noting the VM lock with 'call vm_unlock when finished.' It implies a paired workflow with mouse_up but does not explicitly contrast with alternative tools like mouse_click.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a critical behavioral detail not already in the annotations: the session lock persists and requires a separate vm_unlock call. This is valuable context beyond the idempotent and non-destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the core action front-loaded. The lock warning is relevant and adds necessary operational context without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and the important lock consequence. It omits preconditions (e.g., whether the VM should already be locked) and duration_ms semantics, but given the tool's simplicity and annotation coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description reinforces the meaning of x and y as zero-based physical coordinates, which matches the schema descriptions, but it does not explain the optional duration_ms parameter, leaving 33% of parameters undocumented. The schema covers most of the parameter semantics, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move the mouse') and specifies the exact coordinate system ('zero-based physical pixel coordinate'), distinguishing it from sibling input tools like mouse_click and mouse_drag. The verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides practical context by noting that the VM remains locked and instructing to call vm_unlock when finished. This gives the agent clear follow-up guidance, though it does not explicitly contrast with alternative input methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds meaningful behavioral context beyond annotations: the VM will remain locked after execution and vm_unlock must be called. This is a significant side-effect not captured by the annotations and is critical for the agent to avoid deadlocks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, starting with the core check scope and ending with a critical behavioral warning. Every sentence carries necessary information with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description could mention return format or error conditions, but the tool is a diagnostic check with a clear purpose. It covers the main function, the lock side-effect, and the need to unlock. Given the simplicity of the tool and annotations, this is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It references 'configured binary' and 'accelerator policy', which map to qemu_binary and acceleration, but it does not explain the `profile` parameter at all. The enums provide values, but the description does not clarify how parameters influence the check, leaving partial but non-complete guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and enumerates precise resources: local QEMU host, configured binary, managed VM root, accelerator policy, and guest-to-host TCP route. This clearly differentiates it from sibling status/list tools like qemu_vm_status and system_info, which focus on VM or system state rather than host-level QEMU diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies diagnostic use by enumerating what is checked, and provides explicit after-use context: 'VM remains locked by this session; call vm_unlock when finished.' This gives clear context on when the lock side-effect applies, though it does not explicitly name alternative tools or conditions to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the important behavioral detail that the VM remains locked by the session and requires vm_unlock. This goes beyond the annotations, which only indicate destructiveHint=true. It also specifies that the snapshot is internal and qcow2, adding technical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the primary action front-loaded. It contains no redundant information and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key operational context: precondition (VM stopped), locking behavior, and required unlock call. It does not describe return values or error handling, but the tool is simple enough that this is acceptable given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must clarify parameter semantics. It implies 'name' via 'named snapshot' and 'vm_id' via 'VM', but does not explicitly define either. The parameter meanings are inferable from context, but not fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a named qcow2 internal disk snapshot while the VM is stopped.' This distinguishes it from sibling tools like qemu_snapshot_delete, qemu_snapshot_restore, and qemu_snapshot_list by specifying creation and the snapshot format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets an explicit precondition ('while the VM is stopped') and provides a follow-up instruction ('call vm_unlock when finished'). This gives clear context for when to use the tool, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a significant behavioral note that the VM remains locked by the session and advises calling vm_unlock afterward. This goes beyond the annotations (readOnlyHint, idempotentHint) by disclosing a session-lock related side condition, which is important for the agent to know for proper workflow management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both directly relevant. The primary action is front-loaded, and the additional lock warning is concise and actionable. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description covers the essential purpose and the important lock note. It could be slightly clearer about what 'lifecycle state' includes or that it returns a list of VMs, but the core information is present and sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on the operation itself rather than parameter details, which are unnecessary. It adds no confusion and aligns with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'broker-managed QEMU VMs' along with the output 'their lifecycle state'. This distinguishes it from sibling tools like qemu_vm_status which focuses on a single VM's status, while this lists all managed VMs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as qemu_vm_status or qemu_vm_select. However, it provides a clear follow-up instruction ('call vm_unlock when finished') which gives some usage context, but no explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the 40-second wait, the fallback force-stop behavior, and the fact that the VM remains locked by the session. This adds significant behavioral context not present in annotations. It does not contradict annotations and provides a clear operational sequence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then the critical follow-up instruction. No wasted words; every phrase contributes to understanding the tool's behavior and workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the complete workflow: graceful shutdown, timeout, fallback force-stop, scope (only this process), and required next step (vm_unlock). It is self-contained and sufficient for correct invocation despite the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for vm_id, and the description does not mention the parameter at all. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation, leaving the agent to infer that vm_id is the target VM identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'shutdown' with a clear resource and detailed procedure: requests graceful guest shutdown, waits 40 seconds, then force-stops the QEMU process if needed. This clearly distinguishes it from sibling tools like qemu_vm_force_stop (which implies immediate termination) and qemu_vm_restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: when a graceful shutdown with fallback is desired. It also explains the lock retention and instructs to call vm_unlock afterward, which is critical usage guidance. However, it does not explicitly name alternatives or state when not to use it (e.g., if immediate termination is needed), leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the operation locks the VM and that stdin can optionally be closed. This is valuable behavioral context that annotations do not provide. No contradiction exists since readOnlyHint=false aligns with the write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and every word adds value. The critical unlock instruction is included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core function and locking behavior, making it usable for a simple write operation. It does not explain prerequisites like an existing interactive shell session or the output/return behavior, but given moderate complexity and no output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description compensates by explaining the purpose of text and base64 (content) and eof (closing stdin). However, it fails to mention the session_id parameter or clarify mutual exclusivity between text and base64, leaving gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Write UTF-8 text or base64 bytes to an interactive shell' and optionally close stdin. This specific verb+resource+content type distinguishes it from siblings like shell_read (reads) and shell_exec (executes commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the VM remains locked and instructs to call vm_unlock when finished, guiding when to invoke this tool in a session. However, it does not explicitly compare against alternatives like shell_exec or shell_start, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant behavioral trait beyond annotations: it acquires the VM lease and locks the VM for the session. This adds valuable context about side effects and requires a companion tool call, which annotations do not convey. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary purpose, and then immediately presents the critical locking behavior. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and sibling tools like vm_lock and vm_unlock, the description provides all necessary context: what it does, the lease acquisition, the locked state, and the required unlock call. It is fully complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'message' parameter at all. The schema only provides the parameter name and type, leaving the description to compensate. Although the parameter is self-explanatory, the description fails to add any meaning beyond the schema, warranting a low score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Display') and resource ('a Windows 98 message dialog titled Windows 98 Remote Control'). It distinguishes itself from sibling tools by specifying the exact type of dialog and its title, which is unique among the tool list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that the tool acquires the VM lease and leaves the VM locked, with a direct call-to-action to use vm_unlock when finished. This provides clear context for when to use the tool and the necessary follow-up, though it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it explicitly states that the tool does not delete unrelated guest files, clarifying the nature of its destructiveness, and it discloses that the VM remains locked by the session, requiring a subsequent vm_unlock call. These are important side effects not evident from the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of only two sentences. The first sentence states the core purpose, and the second provides critical lock-related instruction. Every word earns its place, with no redundant or ambiguous filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main merge-copy behavior and the lock requirement, it omits explanation of the 'overwrite' parameter, which is a key aspect given the destructiveHint annotation. The lack of output schema and schema descriptions means the description should have addressed this parameter. The tool is moderately complex, and this gap makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly covers the two required parameters, host_path and guest_path, by referring to 'host directory' and 'guest'. However, it does not explain the 'overwrite' parameter, which is especially important given that the schema has no descriptions (0% coverage). The behavior of overwrite remains ambiguous, so the description only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Merge-copy a host directory into the guest' which identifies the specific action (merge-copy), resource (host directory), and target (guest). It also distinguishes itself from a plain copy by explicitly noting it does not delete unrelated guest files, which differentiates it from sibling tools like file_push or directory_pull.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it is a merge-copy that preserves unrelated guest files, and it notes that the VM remains locked, instructing to call vm_unlock when finished. However, it does not explicitly name alternative tools or state when not to use it, so it lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral disclosure beyond annotations: it states the tool fails rather than substituting unrepresentable characters, and that the VM remains locked requiring a vm_unlock call. These are not captured by the annotations (which only indicate basic mutability/destructiveness aspects). This gives the agent critical operational context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and then a critical operational note. Every clause adds value: the typing function, the failure behavior, and the lock/unlock requirement. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the essential behavior, failure mode, and a crucial locking side-effect. It omits what the tool returns or the exact effect of interval_ms, but the absence of an output schema reduces the need to describe return values. The tool's complexity is low, and the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'text' parameter implicitly ('Type text...') but does not mention 'interval_ms' at all. The interval_ms parameter is left entirely to its name and schema constraints, providing incomplete meaning. The description does not fully clarify the purpose or units for interval_ms, which is a gap given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Type text with the active Windows 98 keyboard layout'. It also differentiates from sibling tools by noting it 'fails rather than substituting unrepresentable characters', which distinguishes it from more permissive typing tools. The function is unambiguous and distinct from keyboard_key, hotkey, or batch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it types text, and includes an explicit follow-up instruction ('VM remains locked by this session; call vm_unlock when finished'). It does not name alternative tools or state when NOT to use it, so it lacks full exclusionary guidance. The mention of failure on unrepresentable characters implies a usage caution but not a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that guest wheel support is required and that the VM lock remains held after the call, necessitating a subsequent vm_unlock. These are important behavioral traits not captured by the readOnlyHint or destructiveHint flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core action, then add necessary prerequisites and lock guidance. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple input action with no output schema, the description covers the action, prerequisites, and required follow-up unlock. It does not need to explain return values, and the input schema covers coordinate bounds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional coordinates' and 'mouse-wheel delta' which loosely maps to the parameters, but it does not clarify the meaning of delta (e.g., units or sign). The schema already describes x and y as zero-based physical screen coordinates, so the description adds little beyond that. With delta's schema description missing, the description leaves its semantics vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a mouse-wheel delta at optional coordinates.' This specific verb+resource combination distinguishes it from sibling mouse tools like mouse_move (moving the cursor) and mouse_click (clicking). It also mentions optional coordinates, which adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires guest wheel support') and a post-condition ('VM remains locked by this session; call vm_unlock when finished'). This gives context for when and how to use the tool safely, though it does not explicitly compare with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses a critical behavioral trait: the tool keeps the VM locked and requires vm_unlock to be called afterward. This is essential context that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences: the first states the action and resource, the second states a critical follow-up. No wasted words; it is front-loaded and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-metrics tool with annotations and a single parameter, the description provides the essential facts: what it reads and the lock/unlock contract. It doesn't detail return values, but no output schema exists and the tool's purpose is straightforward. It could mention the metric categories, but is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (vm_id) with no description, and the description does not mention it at all. With 0% schema description coverage, the description should compensate, but it adds no meaning beyond the parameter name and pattern. The parameter is simple, but the description still fails to provide any semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' with a clear resource: 'managed QEMU process and QMP metrics.' This distinguishes it from sibling tools like qemu_vm_status or qemu_vm_list, and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'VM remains locked by this session; call vm_unlock when finished,' which tells the agent this is part of a lock-hold workflow. It doesn't explicitly name alternatives or exclusions, but it provides clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a critical behavioral detail beyond these: the VM is locked by this session and requires vm_unlock. This is a side effect not captured by the annotations, and it is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states what the tool does and includes a necessary behavioral caveat. Every phrase contributes value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with strong annotations and a single parameter, the description covers the essential state being read and the lock semantics. However, with no output schema, it does not describe the return format or fields, which is a minor gap but not critical given the simplicity and available annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter vm_id with 0% description coverage, and the tool description makes no mention of it. The description should compensate for the schema's lack of parameter documentation, but it does not. The parameter name is somewhat self-explanatory, but the description adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource: 'one managed QEMU VM's process, QMP, and guest TCP transport state.' This distinguishes it from sibling tools like qemu_vm_list (which lists VMs) and qemu_vm_metrics (which likely focuses on metrics), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: to read status of a single VM. It also provides an important usage instruction: 'VM remains locked by this session; call vm_unlock when finished.' While it doesn't explicitly name alternatives or exclusions, the context and sibling list make that less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses a significant side effect: acquiring the VM lease and leaving the VM locked until vm_unlock is called. It also specifies the output format as native MCP PNG image content, adding valuable behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the primary purpose and immediately follows with the essential locking caveat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested schema, no output schema, and moderate complexity. The description covers the core behavior, output format, and locking side effect. It is mostly complete, but the missing include_cursor parameter semantics prevent it from being fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. It clarifies that the region parameter is optional (capture primary display vs. a pixel region), but it does not mention the include_cursor parameter at all, nor does it explain the region object's width/height semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Capture the primary display or a pixel region as native MCP PNG image content.' This clearly distinguishes it from sibling tools like window_capture, which targets windows, and clipboard_get, which targets clipboard content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (capturing a display or pixel region) and adds critical operational guidance about the VM lease. However, it does not explicitly name alternatives such as window_capture or state when not to use this tool, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already include destructiveHint:true, the description adds meaningful behavioral context beyond that: it disconnects the guest, requires configured autostart for recovery, and leaves the VM locked by the current session. It also provides a clear follow-up action (vm_unlock). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. The first sentence states the core action, and the second covers essential consequences and follow-up. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive reboot operation, the description covers purpose, disconnect side-effect, recovery prerequisite, and the need to unlock afterward. However, it omits any explanation of the force and delay_seconds parameters, and there is no output schema. It is complete for the core behavior but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (force and delay_seconds) with 0% schema description coverage, and the description does not explain either. The parameter names are self-explanatory to a degree, but the description fails to compensate for the lack of schema description, leaving the meaning and implications of 'force' and 'delay_seconds' ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Reboot Windows 98', a specific verb and target that clearly states the action and resource. It also differentiates from the sibling tool system_shutdown by indicating a reboot (not a shutdown) and includes the guest-disconnect consequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it disconnects the guest, requires configured autostart for recovery, and notes that the VM remains locked by this session, directing the user to call vm_unlock when finished. It does not explicitly name alternatives like system_shutdown, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds valuable extra behavior: after closing the window, the VM remains locked by the session and must be explicitly unlocked via vm_unlock. This is useful post-condition context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It conveys the core action and the essential lifecycle caveat about vm_unlock in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with a destructive annotation and no output schema, the description covers the action and the important lock-state implication. The parameter schema provides the source of the window_id. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description 'Window handle returned by window_list' is already in the schema. The tool description does not add additional parameter semantics beyond what the schema provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the specific action ('Request that a selected window close') with the resource being a selected window, which matches the tool name and clearly distinguishes it from sibling window tools like window_list, window_focus, and window_capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual guidance about the VM session lock lifecycle, instructing to call vm_unlock when finished. While it does not name explicit alternatives, there are no alternative close tools among siblings, and the locking instruction gives practical when-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly/idempotent), the description discloses that the VM lock is retained and that vm_unlock must be called, adding critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, and the lock/unlock instruction is essential and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description covers the action, the locked-session context, and the required unlock follow-up. The return value is implicit in 'Read text', and no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'format' is constrained to 'text' in the schema with a default, so no further explanation is necessary. The description's mention of 'text' is consistent with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read text from the Windows 98 clipboard' with a specific verb, resource, and scope, distinguishing it from clipboard_set and other VM tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that the VM remains locked and instructs calling vm_unlock when finished, establishing a post-condition. This implies usage while the VM is locked, though no explicit alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds a critical behavioral detail beyond annotations: the VM remains locked by this session and must be unlocked with vm_unlock. This is essential for the agent to avoid leaving the system in a locked state. It also clarifies the optional coordinate behavior, which annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no wasted words. The VM lock warning is placed appropriately after the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core behavior and the critical VM lock/unlock context. It could mention click_count or the physical coordinate system, but the schema already handles some of that, and the tool is relatively simple. Overall, it is sufficiently complete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description partially compensates by clarifying coordinate optionality. However, it does not explain the semantics of button, click_count, or interval_ms, leaving gaps that the schema does not fully fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (click), the resource (mouse), and the flexibility of using either supplied coordinates or the current pointer position. This sharply distinguishes it from sibling tools like mouse_down, mouse_up, mouse_move, and mouse_drag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use this tool, including the ability to omit coordinates for the current pointer position. It also notes the VM lock requirement, but it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a safe, read-only, idempotent operation. The description adds valuable behavioral context beyond annotations: the tool's usage is tied to a locked VM session and requires an explicit vm_unlock call afterward. This stateful detail is not captured in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action and followed by a necessary behavioral note. There is no wordiness; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description covers the core operation and the lock/unlock requirement. It could optionally specify the return format (e.g., x/y coordinates), but the tool name and simplicity make this a minor gap. Overall it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description adds no parameter-specific information, but none is needed since the input schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Read the current mouse pointer position.' This differentiates it from sibling input tools like mouse_move and mouse_click, and the read-only intent is obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool: when you need the current pointer position. It also provides important sequencing context by stating that the VM remains locked and to call vm_unlock when finished, guiding the agent's workflow. However, it does not mention explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by mentioning the optional move-before-release and the VM lock persistence. It does not contradict the idempotentHint or destructiveHint annotations, and the disclosure is adequate for a simple input tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The first sentence names the core action, and the second provides essential lock-related instructions. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mouse input tool, the description plus schema and annotations cover the action, optional parameters, and the lock lifecycle. It does not explicitly mention the sequence ('use after mouse_down') or compare with mouse_release_all, but those gaps are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes x/y as coordinates. The description adds that these are optional movement targets before release, which clarifies why they are optional. The button parameter is self-explanatory via its enum and default, and the description's 'held mouse button' ties it to the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Release a held mouse button' is a specific verb+object description that clearly differentiates this tool from siblings like mouse_down, mouse_click, and mouse_release_all. It also adds the optional movement behavior, which further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a mouse button is currently held and optionally after moving to coordinates. The VM lock note gives important sequencing context ('call vm_unlock when finished'), though it does not explicitly compare against alternatives like mouse_release_all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the force parameter's eject-first behavior and the critical side-effect that the VM remains locked by the session, requiring vm_unlock. This is valuable behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. It front-loads the purpose, then adds force semantics and the lock requirement. Every sentence contributes essential information with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, the conditional force behavior, and the important post-condition (lock remains). It does not explicitly state error conditions (e.g., if the ISO is mounted and force=false), but for a simple deletion tool with no output schema, the information is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explicitly explains the force parameter ('ejects it first when it is mounted'). The vm_id and media_id parameters are self-evident from their names and the tool context, though the description does not elaborate on them. This is partial, but not full, compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Delete an unmounted managed ISO.' The verb 'delete' and resource 'managed ISO' are specific and distinguish it from sibling tools like qemu_media_mount, qemu_media_eject, and qemu_vm_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: for deleting an ISO, with force=true if it is mounted. It also gives an important usage constraint by noting the VM remains locked and instructing to call vm_unlock. However, it does not explicitly mention alternatives or when not to use it, such as using qemu_media_eject for a simple eject.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations offering no useful hints (all false), the description carries the full burden. It discloses the lock side effect, the unlock requirement, and the QMP mechanism, which are essential behavioral traits beyond what the schema or annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and context, followed by the lock warning. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool with no output schema, the description adequately covers the usage context (pre-Windows) and the lock/unlock lifecycle. It doesn't explicitly mention that the coordinates are zero-based, but that is in the schema, so no critical gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information. The schema already covers x and y with descriptions and button with an enum/default, while vm_id is inferable from its name. With 50% schema coverage, there is no significant gap, but the description does not enhance understanding of any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Move then click through QMP' and provides the specific context 'before the Windows controller is available.' This distinguishes it from siblings like qemu_mouse_move (move only) and mouse_click (generic), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('before the Windows controller is available') and gives a critical follow-up instruction ('call vm_unlock when finished'). While it doesn't name alternative tools, the timing condition and lock reminder provide strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description discloses that the VM must be stopped and that the VM remains locked by this session, requiring vm_unlock. This is actionable behavioral context that the annotations do not capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no extraneous words. The first sentence states the core function; the second provides necessary lock handling guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and param descriptions, the description covers the essential scenario: restore an internal snapshot, with prerequisites and follow-up. It could mention that the snapshot name must exist or that the current disk state is overwritten, but annotations cover destructiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for vm_id or name (0% coverage). The description adds that the snapshot is 'named' and an 'internal disk snapshot', clarifying the name parameter, but does not elaborate on parameter formats or where to find valid snapshot names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restore'), the resource ('named qcow2 internal disk snapshot'), and the condition ('while the VM is stopped'). It distinguishes from sibling tools like qemu_snapshot_delete or qemu_vm_restore by specifying internal disk snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: the VM must be stopped and the session holds the VM lock, with a required follow-up call to vm_unlock. It does not explicitly mention alternative tools or exclusions, but the precondition and post-action are enough for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds the important side effect that the VM remains locked by this session, which is not captured by the annotations. This is valuable behavioral context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and includes only the essential lock caveat. Every word earns its place; no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description is mostly complete. It explains the core purpose and the critical lock side effect. It could further clarify what 'recoverable' means or how the lock affects other operations, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. The schema is empty and fully covers the parameter surface, giving a baseline of 4. The description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recoverable deleted managed VMs, which is a specific verb and resource. It distinguishes itself from qemu_vm_list (active VMs) and qemu_vm_trash_empty (emptying trash).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning the VM remains locked by this session and instructs to call vm_unlock when finished. It does not explicitly name alternatives, but the 'recoverable deleted' scope implies when to use this over other list/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds the valuable behavioral detail of not acquiring the VM lease, which is not present in annotations. It does not describe return format or edge cases, but given the safety profile already covered, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the active verb 'Read', and includes all necessary information without any fluff. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully states the action and the key lease-free constraint. The term 'capabilities' could arguably be more specific, but in the VM context and with the sibling tool set, it is sufficiently clear. It is complete enough for an agent to know when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially 100% covered. The description cannot add parameter semantics beyond what the schema provides. Per the baseline for zero-parameter tools, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and identifies the resource as 'connected Windows 98 guest capabilities'. The qualifier 'without acquiring the VM lease' distinguishes it from sibling tools that likely require lease acquisition. This leaves 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without acquiring the VM lease' provides clear usage context: it is a lightweight read that avoids the overhead of lease acquisition. While it does not explicitly name alternative tools, it implies this is the go-to for capability checks when lease-free access is desired. This meets the bar for clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already establish the safe read-only nature. The description adds valuable behavioral context by clarifying that no VM lease is acquired, which is a non-obvious operational detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and object, then adds a key differentiating detail. No wasted words—every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only diagnostic tool with strong annotations, the description is fully adequate. It communicates the core purpose and the lease-free behavior, which is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameter meanings. The baseline of 4 applies, and the empty schema aligns with the tool's simple read-only nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and names the exact resources ('guest crash context and supervisor recovery status'). It also distinguishes itself from sibling tools like vm_status by noting 'without acquiring the VM lease', making the tool's scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without acquiring the VM lease' provides clear context for when to use this tool: when a lightweight diagnostic read is needed without locking the VM. While it doesn't explicitly name alternative tools, the context implies this is the go-to for non-invasive crash/recovery checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotentHint, destructiveHint), the description adds that only keys tracked by this session are released, and that the VM lock persists. This is valuable behavioral context for the agent, covering scope and state after the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core purpose, and the second provides a critical next-step instruction. No word is wasted, and the structure is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully covers what the tool does and what the agent should do next. The session-scope clarification and lock reminder complete the context without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects that completely. Per the baseline for zero parameters, the description does not need to add parameter details, and it does not. The description focuses on behavior rather than parameters, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Release every keyboard key tracked as held by this session.' It uses a specific verb and identifies the resource ('every keyboard key'), and the scope ('by this session') distinguishes it from global key release tools or mouse_release_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: after releasing keys, the VM remains locked and the user should call vm_unlock. This gives a directive for a typical usage flow, though it does not explicitly mention alternatives or exclusions (e.g., when not to use).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state idempotency and non-destructiveness. The description adds valuable context: the release is scoped to 'this session', and the VM lock is preserved, requiring a separate vm_unlock call. This goes beyond the structured hints and warns the agent about session lock behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first states the primary action, the second clarifies an important side effect. No fluff or repetition of schema annotations. Every word adds value and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully covers what the tool does, its session scope, and the follow-up action needed (vm_unlock). It is complete enough for an agent to select and invoke it correctly without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter details. Baseline for no-parameter tools is 4, and the description correctly focuses on the action and its side effects rather than inventing unnecessary parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Release') with a clear resource ('every mouse button tracked as held by this session'). It distinguishes itself from siblings like mouse_up (which releases a specific button) and keyboard_release_all (which handles keyboard). The scope 'tracked as held by this session' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to reset all mouse held states for the session. It does not explicitly name alternatives (e.g., mouse_up for individual buttons), but the context of session tracking and the note about the VM remaining locked provide clear situational guidance. It lacks an explicit 'use instead of...' but is still helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a significant behavioral trait not covered by annotations: the VM remains locked by this session and must be unlocked with vm_unlock. Also clarifies it reports the mounted ISO, adding useful output context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the purpose front-loaded. Every sentence adds value: the first states the action and scope, the second provides a critical locking caveat. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool lists, what it reports (mounted ISO), and the lock behavior. With no output schema, this sufficiently sets expectations for a read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter vm_id is not described in the schema or description; the description's reference to 'this managed VM' implies its purpose but does not specify format or origin. With 0% schema coverage, the description should compensate more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ISO images in a VM's media directory and reports the mounted ISO, distinguishing it from sibling tools like qemu_media_mount or qemu_media_eject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is a read-only listing operation and notes the VM remains locked, requiring vm_unlock. However, it does not explicitly mention when to use it vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and non-destructive annotations, the description discloses a critical side effect: the VM remains locked by the session and requires a call to vm_unlock. This is important behavioral context not captured in structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action and resource, followed by a necessary behavioral note. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers the main constraint (stopped-VM), the safety profile (via annotations), and the lock side-effect. No critical gaps for the agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (vm_id) exists with zero schema description coverage. The parameter name is self-explanatory, but the description does not explicitly mention it or add detail about how to specify the VM. It neither confuses nor significantly enhances the schema, landing at the minimum viable score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'stopped-VM qcow2 internal snapshots', and the 'stopped-VM' qualifier distinguishes it from other snapshot operations. It clearly states what the tool does and helps differentiate from qemu_snapshot_create/restore/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that this tool is for stopped VMs and notes the locking behavior, implying it should be paired with vm_unlock. However, it does not explicitly name alternative tools or exclusion criteria, though the sibling snapshot tools are obvious alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds that deletion is permanent and that the VM lock is retained by this session, requiring vm_unlock afterwards. This is important behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. The first states the action, the second states the critical lock post-condition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter destructive operation, the description fully covers scope (all retained entries), permanence, and lock behavior. No output schema is necessary, and the follow-up instruction adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. Per rubric, 0 parameters gets a baseline of 4; no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'delete' with a clear resource: 'every retained QEMU trash entry'. This distinguishes it from sibling tools like qemu_vm_trash_list (listing) and qemu_vm_restore (restoring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly name alternatives, the description provides actionable context: after emptying trash, the VM remains locked and the agent should call vm_unlock. This indicates when to perform a follow-up action but does not contrast with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds value by clarifying that no lease is acquired and that it inspects both connection and lease state, which is beyond the annotation metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes meaning: 'Inspect', the target state, and the critical 'without acquiring the VM lease' qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, but rich annotations), the description fully covers what the tool does and its key behavioral constraint. It is complete for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is fully automated. The description correctly avoids adding parameter details, earning the baseline 4 for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and identifies the target resource ('guest connection and lease state'). It also distinguishes itself from lease-acquiring tools by noting it does so 'without acquiring the VM lease'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for non-invasive inspection and explicitly states it does not acquire the VM lease, which implies use when a read-only status check is needed. However, it does not name specific alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: it blocks for a maximum of ten minutes, it is stateful (VM remains locked), and it requires a follow-up vm_unlock call. These are not captured in the annotations (readOnlyHint false, destructiveHint false) and add critical context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds essential information (timeout, usage timing, lock state, follow-up). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a blocking wait operation with no output schema, the description covers the essential context: when to use it, the timeout bound, the lock state, and the required unlock call. It is sufficiently complete for an agent to invoke the tool correctly in the context of sibling VM tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, wait_seconds, with min/max values but zero description coverage. The description mentions 'at most ten minutes' which aligns with the max 600 seconds, but it does not explicitly state that wait_seconds controls the wait duration. The semantic link is implicit but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits in a FIFO lease queue for at most ten minutes, using a specific verb ('wait') and resource ('FIFO lease queue'). It distinguishes itself from sibling tools like process_wait by specifying the VM lease context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after VM_BUSY', providing a clear trigger condition. It also implies the usage pattern by noting the VM remains locked and vm_unlock should follow. However, it does not mention alternative tools or when not to use this one, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds critical behavioral information: the VM is locked by this session and must be unlocked via vm_unlock. It also discloses the return format (native MCP PNG image content), which is not in the annotations. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and output, followed by a crucial lock/unlock note. Every word adds value with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the action, output type, and a critical lifecycle requirement (unlock). The lock behavior is essential context that would be otherwise unknown. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for window_id ('Window handle returned by window_list'), so the schema already provides full parameter meaning. The description adds no extra parameter-level detail beyond what the schema states, meeting the baseline expectation without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture a selected window') and the resource (a window), with the output format specified as 'native MCP PNG image content'. It distinguishes itself from siblings like screen_capture (whole screen) and window_list (listing windows) by focusing on single-window capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the VM remains locked after capture and that vm_unlock must be called when finished, indicating a precondition and follow-up action. It does not explicitly name alternatives or state when not to use this tool, but the context is clear enough for an agent to decide to use it when capturing a specific window.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the VM remains locked by this session and requires a future vm_unlock call. This is valuable behavioral context not available in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, and no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and no output schema, the description covers purpose, usage context, and a side effect. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes window_id as 'Window handle returned by window_list.' The description repeats this fact without adding new meaning, so baseline 3 applies with full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Bring a window returned by window_list to the foreground.' This clearly distinguishes the tool from siblings like window_close and window_capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage after window_list and provides a critical follow-up instruction: 'call vm_unlock when finished.' It lacks explicit when-not-to-use guidance but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the annotations: it explains the default child-tree termination behavior ('by default, its discovered child tree') and the VM lock side effect ('VM remains locked by this session'). This goes well beyond the destructiveHint and readOnlyHint flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and efficiently communicates the key behavior (child tree) and a critical side effect (VM lock). Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, the default child-tree handling, and the VM locking side effect. It does not mention error behavior or return values, but since no output schema exists, that information would be helpful. However, given the tool's relative simplicity (2 params, one required), the description is sufficiently complete for a highly destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining the 'tree' parameter's default behavior ('by default, its discovered child tree'). It also implies that process_id identifies the target process. The schema already defines types and ranges, so the description adds meaningful context for the default tree behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Terminate a process') and the resource (a process and its discovered child tree). This distinguishes it from sibling tools like shell_terminate, which deals with shell sessions, and process_list/process_wait which are non-destructive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it terminates a process and by default its child tree, and explicitly notes that the VM remains locked and instructs to call vm_unlock when finished. While it does not explicitly mention alternatives ('use this instead of ...'), it gives practical usage guidance for a destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds critical non-obvious behavior: the VM stays locked after the call and the agent must explicitly invoke vm_unlock. This goes well beyond the structured annotations and is valuable for correct orchestration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences. The core purpose is front-loaded, and the lock-handling caveat is appended without verbosity. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a straightforward list operation: it identifies the platform (Windows 98), the purpose, and a critical side-effect. It does not describe the return format (e.g., process names, PIDs), but for a simple list tool and with no output schema, this is a minor gap rather than a fundamental incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description adds no parameter-specific details, but none are needed. The schema already fully covers the parameter space with an empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'Windows 98 processes', making the tool's function immediately obvious. It is distinct from sibling tools like process_kill and process_wait, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context by stating the VM remains locked and instructing to call vm_unlock when finished. It does not explicitly name alternatives or exclusions, but this is not necessary for a simple list operation; the lock-unlock guidance is practical and directly applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses important behaviors: the boot order change is 'persistent', the VM 'must be stopped' (fails otherwise), and the VM 'remains locked by this session; call vm_unlock when finished.' These add significant operational context not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main action. No filler or redundant information. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the core purpose, precondition, and side effects. It does not detail error handling or return values, but these are not essential given the tool's simplicity and the presence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly maps the 'device' parameter to 'disk, cdrom, or network,' which aligns with the enum in the schema. It does not mention vm_id, but the schema pattern already defines its format. Given 0% schema description coverage, the description partially compensates by explaining the allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set persistent QEMU boot order to disk, cdrom, or network.' It uses a specific verb ('set') and resource ('QEMU boot order'), and the three options distinguish it from siblings like qemu_media_mount or qemu_vm_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit preconditions: 'The VM must be stopped' and a required follow-up action: 'call vm_unlock when finished.' This gives clear context for when and how to use the tool, though it does not mention alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint. The description adds significant non-annotation behavioral context: the VM lock side-effect and the need to unlock. It also clarifies bounded output and long-polling behavior. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: the first front-loads the core action and key modifiers; the second adds a necessary caution. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with strong annotations, the description covers the essential behavior, the locking side-effect, and parameter hints. It omits return format and error cases, but given the tool's simplicity and the annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description maps all four parameters conceptually: 'after a cursor' to after_cursor, 'bounded output' to max_bytes, 'long-polling' to wait_ms, and 'this session' to session_id. This compensates for the lack of schema descriptions, though it does not detail parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Read' with a clear resource ('output after a cursor from an interactive shell'). It adds scope modifiers ('bounded', 'optionally long-polling') and is easily distinguished from siblings like shell_write, shell_terminate, and shell_close.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies usage after interacting with a shell session and includes a critical usage caveat: VM remains locked, so call vm_unlock when finished. It does not explicitly name alternatives or exclusions, but the context is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the annotations: 'VM remains locked by this session; call vm_unlock when finished.' This discloses a key behavioral trait (the lock state) that annotations (readOnlyHint, destructiveHint) do not cover. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the primary purpose, followed by a critical locking note. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, output-schema-less tool with strong annotations, the description is complete. It states what it does, why (filesystem browsing), and the VM lock context. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter semantics needed, and the description doesn't attempt to describe any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List available Windows drive roots for filesystem browsing.' The verb 'List' and resource 'Windows drive roots' are specific, and the purpose 'filesystem browsing' distinguishes it from sibling tools like fs_list (which lists directory contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool ('for filesystem browsing') but does not explicitly compare it to alternatives like fs_list or state when not to use it. The lock context implies a prerequisite (VM is locked) but that's more behavioral than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait beyond annotations: the VM remains locked after unselecting, and the user must call vm_unlock. This is important state-management context that annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that convey the action, consequence, and next step without any redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, output-schema-less tool, the description fully explains what happens and what to do next. No gaps remain for the agent to discover behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema requires no documentation. Per the rubric, a baseline of 4 is appropriate since no parameter description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('clear') with a specific resource ('this session's managed QEMU VM selection'), making it distinct from sibling tools like qemu_vm_select and vm_unlock. It clearly states the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for clearing the current selection without releasing the lock, and it explicitly directs to call vm_unlock when finished. This provides a clear sequence, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses a significant behavioral trait: the VM remains locked by this session and requires vm_unlock. This is not captured by the annotations and is essential for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, then the lock caveat. No redundant information; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and no output schema, the description fully covers the tool's purpose and the necessary side-effect behavior (lock state and unlock requirement). No missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description does not need to add parameter details; the baseline for a zero-parameter tool is satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Read') and specific resources ('guest operating-system, code-page, display, and build information'). It distinguishes itself from sibling tools about system control (reboot/shutdown) and status checks by focusing on detailed read-only guest information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool (when needing guest system information) and includes a critical follow-up instruction ('call vm_unlock when finished'). However, it does not explicitly mention alternatives or exclusions, though the lock caveat strongly guides correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotent, non-read-only, non-destructive), the description discloses that the VM remains locked by the session and requires explicit unlock. This adds important stateful behavior context not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and each sentence contributes meaning. No extraneous information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers purpose, usage context, and required follow-up. Annotations already address safety and idempotency, making the description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter-specific details, but none are needed. Baseline 4 for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Explicitly acquire the exclusive VM lease' with a specific verb and resource, clearly identifying the tool's function. It also distinguishes from sibling vm_unlock by emphasizing the explicit acquisition and pointing to the release action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Most operational tools acquire it automatically', which indicates when not to use this tool (when relying on automatic acquisition). It also instructs to call vm_unlock when finished, providing clear follow-up guidance and effective use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![windows98-mcp MCP server](https://glama.ai/mcp/servers/ido-pluto/windows98-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ido-pluto/windows98-mcp)

Score Badge

Copy to your README.md:

[![windows98-mcp MCP server](https://glama.ai/mcp/servers/ido-pluto/windows98-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ido-pluto/windows98-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ido-pluto/windows98-mcp'

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