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.7.0
Disambiguation2/5
Several tool pairs have heavily overlapping purposes: qemu_keyboard_type/keyboard_type, qemu_mouse_click/mouse_click, qemu_screen_capture/screen_capture, and vm_list/qemu_vm_list. The QMP vs guest-agent distinction is documented, but with 85 tools an agent can easily select the wrong one, especially when both versions of an action exist for the same nominal target.
Naming Consistency4/5
The overwhelming majority of tools follow a clear object-prefix + action pattern using snake_case, such as qemu_vm_*, qemu_media_*, shell_*, mouse_*, window_*, and fs_*. A few outliers like show_message, agent_diagnostics, input_batch, and qemu_doctor break the pattern, but naming is generally predictable and category-scoped.
Tool Count1/5
85 tools is far beyond what an agent can cleanly reason about, and the rubric explicitly treats 50+ as an extreme mismatch. The server tries to cover VM lifecycle, media, snapshots, files, processes, shells, input, clipboard, windows, and transfers all in one namespace, resulting in severe tool-surface bloat.
Completeness5/5
The tool set covers the Windows 98/QEMU domain unusually well: full VM lifecycle with trash/recovery, media and snapshot management, filesystem and process access, interactive shell handling, input and clipboard control, window management, file transfer, and diagnostics. There are no obvious dead ends or critical missing operations for the stated purpose.
Average 3.9/5 across 85 of 85 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 36 commits in the last 12 weeks
- Last stable release on August 20, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply the fact that this is not read-only, not idempotent, and not marked destructive, but the description adds little behavioral detail beyond that. It does not state whether the VM must already be selected/managed, what side effects arbitrary QMP commands may have, or what the response contains; 'broker-owned endpoint' is unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant phrases, and the execution verb is front-loaded. However, 'advanced' and 'broker-owned' add jargon without clarity, so it is not a perfect concise description.
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 sparse annotations, the description needs to explain return behavior, prerequisites, and relationship to sibling tools; it does none of these. A tool that can run arbitrary QMP commands is high-risk and needs more context than this.
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 mentions none of the parameters. An agent gets no help understanding the expected QMP command format, how to pass arguments, or how vm_id relates to the managed VM.
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?
Identifies a specific action ('Run') against a precise resource ('QMP endpoint of a managed VM'), and the QMP/HMP distinction separates it from qemu_hmp_command. However, the qualifier 'advanced' is vague and no sibling is named, so it does not fully disambiguate from overly similar QMP-related tools.
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 rather than qemu_hmp_command, qemu_vm_command_preview, or qemu_doctor. The only hint is the word 'advanced,' which does not establish selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all non-informative defaults ('readOnlyHint': false, 'destructiveHint': false, 'idempotentHint': false), so the description carries the full disclosure burden. It only says 'Run' and adds no detail about side effects, output format, error behavior, or risks of executing arbitrary HMP commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and readable, though the terseness contributes to the lack of operational guidance.
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 free-form command execution tool with no output schema and no meaningful annotations, this description is too thin. It leaves unresolved the key questions of what output to expect, what VM context applies, and how this differs from qemu_qmp_execute.
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 must compensate for the parameters, but it only hints that 'command' uses HMP syntax. It does not explain vm_id, command constraints, output, or interaction between the two parameters.
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 states a specific action ('Run') and a resource ('HMP command through QMP human-monitor-command'), making the core function clear. The word 'advanced' is somewhat vague, but the primary purpose is still identifiable.
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?
There is no guidance on when to use this tool versus alternatives such as qemu_qmp_execute or qemu_vm_command_preview. It also does not mention prerequisites like a running VM or the difference between HMP and QMP command paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond the bare operation — no mention of whether an existing VM with the same ID gets overwritten, whether the restore is reversible, or what state (stopped or running) the VM is returned in. It does not contradict the annotations, but it contributes no transparency of its own.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single eight-word sentence with zero filler, and the verb and object are front-loaded. For a one-parameter tool this brevity is appropriate, though it borders on under-specification.
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 destructive mutation tool with no output schema, the description leaves essential context unstated: what 'broker trash' is, what restoring entails, and what happens if a VM with the same ID already exists. An agent can guess the core operation but cannot anticipate consequences, which matters for a destructive 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?
Schema description coverage is 0%, so the description carries the burden of explaining the vm_id parameter, and it does not even mention it. The well-named parameter and its pattern regex in the schema do some work, but the tool description adds zero semantic value for the parameter, failing to compensate for the coverage gap.
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 uses a specific verb ('Restore'), a clear resource ('managed VM'), and a precise source ('broker trash'), so an agent can identify the operation. It is implicitly distinguishable from siblings like qemu_snapshot_restore (snapshot vs. VM) and qemu_vm_delete, though 'broker trash' is unexplained domain jargon that prevents a 5.
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 use this tool versus alternatives. It does not state that the VM must already reside in the trash, does not contrast with qemu_vm_trash_list or qemu_vm_trash_empty, and offers no preconditions or exclusions. An agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide little behavioral context (readOnlyHint=false, idempotentHint=false), so the description carries the burden. It adds that the text goes to the active QEMU display and is QEMU-monitor-compatible, but it does not disclose prerequisites, side effects, or whether the VM must be running. There is no contradiction with 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 focused sentence with no filler or redundant clauses. It front-loads the core action and target immediately, making it easy for an agent to parse quickly.
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 two-parameter input-injection tool, this is minimally viable: the schema covers the parameters and the description states the action. However, it lacks routing guidance, behavioral caveats, and a clear statement of when the active QEMU display is available, which leaves meaningful gaps for an agent selecting among many input sibling tools.
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 parameters. The parameter names 'vm_id' and 'text' are self-explanatory enough to avoid a 1, but the description does not clarify text format/encoding limits or how vm_id maps to the active display. The description should compensate for the schema gap and does not.
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 a specific verb ('Type'), the resource ('basic QEMU monitor-compatible text'), and the target ('the active QEMU display'). It is distinguishable from mouse/command tools, though it does not explicitly differentiate itself from sibling tools like qemu_keyboard_key or keyboard_type.
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 explicit guidance is given about when to use this tool versus alternatives such as qemu_keyboard_key, keyboard_type, or qemu_hmp_command. The phrase 'basic text' implies a plain-text use case, but there are no stated preconditions, exclusions, or direction to a more appropriate sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds scope by specifying 'managed QEMU process and QMP metrics,' but it does not disclose behavior for unmanaged VM IDs, the exact metric set returned, or failure modes. This is comparable to other read-only tools where annotations do the heavy lifting.
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 eight-word sentence, front-loaded with the verb 'Read.' Every word earns its place, and there is no redundant restatement of the tool name or title.
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 single parameter, read-only annotations, and lack of an output schema, the description is near the minimum viable level. However, it leaves ambiguity about what 'QMP metrics' actually includes, whether the VM must be pre-selected, and how this tool relates to qemu_vm_status. An agent can probably call it, but may be guessing about the return contents and exact preconditions.
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 compensate for the single vm_id parameter, but it does not explain what values are valid, how the VM is identified, or whether it must be a currently selected/managed VM. The parameter name and schema pattern provide limited self-evident meaning, so this is slightly above a complete absence of semantic guidance.
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 uses a specific verb ('Read') and names its resource: managed QEMU process and QMP metrics. It is clear enough to understand the general purpose, but it does not explicitly differentiate itself from related siblings like qemu_vm_status or qemu_doctor.
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 gives no guidance on when to use this tool versus qemu_vm_status, qemu_doctor, process_list, or system_info. It only states the action, leaving the agent to infer the selection criteria. There are no exclusions, alternatives, or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=false, and the description adds that QMP and the profile's guest TCP network are set up as part of the start. It does not disclose behaviors such as failure when already running, asynchronous completion, or the resulting VM state beyond '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?
The description is a single sentence with the action and resource front-loaded. It contains no filler, redundancy, or tangential detail, earning its place entirely.
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 one-parameter start operation, the core invocation is clear: pass a vm_id and the VM will be started with QMP and its profile network. However, prerequisites, lifecycle relationship to sibling qemu_vm_* tools, and outcome/return behavior are missing, leaving some ambiguity.
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 provides the property name and pattern, but the description adds no meaning beyond what the parameter name already implies.
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 uses the specific verb 'Start' with the resource 'managed QEMU VM' and adds the details 'QMP' and 'profile's guest TCP network' to characterize the launch mode. It clearly reads as powering on an existing managed VM rather than creating or configuring one, though it does not explicitly name sibling tools.
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 when-to-use, when-not-to-use, or alternative tool guidance is provided. The agent is left to infer the difference between this and qemu_vm_create, qemu_vm_restart, qemu_vm_shutdown, and the other qemu_vm_* lifecycle tools based only on the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds value by specifying what state is inspected (process, QMP, guest TCP transport), which is useful context beyond annotations. There is no contradiction, but no deeper traits such as auth requirements or failure behavior are 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?
A single 16-word sentence that is front-loaded with the verb and names the exact scopes of the read. Every word earns its place; there is no filler and no repetition of schema or annotation 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 tool is low-complexity: one required parameter, and the safety profile is fully covered by annotations. The description names the three state domains read, giving the agent a reasonable expectation of what the result will contain. The absence of an output schema means the return structure is unstated, but for a simple read-only status tool that 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 must compensate, but it only implies that vm_id identifies a managed QEMU VM. It does not explain how to obtain vm_id, what values are valid beyond the regex pattern, or the meaning of the pattern constraints. The parameter name is self-evident, yet the description adds almost nothing on top of it.
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 uses a specific verb ('Read') and identifies the exact resource ('one managed QEMU VM') as well as the specific state domains inspected (process, QMP, guest TCP transport). This clearly conveys function and scope, implicitly distinguishing it from list-oriented siblings like qemu_vm_list. However, it never explicitly names a sibling, so differentiation is left to inference.
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?
There is no guidance on when to use this tool versus closely related siblings such as vm_status, qemu_vm_metrics, qemu_doctor, or qemu_vm_list. The description states only what the tool does, with no conditions, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important non-obvious side effect: the VM remains locked by this session and the caller must call vm_unlock when finished. This goes beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) and gives the agent critical behavioral context. 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 short sentences with the primary action front-loaded and the lock/unlock obligation placed immediately after. Every sentence contributes useful information with no redundancy or restatement of the tool name.
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 mkdir operation, the description covers the essential action and the critical lock/unlock contract. However, with no output schema and low parameter coverage, it leaves return behavior, error cases, and the effect of recursive creating to inference. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only vm_name described in the schema. The phrase 'guest directory' hints that path refers to a filesystem path inside the guest, but the recursive boolean and path semantics are not meaningfully explained. Since coverage is low, the description needed to compensate more than it does.
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 opens with a specific verb and object, 'Create a guest directory,' which clearly identifies the operation and target. It does not name or compare against sibling filesystem tools like fs_move or fs_delete, so it stops short of full differentiation, but the purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use fs_mkdir instead of related tools such as directory_push, fs_move, or fs_delete. The only additional context is about the VM lock, which is a postcondition rather than a selection criterion for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds modest value by clarifying that no VM state changes occur and that the output is the exact managed command, but it does not go beyond the safety profile already established 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?
The description is a single, tightly worded sentence with no filler. It front-loads the core purpose ('Preview') and includes the key safety qualifier immediately, earning its place with every word.
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 12 parameters, nested objects, no parameter descriptions, and no output schema, the one-sentence description leaves major gaps. It does not explain what 'managed QEMU command' means, how parameters relate to the generated command, or what the preview output looks like, making it insufficient for confident invocation.
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 none of the 12 parameters are described anywhere. The description provides no meaning for cpus, memory, overrides, profile, acceleration, or other fields, forcing the agent to guess despite the large, nested parameter surface.
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 ('Preview') and a clear resource ('the exact managed QEMU command'), immediately distinguishing this from state-changing siblings like qemu_vm_create or qemu_vm_update. The phrase 'without changing VM state' reinforces its read-only purpose.
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: use this when you want to see what managed QEMU command would be used without mutating VM state. However, it does not explicitly name alternatives or state when not to use it, leaving the routing decision partially to 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?
Beyond annotations, the description reveals a meaningful behavioral trait: the session keeps the VM locked and requires a subsequent vm_unlock call. This is exactly the kind of side-effect/state information an agent needs. It doesn't cover invalid-parameter behavior or effects of conflicting virtual_key/scan_code values, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, with the primary purpose first and the state warning second. Every clause 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?
For a five-parameter input tool with no output schema and low schema coverage, the description leaves too much to inference: mutability/exclusivity of virtual_key and scan_code, meaning of extended, and how action values map to event behavior. The lock warning is helpful but not sufficient.
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 only 20%, and the description adds little parameter-level detail. It mentions virtual-key or scan-code, which maps to virtual_key/scan_code, but leaves action, extended, and the relationship between virtual_key and scan_code unexplained.
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 identifies a specific action ('Send...input event') and resource ('Win32 virtual-key or scan-code'), making the tool's function clear. It doesn't explicitly name sibling tools like keyboard_key or qemu_keyboard_key, but 'low-level Win32' sets it apart from higher-level keyboard inputs.
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 gives operational context: the VM stays locked by this session and vm_unlock must be called when done, which tells the agent when to pair this tool with vm_unlock. However, it gives no explicit guidance on choosing this over sibling keyboard_key/keyboard_hotkey/input_batch, or when low-level keycodes are required.
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?
Adds meaningful behavioral context beyond the annotations by disclosing that the VM remains locked by this session and instructing the agent to call vm_unlock when finished. The annotations already cover idempotency and non-destructiveness, and the readOnlyHint=false aligns with the description's write-like mouse movement. No contradiction found.
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?
A single compact sentence front-loads the core action and appends the essential lock caveat. There is no filler, restatement, or unnecessary detail; every word contributes to the agent's understanding.
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-movement tool, the action and post-condition are clear, and the annotations cover safety and idempotency. The main gaps are the undocumented duration_ms parameter and the lack of sibling differentiation, but required parameters are in the schema and the operation is straightforward.
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 echoes the x/y meaning ('zero-based physical pixel coordinate') but adds little beyond the schema's existing descriptions. It says nothing about vm_name and, more importantly, leaves the optional duration_ms parameter completely unexplained, even though the schema provides no description for it. With only 75% schema coverage, the description does not adequately compensate.
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?
States a concrete action ('Move the mouse') with a precise target ('exact zero-based physical pixel coordinate'). It clearly distinguishes what it does from read-style tools like mouse_position, but it does not differentiate itself from the sibling qemu_mouse_move or explain its relationship to mouse_drag/mouse_click.
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 only usage guidance is the lock lifecycle: 'VM remains locked by this session; call vm_unlock when finished.' This is a useful post-condition, but it does not say when to prefer this tool over qemu_mouse_move, mouse_drag, or other input tools, nor does it state any exclusions or 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Check' wording aligns with those. The description adds useful behavioral context by specifying the exact dimensions checked, especially the network connectivity check via 'stable guest-to-host TCP route,' which goes beyond the generic annotation profile.
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 efficient sentence that front-loads the action and lists the checked items in a clear, scannable sequence. Every word contributes meaning; there is no fluff 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?
For a read-only diagnostic tool with no output schema, the description adequately conveys what is checked but does not explain what the tool returns, how results are presented, or how parameters alter the diagnostic scope. The annotations cover safety, and all parameters are optional, so an agent could invoke it correctly, but return-value expectations remain unspecified.
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 mention any of the three optional parameters (profile, qemu_binary, acceleration) or how they influence the check. Since there are no parameter descriptions in the schema, this is a significant gap the description needed to fill but did 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 opens with a clear verb, 'Check,' and names a distinct resource: the local QEMU host. It also enumerates specific diagnostic areas — configured binary, managed VM root, accelerator policy, and guest-to-host TCP route — which separates it from sibling status and listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like qemu_vm_status, system_info, or agent_diagnostics. It implies a diagnostic/health-check purpose from the verb 'Check' and the title, but it does not state when this tool is preferable or when another tool should 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?
Annotations only signal destructiveness; the description adds that deletion is recoverable and enforces a three-entry retention policy, which is useful beyond the structured data. It does not explain what force does, but the core non-obvious behavior is 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?
One compact sentence leads with the action and target, then appends the key retention constraint. Every word contributes; no filler or boilerplate.
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 two-parameter destructive tool without an output schema, the core effect and retention rule are stated clearly. However, the force parameter is left entirely unexplained, leaving a meaningful gap in knowing what happens when force is set to true.
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 mentions no parameters at all. vm_id is inferable from the tool name, but force has no documented semantics (e.g., whether it bypasses trash or overrides a running VM), so the description fails to 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?
Description uses a specific verb ('Move') and target ('managed QEMU VM' to 'recoverable broker trash'), clarifying that this is a soft-delete rather than permanent removal. The retention limit also distinguishes it from related trash-management siblings.
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 explicit when-to-use or alternative routing appears; the description never names qemu_vm_force_stop, qemu_vm_trash_empty, or qemu_vm_restore as alternatives. The agent must infer that this is the deletion/soft-delete path from 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 indicate readOnly, non-destructive, and idempotent behavior. The description adds valuable context beyond annotations: the wait is bounded, the VM lock persists for the session, and the agent should call vm_unlock afterward. This is relevant operational behavior not captured in 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?
Two concise sentences with no filler. The core function is front-loaded, and the lock-related follow-up instruction is placed immediately after. 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 description covers the core wait action and lock handling, but with no output schema, it leaves timeout behavior and edge cases (e.g., what happens when the bounded period expires or the process already exited) to inference. It is adequate for basic use but not fully 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 only 33%: vm_name is documented, but process_id and timeout_ms are not. The description does not explain these parameters, and 'bounded period' only weakly hints at timeout_ms. It fails to compensate for the schema's low coverage.
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 states a specific action ('Wait for a process to exit') and a resource, clearly distinguishing it from process_kill. However, it does not explicitly contrast it with vm_wait or other wait-type siblings, so sibling differentiation is only implicit.
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 clear usage context: wait for a bounded period and remember that the VM remains locked, requiring vm_unlock when finished. It does not, however, state when to choose this tool over alternatives like vm_wait or process_kill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, so the mutating nature is covered. The description adds that the event is sent via QMP and usable regardless of guest-agent startup, but it does not disclose side effects, permissions, or how the action values map to key-down/up/press behavior beyond the schema enum.
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 front-loads the action and resource, then adds a useful timing qualifier without 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 three-parameter tool without an output schema, the description is mostly serviceable, but it leaves an agent to infer valid QMP qcode key values and the precise meaning of the action parameter. It also does not explicitly differentiate from qemu_keyboard_type, so the guidance is not fully 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%, so the description must compensate for undocumented parameters. It clarifies that 'key' is a QMP qcode, but it does not explain the 'action' enum semantics, the default 'press' behavior, or the vm_id requirement beyond its name and schema pattern.
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 uses a specific verb ('Send') and identifies a distinct resource ('QMP qcode key event'), clearly stating what the tool does. It also adds lifecycle context ('before or after guest-agent startup'), which helps separate it from text-typing or mouse tools, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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' gives clear timing context and implies the event is sent via QMP rather than relying on the guest agent. However, it does not explicitly state when not to use this tool or name alternatives like qemu_keyboard_type for text entry, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All annotations are false, so they carry no real information and the description bears the disclosure burden. The description does add context beyond annotations: the operation travels over QMP, coordinates are absolute, and the target VM must already be running. It does not, however, disclose the primary side-effect (injecting an input event that visibly moves the guest cursor) or any error/edge behavior. Nothing in the description contradicts 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?
A single nine-word sentence that leads with the verb and packs the three essential qualifiers ('absolute', 'QMP', 'running') with zero filler. Every word earns its place and the most decision-relevant information is 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?
For a three-parameter tool with no output schema and neutral annotations, the description covers the essentials but leaves two gaps an agent must resolve on its own: how the 0-65535 absolute coordinate space maps to the actual guest display, and which sibling should be chosen instead (qemu_mouse_click versus this move tool, or the generic mouse_move). These gaps are non-trivial given the sibling list contains nine mouse-related 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?
Schema description coverage is 67%: x and y are documented as 'Zero-based physical screen coordinate' with 0-65535 bounds, but vm_id has no description in the schema. The description adds the 'absolute' qualifier, which clarifies the coordinate semantics beyond what the schema states, but it does not explain how the 0-65535 space maps to the guest display, and it contributes nothing for the undocumented vm_id.
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 uses a specific verb ('Send') with a clear resource ('absolute QMP mouse coordinates to a running QEMU VM'), stating exactly what the tool does. The 'absolute' and 'QMP' qualifiers meaningfully differentiate it from the generic mouse_move sibling, though it does not explicitly distinguish itself from qemu_mouse_click, which is the closest competing sibling.
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 phrase 'to a running QEMU VM' implies a prerequisite (the VM must be running before this tool is valid), and 'absolute' implies it is not for relative pointer movements. However, the description offers no explicit when-to-use vs. when-not-to-use guidance and names no alternatives, leaving the agent to infer placement among nine mouse-related siblings like qemu_mouse_click, mouse_drag, and mouse_scroll.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive, and the description adds a useful timing constraint rather than contradicting them. However, it does not explain behavior if the controller has already started, whether the VM must exist, or what the capture output looks like, so it adds only modest 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?
The description is a single, front-loaded sentence with no filler or redundancy. It communicates the essential verb, resource, and timing condition efficiently.
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 one-parameter, read-only capture tool, the core information is present and the annotations cover the safety profile. The main gaps are the undefined 'Windows controller' term, the lack of any return-format hint, and no mention of failure modes; with no output schema, the description must carry more of this burden.
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%, but the description never mentions vm_id or explains that it identifies the target VM. The parameter name and pattern provide some inference, but with low schema coverage the description should explicitly tie vm_id to the framebuffer being captured; it does not.
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 states a specific action ('capture') and resource ('QEMU framebuffer'), with a temporal qualifier that distinguishes it from generic siblings like screen_capture or window_capture. However, the phrase 'Windows controller' is not defined and no sibling is explicitly contrasted, so it stops short of a 5.
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: this tool is for capturing the QEMU framebuffer before the Windows controller has started, which implies a pre-boot or early-boot scenario. It does not explicitly name alternatives or say when not to use it, but the timing condition is concrete enough to guide selection over generic screen capture tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, covering the mutation risk. The description adds useful context about the snapshot type and VM state requirement, but does not disclose what happens to the current disk state or that the restore is irreversible. With annotations covering the core safety profile, the extra context is moderate.
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?
A single sentence with no filler. The verb, object, and precondition are front-loaded, making the core information instantly accessible. Nothing extraneous is included.
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 two-parameter destructive operation, the description states the action and precondition. However, given its destructive nature, the absence of any parameter details and lack of output expectation leaves meaningful gaps. The description is adequate but not rich enough to fully guide an agent without additional schema support.
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 elaborate on either parameter. 'named' hints at the 'name' parameter and 'VM' implies 'vm_id', but there is no explanation of value formats, constraints, or which snapshot is targeted. The description fails to compensate for the complete lack of schema documentation.
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 action ('Restore'), the resource ('named qcow2 internal disk snapshot'), and a key precondition ('while the VM is stopped'). This distinguishes it from snapshot creation/deletion/list tools, though it does not explicitly name sibling alternatives like qemu_vm_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 provides clear context about when the tool is appropriate: the VM must be stopped. This is a meaningful usage condition. However, it does not explicitly mention alternatives or state when not to use this tool in favor of qemu_vm_restore or snapshot deletion.
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 provide destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds value beyond those by disclosing a non-obvious behavioral trait: 'VM remains locked by this session; call vm_unlock when finished.' This tells the agent the session's lifecycle outlives the call itself and requires a follow-up action, which the annotations alone would 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 with zero filler. The primary action is front-loaded in the first sentence, and the critical follow-up (vm_unlock) is delivered in the second. 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?
For a destructive two-parameter tool with annotations present, the description covers the core action and the essential lock-lifecycle warning. The gaps are the undocumented session_id parameter semantics and the missing distinction from shell_close. No output schema exists, so return behavior is unaddressed, but this is a minor concern for a terminate-style 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?
Schema coverage is only 50%: vm_name has a description, but session_id has only minLength: 1 with no semantic meaning. The description does not compensate by explaining what session_id is or where it comes from (e.g., the value returned by shell_start). An agent cannot know how to obtain or validate session_id from this definition.
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 states a specific verb and resource: 'Terminate a running interactive shell session.' This clearly identifies the operation. However, it doesn't differentiate from the sibling shell_close, which plausibly performs a similar shutdown action, leaving the agent to guess which one to pick.
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 — terminating a session that is no longer needed — and gives a clear follow-up instruction to call vm_unlock. But it never states when to prefer this over shell_close, or any conditions that would exclude using it. Usage is implied by the lifecycle narrative rather than explicitly specified.
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 non-obvious behavior beyond that: the guest cannot reconnect until the VM is started externally, and the VM remains locked by the current session, requiring vm_unlock. This is valuable behavioral context not present 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 three short sentences with the primary action front-loaded, followed by essential caveats. There is no fluff, no repetition of schema defaults, and every sentence adds value.
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 critical lock lifecycle and post-shutdown workflow well. However, for a destructive tool with three parameters, it omits the meaning of force and delay_seconds, and it does not describe expected output or failure states. Given no output schema, there are meaningful 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?
Only vm_name is described in the schema (33% coverage). The other two parameters, force and delay_seconds, have only type/default/range information and are not mentioned in the description. An agent cannot infer their semantic meaning from either source.
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 states a concrete action ('Shut down Windows 98') and adds distinguishing context: the guest cannot reconnect and the VM remains locked until an external start. It does not explicitly differentiate from sibling tools like system_reboot or qemu_vm_shutdown, so it is clear but not fully differentiated.
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 intended workflow is implied: shut down the guest, then call vm_unlock when finished. However, there is no explicit guidance about when to prefer this tool over alternatives such as system_reboot, qemu_vm_shutdown, or qemu_vm_force_stop, nor 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?
With only generic annotations, the description carries the behavioral burden. It clearly discloses both key side effects: the eject happens 'now when running' and an empty drive is persisted 'for future starts.' It does not mention error cases or whether media files remain on disk, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler. The operation is front-loaded, and both immediate and persisted effects earn their place in the sentence.
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 side-effect tool, the description covers what happens now and on future starts, leaving little ambiguity about the tool's effect. No output schema exists, but explaining return values is unnecessary for a simple eject action.
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 sole parameter vm_id has no schema description (0% coverage), and the description does not mention the target VM or explain how vm_id relates to the eject operation. While the parameter name is fairly self-explanatory, the description adds no semantic value beyond the schema.
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 opens with a specific verb ('Eject') and resource ('managed CD-ROM'), then adds detail about immediate and future behavior. It distinguishes ejecting from deleting by noting the drive persists as empty for future starts, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 eject the CD-ROM now and ensure the drive remains empty for future starts. It does not explicitly compare against alternatives like qemu_media_mount or qemu_media_delete, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation destructive, and the description adds the meaningful detail that the stop is graceful before restart. However, it does not disclose consequences such as downtime, loss of unsaved guest state, or behavior if the VM is not running.
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?
One concise, front-loaded sentence with no filler; every word contributes to scope and method.
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?
Adequate for a simple one-parameter restart tool, but with no output schema and no mention of prerequisites, return behavior, or failure conditions, an agent cannot fully anticipate edge cases.
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 vm_id beyond referring to the managed VM. The parameter name and pattern offer some guidance, but 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?
States a specific verb ('restart') and resource ('managed QEMU VM'), and clarifies the method ('gracefully stop then restart'), distinguishing it from sibling tools like force_stop, shutdown, or start.
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 graceful restart semantics imply when it should be used, but it does not explicitly contrast with alternatives such as qemu_vm_force_stop or state prerequisites like 'VM must be running'.
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 destructive=true, readOnly=false, and idempotent=false. The description adds meaningful behavioral context by disclosing that the session locks the VM and that vm_unlock is required afterward, which is beyond what the annotations alone provide. There is no contradiction with 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 fully capture the action and the key side-effect. The core purpose is front-loaded, and the critical unlock instruction is placed immediately after. No filler is present.
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 start-session behavior and the lock-related requirement, but it omits how the 'command' parameter should be used and how the returned session ID connects to the session-based sibling tools. Given no output schema, a bit more detail about the expected response and follow-up workflow would make it more 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?
Schema description coverage is only 33%, and the tool description adds essentially no parameter-level meaning. The 'command' and 'cwd' parameters are left undocumented in the schema, and the description does not clarify what command format is expected or what cwd controls. This is a significant gap for an agent trying to invoke the tool correctly.
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?
States a specific verb and resource: 'Start an interactive redirected-pipe shell session' and notes that it returns a session ID. This clearly differentiates it from sibling tools like shell_exec, shell_read, and shell_write, even without naming them explicitly.
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 gives an important lifecycle instruction: the VM remains locked by this session, and vm_unlock must be called when finished. However, it does not explicitly state when to choose this tool over a one-shot shell_exec, nor how it relates to shell_read/shell_write.
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 important behavioral context beyond the annotations: the VM remains locked by this session and vm_unlock must be called afterward. This is a critical side effect not captured by destructiveHint or readOnlyHint, and 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 short sentences with no filler. The core action is front-loaded, and the essential lock/unlock warning immediately follows. Every sentence carries necessary 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 destructive, no-output-schema tool, the description covers the target, the operation, and the significant VM-lock side effect. It omits explicit semantics for recursive deletion of non-empty directories, but this is partially inferable from the recursive parameter defaults and is a relatively 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 only 33%, with path and recursive lacking descriptions. The tool description adds no parameter-level detail; it loosely maps 'file or directory' to path and 'VM' to vm_name but says nothing about the recursive parameter or its behavior, which the schema also fails to explain.
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 ('Delete') and a clear resource ('a guest file or directory'), which immediately distinguishes it from sibling fs tools like fs_move, fs_list, and fs_stat. Scoping the operation to the guest also prevents confusion with host filesystem operations.
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?
There is no guidance about when to choose this tool over alternatives, nor any mention of conditions that should or should not trigger it. The only actionable note is a post-condition about unlocking the VM, which is not usage-selection 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 meaningful behavioral context beyond the annotations: it discloses that the VM remains locked by this session and that the caller must unlock it. This is not captured by readOnlyHint, destructiveHint, or idempotentHint, and 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?
Two sentences deliver the core action, the coordinate fallback behavior, and the lock responsibility with no wasted words. The most important usage constraint is included succinctly.
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 is reasonably complete for a simple click operation, especially the lock-handling note, but it leaves out return behavior, error conditions, and any rationale for choosing this over qemu_mouse_click. Given the absence of an output schema and the number of parameters, some additional context would help.
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 covers x, y, and vm_name with descriptions, so the description's clarification that omitted coordinates use the current pointer position adds value. However, button, click_count, and interval_ms are not explained beyond defaults/enums, and the description does not compensate for the 50% schema coverage gap.
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 action: click at supplied coordinates, or at the current pointer position when coordinates are omitted. It is specific about the resource and behavior, though it does not differentiate from the closely related sibling qemu_mouse_click.
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 within a locked VM session by noting that the VM remains locked and that vm_unlock should be called afterward. However, it does not explicitly state when to prefer this over alternatives such as mouse_down/mouse_up or qemu_mouse_click.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation via readOnlyHint=false and idempotentHint=false. The description adds useful behavioral detail: the operation is performed immediately on a running VM and persists across reboots. However, it does not disclose side effects such as replacing an already-mounted ISO, error behavior, or prerequisites beyond the VM running.
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 wasted words. It states the action, timing, and persistence in one compact statement, making it easy for an agent to parse quickly.
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 tool with two required parameters and zero parameter descriptions, this description is too thin to fully support correct invocation. It explains what the tool does, but not how to supply vm_id or media_id, what happens if media is already attached, or what the response indicates; there is also no output schema to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the undocumented vm_id and media_id parameters. It does not explicitly explain either parameter; only the phrase 'managed ISO' hints that media_id refers to the ISO, and context implies vm_id is the target VM. This leaves parameter meaning and valid value discovery mostly to inference.
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 has a specific verb-resource pair, 'Mount a managed ISO', and adds temporal scope ('now when the VM is running') plus a persistence guarantee ('persist it for future starts'). This clearly distinguishes it from sibling operations like qemu_media_eject, qemu_media_delete, and qemu_media_set_boot.
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 usage context: use this when the VM is running and you want the mount to survive future starts. It does not explicitly name alternatives or give when-not-to-use guidance, but the context is strong enough to route an agent to the right operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds a useful behavioral constraint: paths are broker-local and remote upload is unsupported. It does not clarify what makes the operation destructive (e.g., overwriting an existing media_id), but annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main action is front-loaded and the caveat follows directly, making it easy for an agent to parse quickly.
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 destructive 3-parameter tool with no output schema, this is incomplete: media_id semantics are absent, destructive edge cases are undisclosed, and there is no guidance on what comes after the copy or how to attach the media. The missing parameter semantics are a significant 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 must explain the parameters. It clarifies source_path only by stating it is broker-local. The required vm_id and the optional media_id are never defined, so an agent cannot know how to name the resulting media or what happens if media_id is omitted.
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 action and object: 'Copy a broker-local .iso image into this VM's managed media directory.' This clearly distinguishes the tool from sibling media operations (mount/eject/delete/list) and from file_push by targeting the managed media directory on the broker side.
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 scopes the source: 'source_path is resolved on the broker host' and warns 'remote media upload is not available yet,' giving an agent clear conditions for when this tool applies. It does not name alternative tools, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile: readOnlyHint, idempotentHint, and non-destructive. The description adds useful context by restricting the scope to stopped VMs and qcow2 internal snapshots, but it does not disclose behavior such as error conditions when the VM is not stopped or what happens if no snapshots exist.
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 compact sentence with no filler or repetition. It front-loads the action and clearly scopes the resource type, which is appropriate for a simple one-parameter list tool.
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 low-complexity tool with one required parameter and strong read-only annotations, the description is mostly sufficient. It states the resource type and scope, though it would be slightly more complete if it noted that the return value is a list of snapshot names/metadata in the absence 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?
Schema description coverage is 0%, and the description does not mention vm_id at all. The schema provides only the name, requirement, and pattern, so the agent must infer that vm_id identifies the target VM. The description should have explicitly linked vm_id to the snapshot listing operation.
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 names a specific verb ('List') and resource ('stopped-VM qcow2 internal snapshots'), making the operation unambiguous. It also distinguishes itself from sibling snapshot-create/restore/delete tools by focusing on listing rather than mutating snapshots.
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 'stopped-VM' qualifier implies the tool is for offline VMs, and the listing action implies it could be used before create/restore/delete operations. However, it does not explicitly state when to choose this tool over alternatives or when it should not be used, such as for running VMs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true, readOnly=false, and idempotent=false. The description adds useful context about the broker-local disk requirement and remote-upload limitation, but it never discloses what destructive side effect may occur—whether the source disk is consumed, moved, or if an existing VM could be affected. This is a meaningful gap beyond what annotations 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 exactly two sentences with no filler. The primary action is front-loaded, and the critical broker-local caveat follows immediately. Every sentence adds distinct value.
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 destructive tool with 13 parameters, nested objects, and no output schema, the description is too sparse. It does not explain what the tool actually returns, whether a VM is created immediately or just defined, how profile and overrides interact, or what the destructive consequence is. Agents calling this tool correctly would need substantially more guidance.
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 of explaining 13 parameters. It only adds meaning for disk_path ('belongs to the broker host; remote-media upload not available'). Parameters like name, cpus, memory, profile, overrides, acceleration, and qemu_binary receive no semantic guidance, leaving the agent to infer their roles from bare schema constraints.
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 combination: 'Import a broker-local disk into a new managed qcow2 QEMU VM.' It clearly distinguishes creation of a VM from disk import versus other VM lifecycle operations like qemu_vm_start or qemu_vm_update. The tool's purpose is immediately obvious and not a tautology of the name.
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 a clear usage context: the disk must currently reside on the broker host, and remote-media upload is explicitly unavailable. However, it does not name alternative tools (e.g., qemu_media_push) or provide explicit when-not-to-use guidance, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state that the tool is not read-only, not idempotent, and not destructive. The description adds some behavioral context by scoping the effect to the session's QEMU panel and distinguishing it from in-guest control. However, it does not disclose what happens to a previous selection, whether the selection persists, or how it affects subsequent qemu_vm_* calls.
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 filler. The first sentence states the core purpose, and the second adds a meaningful scoping boundary between panel-managed VMs and in-guest control. 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?
For a simple one-parameter stateful selection tool, the description is mostly sufficient, but it omits the downstream effect of the recorded selection and does not mention qemu_vm_unselect as the inverse. Since there is no output schema, a brief note about the result or side effect would improve 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 input schema has 0% description coverage, so the tool description must carry semantic weight for vm_id. It partially does by identifying the parameter as the managed QEMU VM to be selected/recorded, but it does not explain where valid vm_id values come from or how they relate to qemu_vm_list. With only one simple parameter, this is adequate but not strong.
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 identifies the action ('Record') and the resource ('managed QEMU VM') within the MCP/Admin session's QEMU panel, making the tool's role reasonably clear. It implicitly differentiates itself from listing, status, and unselect siblings by focusing on setting/recording the current selection, though the verb 'record' is slightly indirect.
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: this tool applies to the Admin session's managed QEMU panel, while in-guest MCP control is explicitly excluded ('In-guest MCP control remains the agent's outbound TCP connection'). It does not explicitly name alternatives like qemu_vm_unselect or state 'use before other qemu_vm_* commands,' but the session-selection context implies when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description does not contradict them. The description adds useful context by noting the VM must be stopped and that the update covers accelerator policy and profile components. However, it does not disclose merge/replace behavior, side effects, or whether the update is applied immediately or requires a subsequent 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?
The description is a single, front-loaded sentence with no filler. It states the action, the precondition, and the scope efficiently, making it easy for an agent to parse quickly.
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 destructive, non-idempotent mutation tool with 12 parameters, nested objects, no output schema, and zero schema-described parameters, the one-sentence description is insufficient. It provides the stopped-VM precondition but omits parameter semantics, return behavior, and operational details needed for reliable use.
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 compensate, but it only hints at 'accelerator policy' and 'profile component'. It does not explain the meaning or usage of the 12 parameters such as cpus, memory, overrides, extra_args, qemu_binary, or architecture. This is a significant gap for an agent trying to invoke the tool correctly.
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 'Update' with a clear resource: 'a stopped managed QEMU VM definition'. It distinguishes this from sibling tools like qemu_vm_create, qemu_vm_start, and qemu_vm_delete by focusing on modifying an existing stopped definition. The phrase 'including accelerator policy and any profile component' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the key precondition 'stopped', which tells the agent when this tool is applicable versus other qemu_vm_* operations. It does not explicitly name alternative tools or say 'use qemu_vm_create for new VMs', but the context is clear enough for appropriate 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?
Annotations already convey destructiveHint and readOnlyHint=false, so the description does not need to restate mutation. It adds valuable context beyond annotations by warning that the VM remains locked by the session and must be unlocked via vm_unlock. This is a meaningful behavioral side effect for an agent to account for after invocation.
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 no wasted words. The primary operation is front-loaded, and the lock-unlock warning is a necessary secondary detail. 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 description covers the core operation and a key side effect, but it is incomplete for a destructive tool with no output schema and low parameter documentation. It does not clarify what happens when overwrite is true or whether the source/destination paths are expected to be guest-absolute paths. The lock warning helps, but the overall picture requires inference.
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 only 25%, with only vm_name described. The description adds little parameter-level meaning: it implies source and destination are guest paths but does not explain path format, overwrite behavior, or the meaning of the overwrite flag. With low schema coverage, the description needed to compensate and did 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 specific action ('Move or rename') and resource ('a guest file or directory'), distinguishing it from sibling tools like fs_delete and fs_mkdir. It is specific enough that an agent can select it for move/rename operations without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or renaming guest files and directories, and adds the important lock-lifecycle instruction to call vm_unlock. However, it does not explicitly mention when not to use it, such as when copying or when operating on host files, nor does it name 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 are sparse (readOnly=false, idempotent=false), so the description carries the behavioral burden. It usefully discloses that pressing order matters, keys are released in reverse order, and the VM remains locked, requiring vm_unlock afterward. This adds meaningful context beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences cover both the core action and the lock lifecycle without wasted words. The behavioral detail is front-loaded, and the unlock instruction follows naturally.
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 explains the action and lock lifecycle, but it omits key name vocabulary, whether the VM must already be locked before calling, and what happens on invalid keys. With no output schema or richer annotations, these gaps leave an agent partially underinformed.
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 only 50%; vm_name is described but keys is not. The phrase 'named keys' adds minimal meaning, but valid key names, modifier syntax, case sensitivity, and how keys map to the ordering behavior are left undocumented. 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 states a specific behavior: press named keys in order and release them in reverse order, and it mentions the VM lock context. This clearly distinguishes it from siblings like keyboard_type (text input) and keyboard_key (single key press) by focusing on ordered hotkey sequences.
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 hotkey combinations and gives a lifecycle instruction ('call vm_unlock when finished'), but it does not explicitly explain when to choose this tool over keyboard_type, keyboard_key, or input_batch. No when-not-to-use guidance or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and non-read-only. The description adds useful context: it is an internal qcow2 snapshot and requires a stopped VM. However, it does not disclose failure behavior, side effects on the disk, or what happens if the VM is running.
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 one tight sentence with no filler. The action ('Create'), object ('named qcow2 internal disk snapshot'), and precondition ('while the VM is stopped') are all front-loaded and directly useful.
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 two-parameter tool, the description captures the essential precondition and resource type. However, with no output schema and minimal parameter explanation, it leaves gaps around return behavior, failure modes, and the relationship between this snapshot and the restore/delete/list siblings.
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 references 'a named ... snapshot' and 'the VM', which weakly maps to the name and vm_id parameters, but it does not explain that vm_id identifies the target stopped VM or that name must be a unique snapshot label. This is insufficient for full 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 uses a specific verb ('Create') and resource ('named qcow2 internal disk snapshot'), plus a key condition ('while the VM is stopped'). This clearly distinguishes it from siblings such as qemu_snapshot_restore, qemu_snapshot_delete, and qemu_snapshot_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 the required precondition: the VM must be stopped. It does not name alternatives or state when not to use this tool, so it stops short of full guidance, but the main usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/idempotentHint/destructiveHint already present, the description adds a meaningful behavioral caveat: the VM remains locked by this session and requires a subsequent vm_unlock. This is not inferable from the annotations and prevents the agent from finishing without releasing the lock. It could additionally mention pagination or empty-result behavior, but the lock note is strong.
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: the first states the operation and return fields, the second states the lock caveat. No filler or restatement of the schema.
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 is mostly complete for a low-complexity read-only tool: it enumerates return fields and the lock/unlock workflow. However, with no output schema and an undocumented visible_only parameter, the definition lacks enough detail for confident invocation with the optional parameter. Minor error/empty-result behavior is also unspecified.
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 documents vm_name clearly, but visible_only has no schema description and the tool description never mentions it. The phrase 'visibility' refers to a returned field, not the filter parameter, so an agent is left to infer what visible_only=false does. At 50% schema coverage, the description needed to compensate and did 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?
Description opens with 'List windows' and enumerates the exact attributes returned (handle, title, class, process, visibility, enabled state, screen rectangle), so the tool's action and output are unambiguous. This clearly separates it from sibling window_focus/window_close/window_capture, which mutate or capture rather than enumerate.
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 gives important lifecycle context: the VM is locked by this session and vm_unlock should be called when finished, which helps an agent understand where this call fits in a locked-VM workflow. It does not explicitly say when to prefer this over alternatives such as process_list or window_capture, so the guidance is contextual rather than comparative.
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 two meaningful behaviors beyond the annotations: failure on unrepresentable characters and the VM lock state ('VM remains locked by this session; call vm_unlock when finished'). This is valuable side-effect information that the annotations do not convey, though the exact lock acquisition mechanism is slightly ambiguous.
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 carry a clear action, a behavioral constraint, and a required follow-up action. There is no filler, and the most important operational detail (VM lock/unlock) is included without bloat.
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 three parameters, no output schema, and annotations that do not mention locking, the description covers the key risks: character representability and VM lock state. It is missing explicit semantics for 'interval_ms' and does not clarify how this relates to qemu_keyboard_type, but it is otherwise sufficient for an agent to invoke and clean up after the tool 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 only 33%, so the description must compensate for undocumented parameters. It does add meaning for 'text' by explaining layout-sensitive typing and failure behavior, but it says nothing about 'interval_ms', and 'vm_name' is already documented in the schema. The compensation is incomplete for the parameter set.
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 names a specific action ('Type text') and a precise resource ('the active Windows 98 keyboard layout'), and adds a distinguishing behavioral detail: it fails rather than substituting unrepresentable characters. This makes it clear how keyboard_type differs from sibling tools like qemu_keyboard_type or 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 gives an explicit follow-up instruction ('call vm_unlock when finished') and implies this tool is for typing text in the active Windows 98 layout. However, it does not say when to choose this tool over alternatives such as qemu_keyboard_type, keyboard_key, or keyboard_hotkey, so usage context is only partially provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already marks this as destructive, and the description adds an 'immediately' behavioral aspect. However, it does not disclose important consequences such as potential data loss or bypassed guest cleanup, which would add meaningful context beyond the 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 a single concise sentence that front-loads the action and the condition. There is no redundant content or repetition of schema 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 one-parameter destructive tool with annotations covering the safety profile, the description provides enough context: what happens, when to use it, and what resource is affected. A short warning about data-loss risk would improve it, but nothing essential for invoking the tool is missing.
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 tool description does not mention or explain the parameter. The parameter name is fairly self-explanatory, so the gap is not severe, but the description contributes no semantic value 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 states a specific action and resource: 'Immediately stop a managed QEMU VM.' The qualifier 'when graceful shutdown is not possible' clearly distinguishes it from related tools like qemu_vm_shutdown. This goes beyond a simple restatement of the tool name.
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 an explicit condition for use: when graceful shutdown is not possible. This implies the graceful alternative should be considered first, though it does not explicitly name qemu_vm_shutdown as the preferred fallback.
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 annotations already establish that this is a mutating operation (readOnlyHint=false) and non-idempotent. The description adds valuable behavioral context beyond the schema: the VM lock persists after the call and must be explicitly released with vm_unlock, and the eof option can close stdin. This helps the agent understand side effects and cleanup obligations.
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 carry the essential information: the primary action and the lock cleanup requirement. There is no redundant wording, and the most critical detail is front-loaded. The description earns every word it uses.
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/unlock behavior, which is important. Still, it omits practical invocation details such as how to choose between text and base64, whether the VM must already be locked before calling, and what happens if neither payload is provided. Given the low schema coverage and absence of an output schema, these gaps make the definition incomplete for reliable use.
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 20%, so the description partially compensates by clarifying that 'text' carries UTF-8 data, 'base64' carries bytes, and 'eof' closes stdin. However, it does not explain whether text and base64 are mutually exclusive, whether exactly one must be provided, or what session_id refers to. These gaps leave ambiguity in invoking the tool correctly.
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 and resource: 'Write UTF-8 text or base64 bytes to an interactive shell and optionally close stdin.' This clearly distinguishes the tool from siblings like shell_read (reading output) and shell_exec (likely executing commands) by targeting an existing interactive shell's input stream. The verb and payload formats 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in an interactive shell context via the word 'interactive' and mentions the lock lifecycle ('VM remains locked by this session; call vm_unlock when finished'). However, it does not explicitly state when to prefer this tool over alternatives like shell_exec or shell_start, nor does it provide exclusions or a comparison to available 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?
Beyond the destructiveHint annotation, the description discloses specific behavioral consequences: guest disconnection, dependency on configured autostart, and session lock persistence with an explicit unlock requirement. This adds real operational 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 compact sentences with no filler. It front-loads the core action and then gives the essential caveats and follow-up instruction. 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 description covers the most critical operational warnings and follow-up action needed. However, it omits the semantics of force and delay_seconds, and with no output schema, there is no information about expected results or failure behavior. This leaves meaningful 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 only 33%, and the description does not explain the force or delay_seconds parameters. The schema provides names, types, and defaults but not their meaning or effect. With low coverage, the description should compensate, but it does not.
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 states a specific action and target: 'Reboot Windows 98.' This clearly identifies the operation and resource. It does not explicitly contrast itself with sibling tools like system_shutdown or qemu_vm_restart, but the Windows 98 specificity and lock behavior make the purpose reasonably distinct.
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 guidance: it disconnects the guest, requires autostart for recovery, and mandates calling vm_unlock afterward. It does not explicitly state when to prefer this tool over alternatives or when not to use it, but the context and follow-up requirements are strong.
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, readOnlyHint=false), the description discloses an important non-obvious behavior: the VM remains locked after the call and requires vm_unlock. It also clarifies that unrelated guest files are preserved, which adds nuance to the destructive hint. 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 redundancy. The core merge-copy behavior and its key guarantee are front-loaded, and the lock/unlock instruction is the only additional context. 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 description is sufficient for the core operation and the critical lock workflow, but it leaves gaps around the overwrite parameter and any result or confirmation behavior. With no output schema and low parameter coverage, the missing overwrite semantics are a notable gap for a destructive-capable 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?
Schema description coverage is only 25%; only vm_name has a schema description. The description adds that host_path and guest_path are directories, but it does not explain the overwrite parameter, path format expectations, or how host_path/guest_path relate to one another beyond the copy direction.
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 names a specific verb and resource: 'Merge-copy a host directory into the guest.' It also explicitly scopes the behavior with 'without deleting unrelated guest files,' which differentiates it from a replace-style directory push and from siblings 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 gives clear usage context: the VM is already locked by this session, and the caller must call vm_unlock when finished. It does not explicitly name alternatives, so there are no exclusion rules, but the context is strong enough for an agent to know the intended workflow.
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 the tool as destructive and non-read-only. The description adds useful behavioral context beyond that by explaining the verified temporary-file commit mechanism and the session lock lifecycle, which the annotations do not convey. There is no contradiction with 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 tight sentences with the primary purpose front-loaded and an essential lock-related instruction added right after. Every sentence earns its place and there is 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 description covers the main purpose, the commit strategy, and the lock lifecycle, which are the most critical operational facts. However, given the destructive nature, no output schema, and low parameter documentation, it leaves out overwrite semantics, path details, and when to choose alternative tools.
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 only 25% because only vm_name has a description, and the tool description does not compensate for host_path, guest_path, or overwrite. It implies host_path is the source and guest_path is the destination, but it does not explain path semantics, overwrite behavior, or other constraints.
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 ('Copy') and resource ('a host file into the guest'), and adds a distinctive mechanism ('verified temporary-file commit'). It clearly identifies what the tool does and is easily distinguishable from related tools like file_pull 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?
The description clearly conveys the operational context: the VM is locked during this operation and vm_unlock must be called afterward. However, it does not explicitly mention when to prefer alternatives such as directory_push for directories, so it lacks full when/when-not routing.
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 and idempotentHint=true, but the description adds valuable behavioral context beyond those: the VM remains locked by this session and requires vm_unlock when done. This is a meaningful side effect that annotations alone would 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 short sentences, zero redundant wording. The primary action is front-loaded, and the critical lock-related instruction is placed second where it is still easy to notice.
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 a single fully documented parameter, the description is nearly complete. The main gap is that it does not explicitly describe the output format, which is slightly more important since there is no output schema, but the phrase 'drive roots' sufficiently implies the result for an agent.
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 coverage is 100%, and the vm_name parameter is already fully documented in the schema with a description and pattern. The tool description adds no additional parameter-level meaning, which is acceptable given the schema handles 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 combines a specific verb ('List') with a clear resource ('available Windows drive roots') and a stated purpose ('for filesystem browsing'). This clearly distinguishes it from sibling tools like fs_list, which list directory contents rather than drive roots.
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 gives a clear inherent context for when the tool would be used, but it does not explicitly name alternatives or state when not to use it. The lock note ('call vm_unlock when finished') provides useful sequencing guidance, but there is no direct comparison to sibling filesystem 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?
Beyond the annotations, the description discloses an important behavioral trait: the VM remains locked by the session and requires vm_unlock afterward. The word 'validated' also hints at pre-execution validation. It does not fully explain failure behavior or partial execution, but the lock disclosure adds meaningful 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?
Two sentences with no wasted words. The core capability is front-loaded, and the critical lock caveat is placed immediately after. 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 quite complex with 13 action variants, no output schema, and minimal parameter descriptions, yet the description remains only two sentences. It covers the lock/unlock contract but omits return value expectations, error handling, atomicity of the sequence, and whether prior locking is required. It is minimally adequate but leaves notable 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?
Schema description coverage is only 25%, and the description adds no parameter-level guidance whatsoever. It does not explain stop_on_error, screenshot_after, or the relationship between actions and vm_name. The schema is rich for the action objects, but the description itself fails to compensate for the low 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 clearly states a specific verb and resource: execute a validated sequence of mouse, keyboard, delay, clipboard, and focus actions in one guest round trip. It communicates both the scope and the batching nature, distinguishing it from the many single-action sibling 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 phrase 'in one guest round trip' provides clear context that this tool is for batching sequences rather than issuing one-off actions. It also gives a concrete follow-up instruction to call vm_unlock when finished. It does not explicitly name alternative single-action tools or state when not to use it, so it stops 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 declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description correctly avoids restating them. It adds real value beyond annotations by disclosing the cascading child-tree kill default and the stateful side effect that the VM lock persists after the kill, naming vm_unlock as the required release step. These are behavioral facts not available in 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 dense sentences with the core action front-loaded: the action, the default scope, and the lock/unlock consequence. Every clause earns its place, with no filler or redundant restatement of the tool name.
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 3-parameter tool with no output schema, the description covers the critical operational path: what gets terminated, the default tree behavior, and the mandatory vm_unlock follow-up. Minor gaps remain — how to discover process_id and what the call returns — but an agent can invoke it correctly with the information given, aided by the sibling process_list 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?
Schema description coverage is only 33% — process_id and tree are undocumented in the schema. The description partially compensates by mapping the 'tree' parameter to its default behavior ('by default, its discovered child tree'), but it never explains how to obtain process_id (e.g., via process_list) or the meaning of the tree flag beyond its default, leaving an agent to infer those 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?
States a specific verb and resource — 'Terminate a process' — and adds distinctive scope: 'by default, its discovered child tree.' This unambiguously separates it from sibling process tools (process_list, process_wait) and VM-level termination tools (qemu_vm_force_stop), so an agent can select it correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implied context and a post-condition ('VM remains locked by this session; call vm_unlock when finished'), which tells the agent what to do after invoking it. However, it provides no explicit when-to-use guidance or exclusions versus alternatives such as shell_terminate for shell processes or qemu_vm_force_stop for whole-VM termination.
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 carry destructiveHint=true, so the deletion risk is known. The description adds real value beyond that by disclosing the mounted/unmounted precondition and revealing that force=true triggers a side effect — ejecting the ISO first before deleting. This is the kind of behavioral trait an agent cannot derive from the schema or 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 totaling roughly fifteen words, with the core action front-loaded and the conditional force behavior in the second sentence. Every word earns its place; there is no repetition of the tool name or schema content.
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 3-parameter destructive tool with no output schema, the definition covers the essential decision space: the unmounted precondition, the mounted-with-force behavior, and the object of deletion. Minor omissions include error behavior when mounted without force and confirmation of permanence, but the destructiveHint annotation mitigates the latter.
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 carries the parameter-semantics burden. It does explain force, the least obvious parameter, by tying it to the mounted-state behavior. However, vm_id and media_id are left entirely to their names and regex patterns — reasonably inferable, but not explicitly described.
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 pairs a specific verb ('Delete') with a specific resource ('managed ISO') and a defining precondition ('unmounted'), making the tool's scope unambiguous. It is clearly distinguishable from siblings such as qemu_media_eject (eject only), qemu_media_mount, and fs_delete without needing to open their schemas.
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 communicates the key usage condition — the ISO should be unmounted — and explains that force=true is the path when it is mounted, which is genuinely useful routing context. However, it never names alternatives like qemu_media_eject (for eject-only workflows) or qemu_media_list (for finding media_id), so the agent must infer when this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by scoping to 'this managed VM's media directory' and clarifying that the tool reports what is 'configured as mounted,' which is a meaningful nuance. However, it does not go further into behavior such as empty-result handling or behavior for invalid vm_id, so it provides only modest additional transparency 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 states the primary action first and the additional reporting behavior second. There is no filler, repetition, or unnecessary detail. 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, single-parameter, read-only listing tool with no output schema, the description adequately explains both the input scope and the expected output: a list of ISO images plus the configured mounted ISO. It could be slightly more explicit about edge cases such as 'no ISOs present' or 'no mount configured,' but these are minor gaps 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only documents vm_id via name and pattern. The description implicitly ties vm_id to 'this managed VM,' which helps an agent infer that the parameter identifies the VM whose media directory should be listed. However, it does not explicitly explain the parameter or instruct the agent on where to obtain a valid vm_id, such as from qemu_vm_list or vm_list.
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 ('ISO images stored in this managed VM's media directory'), and adds the distinct reporting function of which ISO is configured as mounted. This clearly separates it from sibling tools like qemu_media_mount, qemu_media_eject, and qemu_media_delete, which are action-oriented rather than inspection-oriented.
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 makes the operational context clear: an agent should use this tool when it needs to inspect the VM's media directory and see the currently configured mounted ISO. It does not explicitly name alternatives or state when not to use it, but the read-only list-and-report framing is a clear enough context for selecting it over the mutation-focused sibling media 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 flag destructiveHint=true and readOnlyHint=false; the description adds non-obvious behavioral context: the change is persistent and requires the VM to be stopped. It does not detail side effects on future starts, but the annotation plus persistence note is adequate for this simple setter.
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-load the core action and choices, then state the prerequisite. There is no filler or repetition of schema fields beyond what is useful.
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 two-parameter setter with no output schema, the description is largely complete: it identifies the target VM as a required ID, enumerates the device choices, and gives the critical stopped-state precondition. It lacks only error/return behavior notes, which are not essential for this operation.
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 carry parameter meaning. It explains the 'device' parameter via the boot-target list (disk/cdrom/network) and links it to boot order, but it leaves 'vm_id' semantics to inference from the name and pattern. This is partial compensation, not complete.
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 names a specific action ('Set persistent QEMU boot order'), a target resource (QEMU), and the three allowed values (disk, cdrom, network). It is clear, but it does not explicitly distinguish itself from the many qemu_media_* siblings such as qemu_media_mount/eject/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?
It clearly states the key prerequisite: 'The VM must be stopped,' which tells an agent when it is safe/valid to invoke this tool. It does not mention alternatives or explicitly say when not to use it, but none of the sibling tools perform boot-order changes.
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 that a single call performs both a move and a click, and that communication goes through QMP, which is useful beyond the annotations. Annotations specify readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but do not reveal the compound behavior or the QMP path. No contradiction with annotations was found.
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?
A single, efficient sentence that front-loads the action ('Move then click'), states the mechanism ('through QMP'), and includes the key usage condition ('before the Windows controller is available'). No wasted words or redundant restatement of the tool name.
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 fairly simple mouse-input tool, the description conveys the essential purpose, mechanism, timing, and compound behavior. There is no output schema, but this is a fire-and-forget input action. It could mention expected errors or what happens if QMP is unavailable, but for the tool's complexity the definition is adequately 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 schema already describes x and y as zero-based physical coordinates and defines the button enum with a default of 'left'. The description adds no explicit parameter detail, and vm_id lacks semantic explanation beyond its name and pattern. Parameter names are largely self-explanatory, but the description does not compensate for the undocumented vm_id parameter.
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 states a specific action sequence ('Move then click') and a specific mechanism ('through QMP') with a timing/context qualifier ('before the Windows controller is available'). This clearly distinguishes it from controller-based mouse tools like mouse_click and from move-only tools like qemu_mouse_move. It is not a tautology, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before the Windows controller is available' gives a clear condition for when this tool is appropriate. It implies that once the Windows controller is available, other input tools should be used, but it does not explicitly name them or state when not to use this tool. Context is strong but exclusions are left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds minimal behavioral context by disclosing the return content (lifecycle state), but it does not discuss behaviors such as failure modes when no broker is reachable or whether an empty list is returned.
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?
A single sentence that front-loads the verb, includes the scoping qualifier, and discloses the return value. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with rich annotations, the definition is nearly complete: there are no inputs for an agent to get wrong, and the description states the return value (list of VMs and lifecycle state). Minor gap: with no output schema present, enumerating the actual lifecycle states would further help an agent interpret the response.
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 takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. Schema coverage is trivially 100% with an empty properties object, and no 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?
The description uses a specific verb+resource combination: 'List broker-managed QEMU VMs and their lifecycle state.' The qualifier 'broker-managed' scopes the tool distinctly from generic siblings like vm_list, and the mention of lifecycle state separates it from qemu_vm_status, which targets an individual VM.
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?
Usage is implied through the purpose statement: an agent needing to enumerate broker-managed QEMU VMs and their states would select this tool. The 'broker-managed' qualifier provides a scoping signal against alternatives like vm_list, but there is no explicit when-to-use vs. when-not-to-use guidance or named 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 declare destructiveHint=true, and the description adds meaningful context: 'permanently' clarifies irreversibility and 'every retained' clarifies full-scope deletion. This goes beyond the annotation without contradicting it.
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 that front-loads the action and object with no filler. Every word earns its place, and the irreversible scope is conveyed efficiently.
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 zero-parameter destructive tool with no output schema and annotations covering safety, the description is nearly complete. It clearly states the action and scope, though it does not specify whether the action applies to the currently selected VM or to all VMs globally.
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 schema description coverage is 100%, so there is no parameter documentation burden. The baseline of 4 applies because the description does not need to compensate for any missing parameter details.
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 ('delete') and a clear resource ('every retained QEMU trash entry'), with 'permanently' and 'every' signaling scope and irreversibility. This clearly distinguishes it from sibling tools like qemu_vm_trash_list and qemu_vm_restore.
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 use this tool versus alternatives such as qemu_vm_trash_list or qemu_vm_restore. There are no conditions, exclusions, or explicit routing cues; the only implicit signal is the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read-only operation. The description adds useful context that the VMs are 'recoverable deleted' and 'managed', but does not disclose return format or pagination. Given the annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler or redundancy. Every word contributes to the meaning, and the key qualifier 'recoverable deleted' is front-loaded.
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 parameterless, read-only listing operation, this description covers the essential purpose and scope. The annotations cover safety and idempotency, and the absence of an output schema is not critical for a simple list. The only minor gap is not describing the return format, but this is not required for correct invocation.
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 accepts zero parameters, with an empty schema and additionalProperties false, so there are no parameter semantics to document. The baseline of 4 applies because no parameter guidance is needed; the description adds no redundant information.
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 'list' and identifies the exact resource as 'recoverable deleted managed VMs', which is unambiguous and clearly differentiates it from qemu_vm_list (active VMs) and qemu_vm_trash_empty (empty trash). This is a precise, single-purpose definition.
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 the tool is used to view deleted VMs that can still be recovered, likely before restoring or purging them. However, it does not explicitly state when to use it over alternatives like qemu_vm_list or mention any exclusions, leaving the usage context to inference rather than direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not idempotent, and the description adds that it clears a session-scoped selection. This is useful behavioral context, but the description does not disclose what happens if no selection is active or whether existing VM-managed state is affected beyond the selection.
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?
A single, clear sentence conveys the entire operation without filler. The key scoping information ('session's managed QEMU VM selection') is front-loaded and essential.
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 zero-parameter state-clearing tool, the description is sufficiently complete to invoke correctly. It lacks only minor behavioral details such as return/confirmation behavior and whether clearing an already-empty selection is a no-op.
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 fully defines the input contract. The description correctly does not attempt to describe parameters that do not exist, which is appropriate for a no-argument operation.
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') and resource ('this session's managed QEMU VM selection'), making the operation immediately understandable. It also differentiates itself from the sibling qemu_vm_select, since it is the inverse operation.
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 the tool is used when the session has a managed QEMU VM selection that should be cleared, and qemu_vm_select is the obvious complementary alternative. However, it does not explicitly state when to use it versus related VM-selection tools or describe any preconditions or no-op behavior.
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 goes beyond those by disclosing a significant side effect: it acquires the VM lease and leaves the VM locked until vm_unlock is called. This is exactly the kind of behavioral context 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 concise sentences with no filler. The capture purpose is front-loaded, and the critical VM-lock side effect and unlock follow-up are stated immediately. Every sentence carries operational 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 tool with no output schema, the description correctly specifies the return format (native MCP PNG image content) and the critical lock lifecycle. It stops short of explaining coordinate origin for region and the effect of include_cursor, but those are partially covered by the schema and the default value.
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 only 33%, and the tool description adds no parameter-specific guidance for region, vm_name, or include_cursor. The phrase 'pixel region' weakly relates to the region object, but it does not explain semantics, defaults, or how include_cursor affects output.
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 names a specific action and resource: capture the primary display or a pixel region as MCP PNG image content. This is clear, but it does not explicitly differentiate itself from the sibling qemu_screen_capture or window_capture, both of which could overlap in 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 gives clear operational context: calling this tool acquires the VM lease and locks the VM, and the agent must call vm_unlock when finished. It does not, however, state when to prefer this tool over alternatives such as qemu_screen_capture or window_capture.
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 (idempotent, non-destructive), the description discloses an important side effect: the VM remains locked after the call and requires a separate vm_unlock. It also identifies that broker resources are released. This adds meaningful behavioral context beyond what annotations already 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 with no filler: the first states the action, the second gives the critical postcondition and next step. The most important information is front-loaded.
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 action with only two parameters and no output schema, the description is complete enough: it explains the cleanup effect, the lock behavior, and the follow-up action. It could be slightly richer by mentioning what happens when called on an already-closed or invalid session, though idempotentHint partially covers that.
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 covers vm_name but leaves session_id undocumented. The description ties session_id to an interactive shell session and to the VM lock, which adds useful context. It does not state where session_id comes from (e.g., shell_start) or its format, so it 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.
Purpose4/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: 'Release broker resources for a completed interactive shell session.' It clearly identifies the tool as a session-close cleanup operation. It doesn't explicitly differentiate from the sibling shell_terminate, but 'completed' and 'release' make the distinction reasonably 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?
It states when to call the tool: after the interactive shell session is completed, and before the VM lock is released. It also explicitly directs the caller to vm_unlock, giving a clear sequence. It doesn't mention alternatives such as shell_terminate for active sessions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds scope and returned fields but no additional behavioral traits such as whether this triggers a refresh or requires a selected broker, so it adds moderate value 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?
A single, front-loaded sentence with no filler. It states the action, scope, and key returned fields in one pass, so 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 read-only, zero-parameter listing tool, the description is complete: it identifies the resource scope and exactly what information will be returned. No output schema exists, but the description supplies the necessary return 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 and the schema covers 100% of them, so there is nothing for the description to clarify. The no-parameter baseline of 4 applies.
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 names a specific action ('List'), a specific resource scope ('every named VM known to this broker'), and the fields returned (connection, build, address, capabilities, lease state). It is clear, but it does not explicitly contrast itself with the sibling qemu_vm_list, so the differentiation is only implicit.
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 use: use this tool when you need a full inventory of broker-known VMs and their current state. It does not provide explicit when-not-to-use guidance or name alternatives such as qemu_vm_list or vm_status, so it stops 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive, but the description adds meaningful behavioral context: writes go through a verified temporary-file commit, and the VM remains locked until vm_unlock is called. This gives the agent a clear model of side effects and required follow-up. There is no contradiction with 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 with no filler. The primary action is front-loaded, and the lock/unlock warning earns its place as essential operational context.
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 tool with no output schema, the description captures the core workflow, safety mechanism, and lock obligation. The main gaps are the unspecified rules for 'allowed host path' and unstated overwrite behavior, but the annotations and lock guidance make the tool largely usable as described.
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 only 25%, and the description only minimally compensates by clarifying that host_path is an 'allowed host path' and guest_path is a guest file. The overwrite parameter, path syntax, and the meaning of 'allowed' are left unexplained, so an agent gets little parameter-level guidance beyond 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 operation: copy a guest file to a host path. It also distinguishes this from sibling tools like file_push and directory_pull by specifying direction and single-file scope. The 'verified temporary-file commit' detail adds precision without confusing the core purpose.
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-related warning implies this tool is used during a locked VM session and that vm_unlock must follow, but the description never explicitly says when to choose file_pull over alternatives such as file_push or directory_pull. The usage context is partially clear but excludes no 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?
The description discloses a significant behavioral trait not visible in annotations: the tool leaves the VM locked and requires a subsequent vm_unlock call. This goes beyond the schema and annotations and helps the agent plan follow-up actions.
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 behavior and examples, with the lock caveat placed second. Every word earns its place and there is no redundant repetition of schema content.
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 three-parameter tool with no output schema, the description covers the key parameters, example values, action types, and the critical lock-release requirement. It could be more complete by mentioning what happens on invalid keys, but it is adequate for safe invocation.
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 description coverage is only 33%, so the description must compensate. It does by explaining the key parameter with common examples and mapping the action enum to press, hold, and release. The vm_name parameter is already described in the schema, so the combination is reasonably informative.
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 keyboard key, with concrete examples (ENTER, CTRL, LEFT, F1). It is specific about the resource and action, though it does not explicitly distinguish itself from sibling tools like qemu_keyboard_key or keyboard_hotkey.
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 workflow context: the VM remains locked by the session after using this tool and vm_unlock must be called when finished. This tells the agent how to sequence the operation, though it does not mention when to prefer keyboard_type, keyboard_hotkey, or other 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?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds a valuable non-obvious behavioral fact: the VM remains locked by this session and must be unlocked with vm_unlock. This goes beyond the structured annotations and is critical for correct 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 concise sentences: the first states the core functionality, the second conveys the essential lock-lifecycle warning. No filler, repetition, 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?
The tool has one well-documented parameter, safety-related annotations, and no output schema. The description adds the missing lock context and lists the information categories returned, which is sufficient for an agent to invoke it and finish the workflow 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?
The schema fully documents the only parameter, vm_name, including its format and configuration source. Since schema description coverage is 100%, the description does not need to add parameter details; baseline 3 is appropriate.
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?
Description identifies a concrete action (read) and a specific resource: detailed guest OS, code-page, display, and build information. It is clear what the tool operates on, but it does not explicitly differentiate itself from sibling status/information tools like vm_status or qemu_vm_status.
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 intended use is implied: call this when detailed guest system or build information is needed. The lock caveat gives useful workflow guidance ('call vm_unlock when finished'), but there is no explicit comparison with alternatives or when-not-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?
The description adds valuable behavioral context beyond annotations: the VM lock is held by the session after the call and must be released with vm_unlock. This is not captured by readOnlyHint 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?
Two sentences with no filler: the first states the core action, and the second surfaces the critical lock/unlock behavior. The structure is compact and front-loaded.
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 read tool, the description covers purpose, locking side effect, and follow-up action. There is no output schema, so the return value is only implied by 'Read text'; edge cases like an empty clipboard are not addressed, but this is a minor gap.
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 vm_name with a pattern and reference to WIN98CTL.INI, and format is constrained to 'text' with a default. The description reinforces the textual nature but adds no deeper parameter semantics. Schema coverage is sufficient 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 states a specific verb and resource: 'Read text from the Windows 98 clipboard.' It clearly distinguishes this read operation from the sibling clipboard_set and other VM tools. The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear procedural context by noting the VM remains locked and instructing the agent to call vm_unlock when finished. It does not explicitly contrast with clipboard_set or state when not to use it, but the intended context is evident.
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, and the description builds on that by clarifying the destructive scope: unrelated host files are not deleted. It also discloses lock ownership and the required vm_unlock cleanup, which is meaningful behavioral context beyond what the 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 compact sentences with no wasted words. The main action and safety caveat are front-loaded, followed by the lock reminder. Each sentence carries distinct, 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?
For a destructive 4-parameter copy tool with no output schema, the description covers purpose, safety boundary, path restriction, and post-condition. The main gap is overwrite semantics, which prevents it from being fully 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 clarifies guest_path as a guest directory and host_path as a host path, but the overwrite parameter is not explained at all. With schema description coverage at only 25%, the description partially compensates but leaves a meaningful parameter 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 states a specific action ('merge-copy') with an explicit source (guest directory) and destination (allowed host path), and adds a key safety qualifier: 'without deleting unrelated host files.' This clearly distinguishes the tool from sibling operations like directory_push or file_pull by direction and merge semantics.
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 merge-copy a guest directory to a host path. It also includes a lifecycle precondition ('VM remains locked by this session; call vm_unlock when finished') and an allowed-path restriction. It does not explicitly name alternative sibling tools, which keeps it from 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 readOnly, idempotent, and non-destructive behavior. The description adds a meaningful behavioral side effect beyond annotations: the VM lock is retained by this session and requires vm_unlock. This is valuable context for safe agent 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?
Two sentences with no filler. The primary operation is front-loaded, and the critical lock-release warning is placed second. 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 simple read-only list operation, the description covers the main action, recursive option, and lock state. It does not describe the return format, but the tool's name and 'List' imply a listing, and no output schema exists to do so.
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 33%, with path and recursive lacking descriptions. The description adds useful meaning by identifying path as a guest directory and recursive as optional recursion, but it does not compensate fully for path format, required existence, or error 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 uses a specific verb and resource: 'List a guest directory' with an optional recursive flag. This clearly distinguishes fs_list from sibling tools like fs_move, fs_delete, and fs_stat, and the name/title reinforces the operation.
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 clearly states the operation and the optional recursive behavior. It also gives crucial lifecycle guidance by warning that the VM remains locked and instructing the agent to call vm_unlock when finished, though it does not explicitly discuss alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-destructiveness. The description adds meaningful behavioral context beyond annotations: it releases only keys tracked as held by this session, and it does not unlock the VM. This helps the agent understand side effects and prerequisites.
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 filler, with the core action front-loaded and the critical follow-up instruction placed second. Every word contributes to correct usage.
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, idempotent release-all operation with one well-documented parameter, the description sufficiently covers the action, scope, and postcondition. It does not describe output or edge cases, but no output schema exists and the behavior is straightforward.
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 coverage is 100% with a single vm_name parameter fully documented in the schema. The description does not need to repeat parameter details, and the baseline of 3 is appropriate since the schema handles the semantic burden.
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 precise resource ('every keyboard key tracked as held by this session'), clearly distinguishing this from single-key tools like keyboard_key and from mouse_release_all. The session scoping adds necessary 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 clearly implies when to use it (after keyboard input, to clear all held keys) and provides a crucial postcondition: the VM remains locked and vm_unlock should be called. It does not explicitly contrast with alternatives, but the context is clear enough for an agent to select 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 annotations are sparse and do not mention lock behavior, so the description adds valuable behavioral context by warning that the VM remains locked by this session and instructing the agent to call vm_unlock afterward. It does not detail whether the button is released at the end of the drag, but the core side effect is 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 compact and well-structured: the first sentence states the operation, and the second sentence conveys the critical lock state and required follow-up. There is no redundant wording 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?
For a tool with 8 parameters and no output schema, the description covers the essential behavior, the coordinate-based nature of the drag, and the important lock side effect. It leaves some minor gaps such as whether the mouse button is released at the end and what the command returns, but the provided information is sufficient for an agent to invoke it correctly in most cases.
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 63%, and the description adds only marginal semantic value beyond the schema: 'exact pixel coordinates' maps to from_x/from_y/to_x/to_y, and 'selected mouse button' maps to the button enum. It does not explain the optional parameters steps or duration_ms, which are only documented by defaults and ranges in 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 opens with a specific action verb and resource: 'Drag between exact pixel coordinates while holding the selected mouse button.' This clearly identifies the tool as a mouse drag operation and implicitly distinguishes it from sibling tools like mouse_move or mouse_click by emphasizing the held button during movement.
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 for when to use the tool: dragging between exact pixel coordinates with a chosen mouse button. It also gives an explicit follow-up directive: the VM remains locked and vm_unlock should be called when finished. However, it does not explicitly name 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.
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 goes further by disclosing the lock-lifecycle behavior: the VM remains locked by this session and the agent must call vm_unlock when finished. This is valuable context beyond what the annotations provide, though the phrasing is slightly ambiguous about whether the tool itself acquires the lock.
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 filler. The primary purpose is front-loaded, and the important lock/unlock caveat is included without repeating schema or annotation 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 one-parameter read-only tool, the description covers the operation and the essential lock cleanup requirement. The only notable omission is the return format for the mouse position (e.g., coordinate units or screen space), especially since no output schema exists, but this does not block correct invocation.
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 schema already documents vm_name with a pattern and a clear description. The tool description adds no additional parameter-level detail, so the baseline of 3 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 states a specific verb ('Read') and a precise resource ('current mouse pointer position'), making the tool's purpose immediately clear. It is also easily distinguished from sibling movement and click tools, which change state rather than read it.
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 read semantics clearly imply when to use this tool, and the second sentence adds a concrete operational context: the VM remains locked and vm_unlock must be called afterward. The main gap is that it does not explicitly contrast this tool with alternatives like mouse_move or qemu_mouse_move, but the intended usage is still evident.
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 an important behavioral trait: the VM remains locked by this session and the agent must call vm_unlock when finished. It also clarifies that the tool may move the pointer before releasing. This is consistent with the annotations and adds real operational 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 sentences, action first, lock warning second, with zero filler. Every piece contributes to correct invocation or lifecycle handling.
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 plus schema coverage is nearly complete: it states the action, optional coordinate behavior, and the critical VM-lock postcondition. It does not explicitly mention pairing with mouse_down or behavior when no button is held, 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 schema already documents x, y, button, and vm_name well. The description adds meaning to x/y by stating they are used for an optional movement before the release, which is not evident from the schema alone. The button parameter is self-explanatory via its enum and default.
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 action, 'Release a held mouse button', and adds the optional coordinate-move behavior. This clearly distinguishes it from siblings like mouse_down, qemu_mouse_click, and mouse_release_all by targeting a single button release.
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 gives context by mentioning releasing a held button and the VM lock state, but it does not explicitly name alternatives or state when to prefer this over mouse_release_all or after mouse_down. The usage is implied rather than directly guided.
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 readOnly, idempotent, non-destructive behavior. The description adds important behavioral context beyond the annotations: the tool leaves the VM locked and explicitly instructs the agent to call vm_unlock afterward. This is valuable operational 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, both necessary. The primary action is stated first, followed by the critical lock-release instruction. No filler or redundant repetition of schema or annotation 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 tool is simple: one documented parameter, no output schema, and annotations cover safety. The description provides the critical lock context and tells the agent the exact next step. It could mention what the returned process list looks like, but that is implied sufficiently for a list operation.
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% description coverage and fully documents vm_name, including its pattern and meaning from WIN98CTL.INI. The description adds no parameter-level meaning, so the baseline of 3 applies.
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 and resource: 'List Windows 98 processes.' This clearly distinguishes process_list from siblings like process_kill and process_wait by its read-only listing 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 gives clear usage context by noting that the VM remains locked and that vm_unlock should be called when finished. It does not explicitly name alternative tools for killing or waiting on processes, but the basic when-to-use and follow-up action are 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 mark the operation as destructive and non-idempotent. The description adds useful behavioral context beyond annotations by specifying the snapshot type (qcow2 internal disk snapshot) and the required VM state (stopped). This helps the agent understand preconditions and what will be affected.
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?
A single sentence with no filler. It front-loads the action, specifies the target object, and adds the key precondition. Every part 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 destructive tool with annotations indicating destructive behavior, the description is largely complete: it states what is deleted and under what condition. It does not describe error cases or how to discover valid snapshot names, but those are not essential for basic invocation.
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?
Input schema coverage is 0%, so the description carries the burden of explaining parameters. It explicitly ties 'name' to the named snapshot and implies 'vm_id' through 'the VM is stopped', but it does not clarify parameter formats or relationships beyond what the JSON schema patterns already provide. Some meaning is added, but not enough to fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (delete), a specific resource (named qcow2 internal disk snapshot), and an important condition (while the VM is stopped). It clearly distinguishes this tool from sibling snapshot tools like qemu_snapshot_create, qemu_snapshot_restore, and qemu_snapshot_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 gives a clear usage context by requiring the VM to be stopped before deletion. It does not explicitly mention alternative tools or list when-not-to-use conditions, but the precondition and the destructive nature are clear enough to guide basic 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 reveals an important side effect: the tool acquires a VM lease and leaves the VM locked until vm_unlock is called. This is critical stateful behavior that an agent could not infer from readOnlyHint or destructiveHint alone. It stops short of explaining blocking behavior or lease-failure handling, but the main behavioral trait is 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 two tight sentences with no filler. The purpose is front-loaded, and the critical lock/unlock caveat immediately follows, making every sentence operationally relevant.
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 dialog tool, the description covers the main integration risk: the acquired lease and required vm_unlock call. It does not mention return values or whether the dialog blocks, but no output schema exists and the essential call sequence is provided.
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 describes vm_name explicitly but gives only type and length constraints for message. The description implicitly indicates that message is the dialog's displayed text, but it does not explicitly map parameters to their roles. Since schema coverage is 50%, the description adds some meaning but does not fully compensate for the undocumented message 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 states a specific action and resource: 'Display a Windows 98 message dialog titled Windows 98 Remote Control.' This clearly distinguishes the tool from the many sibling VM, input, and file tools, and the dialog title removes ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the lock lifecycle: it acquires the VM lease, keeps the VM locked, and instructs the agent to call vm_unlock when finished. It does not explicitly list when not to use this tool or name alternatives, but the usage context is clear enough for correct invocation.
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 cover the read-only, idempotent, and non-destructive profile. The description adds meaningful behavioral context beyond annotations by stating that no VM lease is acquired and that the operation targets a connected Windows 98 guest, which is valuable for an agent deciding whether to invoke it.
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 one tightly worded sentence that front-loads the main action before the lease condition. No redundant or filler words are present.
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 strong schema and annotation coverage, the description covers the core behavior and the key precondition (no lease). It does not spell out the return value structure, but the simple operation and the word 'capabilities' make the expected output clear enough for correct invocation.
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 single parameter vm_name has a clear description ('Unique VM name configured in WIN98CTL.INI'). The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.
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'), names the resource ('connected Windows 98 guest capabilities'), and adds a distinguishing condition ('without acquiring the VM lease'). This clearly identifies what the tool does and sets it apart from lease-requiring VM 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 phrase 'without acquiring the VM lease' provides clear usage context: this is the lightweight read path when a lease is not needed. It does not explicitly name alternative tools or state when not to use it, but the context is unambiguous.
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 VM remains locked by this session and that vm_unlock must be called. This is a meaningful stateful behavior not captured by readOnlyHint=false or idempotentHint=true. 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?
Three short sentences deliver action, context, and lifecycle guidance with no filler. The purpose is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lock tool with no output schema, the description covers what, when, and the residual state. It could mention blocking behavior or failure modes, but the core calling context is sufficiently 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?
Schema description coverage is 100%, with vm_name already fully documented as a unique VM name configured in WIN98CTL.INI. The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.
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: 'acquire the exclusive VM lease.' It clearly differentiates this tool from siblings by noting that most operational tools acquire the lease automatically and that vm_unlock is the counterpart. 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 description provides clear context: call this only when you need an explicit exclusive lease, since most operational tools acquire it automatically. It also directs the agent to call vm_unlock when finished. However, the 'when not to use' guidance is implied rather than stated as an explicit exclusion.
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 reveals an important nuance: a normal unlock refuses when terminals or transfers are open, implying that force changes this behavior. This adds meaningful context about failure modes and the existence of a non-normal mode, even though it does not fully spell out the exact effect of force.
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 no filler: the first states the core purpose, the second adds a critical behavioral caveat. It is front-loaded and 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 low-complexity tool with helpful annotations and input schema, the description covers the main purpose and a key edge case. It could be more explicit about how force overrides the refusal and what the return behavior is, but those are not significant blockers given the schema and 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 schema documents vm_name but leaves force undescribed, giving only 50% coverage. The phrase 'Normal unlock refuses...' indirectly hints that force is the abnormal override mode, but it never explicitly connects force to that behavior. The description adds some meaning but still relies on inference.
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 concrete action—'Release this session's VM lease'—naming both the verb and resource precisely. It further distinguishes itself with the conditional behavior 'Normal unlock refuses while terminals or transfers remain open,' clearly separating it from sibling tools like vm_lock and other VM management 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?
The description gives clear context about when the unlock will fail (while terminals or transfers are open), which is directly useful for choosing the right invocation. It implies that the optional force parameter provides an alternative path, though it does not explicitly name sibling tools or state 'use force=true when you want to override.'
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 and readOnlyHint=false, so the close action's destructive nature is covered. The description adds value beyond annotations by disclosing that the VM lock persists after closing and that vm_unlock is required as a follow-up.
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 the core action, the second provides the essential follow-up requirement. There is no wasted wording, and the most important operational detail (vm_unlock) is included.
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 action with no output schema, the description is mostly complete: it states the action, references the selected window, and notes the lock behavior. It omits explicit failure/return behavior, but the schema covers parameter origins and the lock hint provides critical operational context.
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%, with both vm_name and window_id already documented. The description does not add meaningful parameter semantics beyond what the input schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('close') on a specific resource ('selected window'), clearly distinguishing it from sibling tools like window_focus, window_capture, and window_list. It is immediately obvious what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context: the VM remains locked by this session and vm_unlock must be called when finished. It does not explicitly name alternative tools or when-not-to-use conditions, but the lock and unlock sequencing gives the agent actionable usage 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 indicate this is not read-only and not destructive. The description adds important behavioral context by noting that the VM lock persists after the call and that vm_unlock must be called afterward. 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 two short sentences with no filler. It front-loads the primary action and immediately follows with the critical lock-state side effect and next-step instruction.
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 and the important VM lock lifecycle. It could mention failure behavior or return value, but these are not critical for correct invocation.
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%, so the schema already documents window_id as a window handle from window_list and vm_name as the configured VM name. The description adds minimal parameter meaning beyond what the schema provides, so a baseline score of 3 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 a specific verb ('Bring') with a clear resource ('a window') and ties it to the output of window_list. It distinguishes itself from siblings like window_close and window_capture by stating the exact foregrounding 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 clearly indicates that the window must come from window_list and that the VM remains locked by this session, instructing the agent to call vm_unlock when finished. It does not explicitly list alternatives or exclusions, but the context is strong enough for correct 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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context by stating the tool operates without the VM lease, which is a subtle side-effect/access-pattern detail not captured by the annotations. It also clarifies what specific diagnostic data is read.
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?
A single, tightly-worded sentence that front-loads the action and resource, with the key operational differentiator ('without acquiring the VM lease') at the end. Every word earns its place; no filler 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 simple parameter set (one well-documented string), the strong safety profile from annotations, and the absence of an output schema, this description provides everything an agent needs to select and invoke the tool correctly. The precise scope of what the tool reads is stated, and the lease-free behavior is a critical contextual detail.
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%, with vm_name already described as a unique VM name configured in WIN98CTL.INI. The tool description adds no extra parameter meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies an explicit verb ('Read') and resource ('guest crash context and supervisor recovery status'), and also notes the key operational constraint ('without acquiring the VM lease'). This clearly distinguishes the tool from sibling diagnostic/status tools and leaves no doubt about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this tool should be used: when a non-invasive, lock-free diagnostic read is needed. However, it does not explicitly name alternatives or state when NOT to use it, so it stops short of 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 indicate idempotentHint=true and destructiveHint=false. The description adds valuable context beyond annotations: the VM remains locked after release, and vm_unlock must be called separately. This clarifies a subtle behavioral expectation not captured by the schema or 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, zero wasted words, and the primary action is front-loaded. The lock reminder is a necessary addition rather than 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 simple, single-parameter tool with no output schema, the description fully covers the action, scope, and an important post-condition. The agent knows exactly what will happen and what follow-up action is required.
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 vm_name parameter is fully documented in the schema. The description does not add parameter-specific detail, but none is needed given the schema's clarity, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Release every mouse button tracked as held by this session.' It clearly distinguishes this from single-button release tools like mouse_up by emphasizing 'every' and the session-scoped tracking.
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 the tool: to release all mouse buttons held within the session. It does not explicitly name alternatives like mouse_up for individual releases, but the 'every' qualifier and session-scoped language make the appropriate context evident.
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 several important behaviors beyond the annotations: ordered stdout+stderr capture, possible screenshot on error, and the critical fact that the VM remains locked until vm_unlock is called. This is meaningful context that the annotations do not provide, and it contradicts nothing.
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 filler. The primary action and output behavior are front-loaded, and the VM lock warning is placed at the end where it serves as an important operational note.
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 lack of an output schema, the description provides a solid behavioral contract: ordered output capture, error screenshots, and VM lock lifecycle. It does not detail timeout/cwd defaults or exit-code semantics, but those are parameter-level details rather than major gaps in the tool's overall context.
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 only 20%, so the description needed to compensate for the undocumented parameters. It mentions captured output and screenshot-on-error, but it does not explain cwd, timeout_ms, or the screenshot_on_error parameter directly, and command semantics are only implicit in 'Run a command'. Most parameters are left to be inferred from their 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 states a specific action ('Run a command to completion') and a clear resource (a command on a VM), and it specifies behavioral details: captured ordered stdout+stderr and possible screenshots on error. This distinguishes it from interactive shell tools like shell_start and shell_read by emphasizing one-shot execution to completion.
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 communicates the execution model: run to completion, capture output, and handle the VM lock by calling vm_unlock when finished. It does not explicitly name alternatives or exclusion criteria, but the 'to completion' wording provides enough context to separate it from interactive or streaming shell 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 state readOnlyHint and idempotentHint, and the description adds a meaningful behavioral guarantee: the call does not acquire the VM lease. It also clarifies what state is inspected (guest connection and lease), which is useful 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?
One sentence, no filler, and the most decision-relevant fact (inspection without lease acquisition) is front-loaded. Every word adds meaning.
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 one-parameter read-only inspection tool with full schema coverage and safety annotations, the description is complete enough to select and invoke correctly. It specifies what is inspected and the key side-effect constraint; an output schema is not required for safe invocation.
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 covers the single vm_name parameter 100%, including its pattern and meaning in WIN98CTL.INI. The description adds no parameter-level detail, so baseline 3 applies; it does not need to compensate for coverage gaps.
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 'Inspect' with a clear resource: guest connection and lease state. The phrase 'without acquiring the VM lease' separates it from lease/lock operations and from sibling qemu_vm_status, which would target QEMU VM state rather than guest connection/lease state.
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?
'Inspect ... without acquiring the VM lease' provides clear context for when to call this tool: a read-only status check that should not lock the VM. It does not explicitly name alternatives such as vm_lock, so it falls short of fully explicit routing.
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 non-read-only mutation. The description adds meaningful behavioral context by flagging that the VM stays locked by the session and that vm_unlock is required afterward. This goes 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?
Two short sentences deliver the core action and the critical follow-up instruction without wasted words. The primary purpose is front-loaded.
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 what the tool does and the lock-related follow-up. It could mention whether a prior lock is required, but the existing wording is sufficient for safe invocation.
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 action 'Replace Windows 98 clipboard text' makes it clear that the text parameter is the new clipboard content. The vm_name parameter is fully described in the schema, so the two parameters are effectively understandable.
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 and resource: replace Windows 98 clipboard text. This clearly distinguishes the tool from its sibling clipboard_get and other VM/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?
The description gives concrete operational context: the VM remains locked after the call and vm_unlock should be called when finished. It does not explicitly list when to avoid this tool, but the lock/unlock sequencing is clear and useful.
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 non-obvious behavioral side effect: the VM remains locked by this session and requires an explicit vm_unlock call. This is valuable information an agent would not otherwise know from the schema or 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, both earning their place: the first states the core operation, and the second warns about the lock lifecycle. 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?
The description covers the core purpose, the critical lock/unlock requirement, and the read-only nature of the operation. Since there is no output schema, it does not describe the exact shape of returned metadata, which is a minor gap, but the tool can still be correctly selected and invoked.
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 schema describes vm_name but leaves path as a bare string. The description adds meaning by clarifying that path is a guest filesystem path, helping distinguish guest paths from host paths. With 50% schema coverage, this partial compensation is meaningful, though vm_name semantics are already covered by 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 opens with a specific verb and resource: 'Read metadata for a guest filesystem path.' This clearly distinguishes fs_stat from sibling tools like fs_list, fs_move, and fs_drives, which perform different operations on the filesystem.
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 gives an implied usage context by stating what it reads, and it provides an important follow-up instruction: 'call vm_unlock when finished.' However, it does not explicitly compare against alternatives or state when to choose this tool over other fs_* tools, so the guidance is only partially complete.
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?
While annotations already indicate the tool is not read-only, not idempotent, and not destructive, the description adds meaningful behavioral context: the VM remains locked after the call and the caller must unlock it. It also discloses a dependency on guest wheel support, which is not visible in the schema or 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 filler. The core action is front-loaded, followed by the prerequisite and lock/unlock responsibility. 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 tool with four parameters and no output schema, the description covers the critical invocation facts: what it does, optional coordinates, guest wheel support requirement, and lock management. It does not specify exact delta semantics or failure behavior if wheel support is missing, but these are partially covered by the schema and the prerequisite statement.
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 coverage is high at 75%, and the schema already explains x, y, and vm_name. The description adds modest value by calling delta a 'mouse-wheel delta' and noting coordinates are optional, but it does not clarify delta direction, units, or how negative values behave. This is adequate but not richly informative 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 and object: 'Send a mouse-wheel delta at optional coordinates.' This clearly distinguishes it from sibling input tools like mouse_move, mouse_click, and qemu_keyboard_type. The 'Requires guest wheel support' caveat further clarifies the intended domain 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 names the main prerequisite ('Requires guest wheel support') and provides explicit follow-up guidance ('call vm_unlock when finished'). It does not explicitly name alternative tools for when wheel support is unavailable, but the context is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations flag destructiveHint=true, but the description adds valuable specifics beyond that: the shutdown is graceful first, the operation blocks for 40 seconds, and the fallback stop is scoped to 'only this QEMU process.' This two-phase escalation and scoping is exactly the behavioral context an agent needs and is not derivable from 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?
One 16-word sentence conveys three behavioral phases (graceful, wait, conditional stop) with zero filler. The primary action is front-loaded and every clause 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 full shutdown protocol, timing, and scope are disclosed, and the destructive nature is covered by annotations while vm_id format is in the schema. Minor gaps: no indication of what the response looks like (no output schema exists) and no pointer to qemu_vm_status for post-condition verification.
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 for the undocumented vm_id parameter. The phrase 'only this QEMU process' implicitly ties vm_id to the target VM, and the parameter name plus tool name make the meaning inferable, but the description never explicitly defines vm_id or explains where valid IDs come from. This is only partial compensation for the 0% coverage 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 states a specific verb+resource (graceful guest shutdown of a QEMU VM) and a precise three-phase behavior: request graceful shutdown, wait 40 seconds, then stop only the QEMU process if needed. This clearly distinguishes it from siblings like qemu_vm_force_stop (immediate kill), qemu_vm_restart, and system_shutdown (host-level).
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 graceful-first, timeout-fallback framing gives clear context for when to use this tool — when a clean guest shutdown with a guaranteed stop is desired. It does not explicitly name alternatives or state when-not-to-use (e.g., qemu_vm_force_stop for immediate termination), so it stops 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: cursor-based incremental read semantics, bounded output (max_bytes), optional long-polling (wait_ms), and the critical side effect that the VM remains locked by this session, requiring an explicit vm_unlock call. This lock warning is exactly the kind of context that prevents the agent from accidentally holding or leaking locks. 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 zero filler. The core action, the cursor/bound/poll constraints, and the lock warning are each conveyed in a short clause. The lock caveat is correctly placed second, after the primary action, and 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 5-param read tool with no output schema, the description covers the operation, the polling behavior, and the lock lifecycle, while annotations carry the safety profile. Remaining gaps: return format is uncharacterized (no output schema exists to fill this in) and there is no guidance on how to obtain a valid session_id (presumably from shell_start). These are notable but minor for a straightforward read 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?
Schema coverage is only 20% (just vm_name is described), so the description must compensate—and it does, embedding the semantics of three undocumented parameters in prose: 'bounded' maps to max_bytes, 'after a cursor' to after_cursor, and 'long-polling' to wait_ms. session_id is only weakly tied via 'this session,' and no explicit per-parameter explanations or defaults are given, but the implicit mapping is serviceable.
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?
States a specific verb ('Read') and resource ('output after a cursor from an interactive shell'), with the cursor qualifier distinguishing it from one-shot execution or full-output reads. The long-polling option and lock warning add operational specificity. Among the shell siblings (shell_exec, shell_write, shell_start, shell_terminate, shell_close), this is clearly the incremental-output reader.
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 the usage scenario—when an interactive shell session is producing output and you want bounded, cursor-relative reads, optionally waiting via long-polling. It does not name alternatives or exclusions (e.g., when to prefer shell_exec's synchronous output over shell_read), leaving the agent to infer the decision from the interactive-shell wording. The vm_unlock pointer is a post-condition rather than a when-to-use guide.
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?
For a tool with only default annotations, this description carries important behavioral context: the wait is in a FIFO lease queue, the session retains the VM lock afterward, and the wait is capped at ten minutes. It does not describe what happens if the wait times out or if VM_BUSY never clears.
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 short sentences, front-loaded with the action and timeout, and every sentence adds operational value. There is no filler or repetition.
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 no output schema and sparse annotations, the description covers the essential invocation context: when to call it, how long the wait can be, the resulting lock state, and the cleanup call. The main missing piece is failure/timeout behavior, but the core usage is 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?
The schema already describes vm_name well, but wait_seconds has no schema description. The phrase 'at most ten minutes' helps explain the wait_seconds upper bound and units, partially compensating for that gap. An explicit statement like 'wait_seconds is the maximum time in seconds to wait' would push this higher.
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 names a specific verb and resource: 'Wait in the FIFO lease queue' with a concrete limit ('at most ten minutes'). It also conveys the lock lifecycle ('VM remains locked by this session; call vm_unlock when finished'), which distinguishes it from the vm_lock/vm_unlock siblings 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 gives an explicit trigger ('Use after VM_BUSY') and a required follow-up ('call vm_unlock when finished'). It does not name alternatives or state when not to use the tool, so it stops short of full routing 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 readOnly, idempotent, and non-destructive annotations, the description discloses an important behavioral trait: the VM remains locked by this session and requires a later vm_unlock call. This adds meaningful operational context that the 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 concise sentences that front-load the core action and output type, then add the lock-related operational note. Every sentence adds necessary information with no redundancy 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 two-parameter tool, the description covers the return format (MCP PNG image content) and the important post-condition (VM remains locked, call vm_unlock). The schema handles parameter documentation, and annotations cover safety, making the definition 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 coverage is 100%, with both vm_name and window_id already described clearly in the schema. The description adds no additional parameter-level detail, so it neither improves nor harms parameter understanding beyond the structured 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 and resource: 'Capture a selected window' with a specific output type, 'native MCP PNG image content.' It clearly distinguishes itself from the sibling screen_capture and qemu_screen_capture tools by focusing on a window rather than the full screen.
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: use this tool when you need an image of a specific window. It also gives workflow guidance by noting that the VM remains locked and that vm_unlock should be called afterward. It does not explicitly name alternative tools or exclusions, but the intended use is not ambiguous.
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 significant stateful behavior beyond annotations: the button remains held until released, and the session retains a VM lock requiring vm_unlock. This is exactly the kind of context annotations cannot infer.
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 sentences with no filler: action, mandatory follow-up (release), and VM lock/unlock obligation. Each sentence adds information necessary for correct invocation.
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 4-parameter side-effecting tool with no output schema, the description covers the essential operational contract: optional movement, hold action, release requirement, and VM lock cleanup. Nothing an agent needs to call this safely or clean up afterward is missing.
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 descriptions already document x/y coordinates, button enum, and vm_name. The description adds meaning by explaining that x/y are optionally moved to before the button press, which is not captured in the schema. Schema coverage is high, so the description complements rather than carries the burden.
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 ('Hold a mouse button down') and differentiates itself from sibling tools by noting it optionally moves to coordinates first, which distinguishes it from mouse_click, mouse_up, and mouse_move. An agent can tell exactly what action this performs.
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 clearly frames the tool's use for press-and-hold input and gives the important instruction to release later. It does not explicitly name sibling alternatives or exclusions, but the condition is clear enough from the stated behavior.
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