Press named keys in sequence and release them in reverse to trigger hotkeys inside a Windows 98 VM. Lock the VM during execution and release it with vm_unlock when finished.
Press named keys in order and release them in reverse order. VM remains locked by this session; call vm_unlock when finished.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes | ||
| vm_name | Yes | Unique VM name configured in WIN98CTL.INI. |
Changes observed during successful MCP inspections.
v1.7.0Input schema / properties / vm_nameAdded value: +{
+ "description": "Unique VM name configured in WIN98CTL.INI.",
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "keys"
-]New value: +[
+ "keys",
+ "vm_name"
+]v0.0.0-developmentDoes 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.
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.
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.
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.
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.
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.