lowlevel-computer-use-mcp

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Most tools have clearly distinct purposes, especially across categories like input, window management, headless desktops, and WSL. However, there are multiple ways to send keyboard input (type_text, press_keys, win_send_keys, ahk_control_send) which could cause confusion despite descriptive names.
Naming Consistency3/5
Names are generally readable and use snake_case, but the pattern is inconsistent. Some follow verb_noun (list_windows, crop_image), others are less systematic (wsl_status, startup_status, run_ahk). The variety of prefixes and lack of a strict convention reduce predictability.
Tool Count2/5
With 53 tools, this server provides extensive coverage of low-level computer automation, but the number feels excessive. Many tools are platform-specific (Windows, Linux, WSL) or offer multiple variants of similar actions, which could overwhelm an agent.
Completeness4/5
The tool surface covers the core workflows of computer automation well: input simulation, window management, screenshots, headless desktops, process control, and WSL management. Minor gaps exist (e.g., clipboard, file operations), but these are not central to the stated purpose.
Average 4/5 across 53 of 53 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- Last stable release on August 3, 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses cursor movement to absolute coordinates and optional animation, but omits instant jump and focus disruption confirmation. Annotations provide idempotentHint and destructiveHint, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections for Args and Returns. It could be slightly more efficient, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object with 5 properties) and annotations, the description covers the basics but misses important parameters like instant and confirm_focus_disruption, and does not explain the return format beyond 'JSON with the resulting cursor position'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions x, y, and duration, but does not cover instant or confirm_focus_disruption. Since the schema already has detailed parameter descriptions, the description adds marginal 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 clearly states 'Move the mouse cursor to an absolute screen coordinate,' specifying the verb and resource. It implicitly distinguishes from sibling tools like mouse_click or mouse_drag, but does not explicitly differentiate.
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 on when to use this tool versus alternatives. The description does not mention contexts where mouse_move is preferred over other cursor movement tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify destructiveHint=true. The description adds that it executes 'arbitrary commands on the host with the server's privileges', which is a strong and important behavioral trait. It also details the capture of stdout/stderr/exit code and timeout behavior, providing useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with a clear one-sentence purpose, adds a security note, then lists args and return format. No unnecessary words, and the key 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?
Given that the tool executes arbitrary commands (a high-complexity operation), the description covers the return format and warns about privileges. However, it lacks details on error codes, encoding issues, or behavior when timed out. The available output schema (mentioned in signals) would fill some gaps, but the description itself is minimally 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?
The input schema has descriptions for each nested property (command, cwd, shell, timeout), so the schema covers the parameter semantics. The description only repeats the argument structure without adding new details or examples. Since schema description coverage is 0% for the top-level param, the description could have compensated but 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 the tool runs a system/shell command and captures stdout, stderr, and exit code. It is specific about the action and resource. However, it does not explicitly differentiate from sibling tools like 'run_command_as_admin' or 'wsl_run', so it loses a point for lacking sibling differentiation.
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 'run_command_as_admin' or 'ahk_control_send'. It mentions that it executes arbitrary commands with server privileges, implying caution, but does not give explicit usage context or 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, destructiveHint, and idempotentHint, so the description needs minimal additional detail. It adds the return format but no side effects or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an unnecessary 'Args:' section that redundantly restates the parameter. It could be more concise by omitting that section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only) and the presence of an output schema in the description, it adequately conveys what is returned. The description of the return JSON structure adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only says 'display number,' which adds little beyond the schema's min/max and default. It does not explain the purpose of the display number or how to determine it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the windows present on an Xvfb virtual display,' which is a specific verb-resource combination that distinguishes it from sibling tools like list_windows and screenshot_virtual_display.
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 provided on when to use this tool vs alternatives, such as list_windows or list_child_windows, nor any prerequisites 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?
With annotations providing no destructive or idempotent hints (destructiveHint=false, idempotentHint=false), the description could add behavioral context. However, it only describes the basic action and omits potential side effects like focus disruption, despite the parameter 'confirm_focus_disruption' hinting at such behavior. No disclosure of behavior when start coordinates are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the purpose, followed by a standard Args/Returns structure. It wastes no words and front-loads the core action immediately.
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?
Given the tool has an output schema and moderate complexity (multiple optional parameters, a focus-disruption consent flag), the description lacks important context: no explanation of default button, default duration, start-from-current-cursor behavior, or the requirement to set confirm_focus_disruption after user consent. These gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema's parameter descriptions are not considered sufficient. The description adds minimal value by stating 'optional start, required end, button and duration,' which largely repeats parameter names. It does not explain the semantics of 'start_x' and 'start_y' being optional with current cursor fallback, or limitations like duration maximum.
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 'Press a mouse button at a start point and release it at an end point,' which unambiguously defines a drag operation. It distinguishes this tool from siblings like mouse_click and mouse_move by specifying the press-and-release sequence across two points.
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 using this tool when a drag action is needed, but does not explicitly state when to use it over alternatives such as mouse_click plus mouse_move, nor does it provide usage conditions or exclusions. It lacks guidance for 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutating (readOnlyHint false) and non-destructive behavior. The description adds that it returns updated geometry JSON or an error, but does not disclose potential failure modes or permission requirements beyond what is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with clear Args and Returns sections. No unnecessary verbiage, but the Returns could be inferred from the output 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?
Given the tool's simplicity (resizing a window) and the presence of detailed schema descriptions for parameters, the description is adequate but not thorough. It could mention how to identify the window (by title or handle) and that it uses case-insensitive substring matching.
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 tool description only mentions 'target window plus new width, height' without detailing the multiple ways to specify the window (title, handle, display) or their relationships. With 0% schema description coverage, the description fails to add meaningful context 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 clearly states 'Resize a window to a new width and height,' which is a specific verb and resource. It distinguishes from sibling tools like move_window (position) and hide_window (visibility).
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 does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites like having a window handle or title from list_windows. Usage is implied but not explicit.
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 description explains multi-key behavior and mentions background delivery via window handles is 'without focus'. However, annotations already indicate destructuring false, so safety profile is decent. The description does disclose the fallback approach (prefer_ahk) somewhat through schema. It adds that keys are delivered without focus for background targets, which is useful. There's no mention of focus disruption consequences, but the confirm_focus_disruption parameter exists in schema. Score 3: adds some behavioral context beyond annotations.
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 compact: a one-line purpose statement, a sentence about single vs multiple keys, and a brief note about background delivery appearing to be within arg descriptions. The 'Returns' line is redundant given the output schema exists. Overall efficient without bloat, appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich nested schema with 6 well-documented parameters including background targeting options (hwnd, window_title, display) and an output schema, the description covers the core purpose and multi-key semantics. However, it doesn't note the ahk_status/sibling relationship for AutoHotkey-dependent features. The description is adequate for most uses but doesn't differentiate from win_send_keys or type_text adequately in body text.
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%, meaning the input schema descriptions are the primary documentation. Each parameter (keys, hwnd, display, prefer_ahk, window_title, confirm_focus_disruption) has a detailed description in the schema itself. The tool description adds the multi-key combinational semantics and the pyautogui key name note, but these are also largely in the schema. Since schema covers parameters well despite 0% 'description coverage' metric (which refers to the tool description), the description adds marginal value over schema. Score 3: schema does most of the heavy lifting.
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 'Press a keyboard combination (hotkey), e.g. Ctrl+C or Alt+Tab' with a specific verb (press) and resource (keyboard combination/hotkey). It distinguishes from siblings like type_text (which types literal text rather than key combos) and win_send_keys by its explicit hotkey framing. Score 4: clear purpose, though it doesn't explicitly contrast with win_send_keys, which is a closely related 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 description states when to use it implicitly (to press hotkeys/combinations) but doesn't explicitly say when NOT to use it or name alternatives like win_send_keys. The sibling win_send_keys is very similar but the description provides no differentiation guidance. The single vs multi-element list semantics give functional usage guidance though. Score 3: functional guidance present, but no explicit alternative/exclusion 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 mark the tool as readOnlyHint=true and destructiveHint=false, indicating safe read behavior. The description adds that it captures the entire display and returns a JSON with dimensions, but no side effects are mentioned. With annotations covering the safety profile, the description provides modest additional context.
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 concise with two sentences plus an Args/Returns section, front-loading the action. Every sentence is functional, though the Args section could be integrated to reduce verbosity.
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 return format and scope (whole display) but omits prerequisites (e.g., virtual display must exist) and error conditions. Given the tool's simplicity and the presence of an output schema, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the two parameters (display number and output path) but does not add detail beyond what the input schema already provides (defaults, ranges, descriptions). With schema description coverage at 0% (though nested properties have descriptions), the description provides minimal extra meaning.
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 'Capture the whole Xvfb virtual display to a PNG' with a specific verb and resource, distinguishing it from the sibling 'screenshot' tool which likely captures the physical display. It leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., the plain 'screenshot' tool) or prerequisites (e.g., virtual display must exist). The description implies it is for Xvfb displays but does not explicitly state usage contexts.
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 indicate destructiveHint=true and readOnlyHint=false, which the description does not contradict. The description adds that output is captured (stdout/stderr/exit code), but lacks details on side effects, permission requirements, or error handling.
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 concise (two short blocks) and front-loaded with the core purpose. It could be slightly more structured (e.g., bullet list of args/returns), but it is efficient.
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 presence of an output schema (implied by context), the description already details the return format. It covers the key aspects: input params, output structure, and basic behavior. Minor omissions include error handling and prerequisites (e.g., distro existence).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for all parameters. The tool's description merely lists the parameters without adding new semantic info (e.g., default values or format constraints). With 0% schema description coverage (context signal), the description should compensate, but it does not go 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 clearly states the verb 'run' and the resource 'shell command inside a WSL distro', and specifies that it captures stdout/stderr/exit code. This differentiates it from sibling tools like run_command (host) and other WSL 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 on when to use this tool versus alternatives such as run_command or wsl_create_temp. The description does not mention 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 indicate destructiveHint=true, and the description mentions creating a display if needed, which is a destructive (state-modifying) action. The description also provides a return format example, which adds transparency. However, it does not disclose potential side effects, such as what happens if the display creation fails or if the command is already running. The description adds some context beyond annotations but could be more thorough.
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 short and to the point, with a clear one-line purpose and structured Args/Returns sections. There is no unnecessary information. However, the Args line is a bit vague and could be slightly expanded without losing conciseness.
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?
Given the complexity of launching a GUI app on a virtual display (including potential prerequisites like Xvfb installation, error handling, and interaction with other virtual display tools), the description is too minimal. It does not explain prerequisites, failure modes, or how it relates to sibling tools like 'create_virtual_display' or 'stop_virtual_display'. The return format example is helpful, but overall completeness is lacking for a tool with many siblings.
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's Args line says 'display number and command line', which is a brief restatement of the schema's property descriptions. The schema already includes descriptions for 'command' and 'display', so the description adds minimal additional meaning. Context signals show 0% schema description coverage, but the actual schema has descriptions, making this a borderline case. The description does not provide formatting or constraints beyond what the schema offers.
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 'Launch a GUI app on an Xvfb virtual display (creates it if needed)', which is a specific verb-resource combination. It distinguishes from sibling tools like 'create_virtual_display' (which only creates the display) and 'launch_on_headless_desktop' (which launches on a headless desktop, not virtual display).
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 that this tool can create a virtual display if needed, so it can be used instead of creating a display separately. However, it does not explicitly state when to use this tool versus alternatives like 'launch_on_headless_desktop' or 'run_command', nor does it mention any prerequisites or conditions. With 51 sibling tools, more explicit guidance would be beneficial.
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, covering the safety profile. The description adds useful context about it being scoped to top-level windows on an off-screen desktop and details the return JSON shape (handle, process_id, thread_id, dpi, title, class, width, height). It doesn't contradict annotations.
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 compact with a one-line purpose statement followed by Args and Returns sections. It's front-loaded with the action and is efficient, though the Args section is redundant given the schema already documents the parameter.
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 output schema is present, so return-value documentation in the description is bonus context, not a requirement. Annotations cover safety and idempotency. The description adequately clarifies the tool is for off-screen desktop windows and lists the exact return fields, which disambiguates it from list_windows. For a simple 1-parameter read-only listing tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter meaning burden. It explains 'desktop name' as a single-line mention in Args, which maps to the HeadlessDesktopInput.name parameter. The description adds minimal value beyond schema—the schema itself describes name as 'Name of the off-screen desktop' with a default, which actually covers the semantics reasonably well.
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 'List the top-level windows living on an off-screen desktop' with a specific verb+resource pair. It distinguishes itself from sibling list_windows (which likely lists on-screen) and list_child_windows (child, not top-level). However, it doesn't explicitly name alternatives for purposes of differentiation.
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—that it lists top-level windows on an off-screen desktop—but provides no explicit when-to-use vs when-not-to-use guidance or mention of alternatives. Sibling tools include list_windows and list_child_windows, but the description doesn't call out when to choose this one over those.
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 context that apps are terminated, which annotations (destructiveHint, idempotentHint) do not cover; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded main action, but includes docstring-style Args/Returns formatting that adds little value for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, input parameter, and return format; sufficient for a simple tool with one parameter and output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description merely says 'display number', matching the schema property description; no added meaning for the default or usage 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?
Explicitly states it stops an Xvfb virtual display and terminates its apps, distinguishing it from create/launch 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 guidance on when to use vs alternatives like close_headless_desktop or stop_screen_recording; no when-not-to-use 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 declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. The description doesn't contradict annotations. It adds that the payload is base64-encoded, which is useful. However, it doesn't disclose whether existing files at the path are overwritten, whether directories must pre-exist, permission requirements, or what the output schema / return value indicates.
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?
Single sentence, zero wasted words. Effectively front-loaded with the core purpose. 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?
With an output schema present and a 2-parameter tool, this is a relatively simple operation. The description captures the core write operation, base64 encoding, and destination. However, for a destructive operation (destructiveHint=true), the description could note overwrite behavior or confirm-the-target-before-writing guidance. The simplicity of the tool doesn't warrant a higher score given the missing edge-case behavioral 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 0%, so the description carries the full burden for parameter semantics. The description does clarify that content_base64 is a base64-encoded payload, which matches the schema field description. However, it doesn't clarify path semantics (absolute vs relative, format requirements) beyond what the schema's 'Destination path on the controlled computer' already states. The description adds minimal value over the schema field descriptions.
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 'Write a base64 file payload to the controlled computer' uses a specific verb (write) and resource (file payload to controlled computer), distinguishing it from sibling download_file (which reads from the computer). The verb 'write' makes the write-vs-read contrast clear against download_file. It doesn't explicitly say 'upload' but the tool name makes that obvious.
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 this is for writing files to the remote machine, contrasting with download_file which pulls files. However, there's no explicit when-to-use guidance, no fformat/path conventions, no note about overwrite behavior or directory creation requirements. The context is clear but exclusions are not stated.
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, destructiveHint=false, and idempotentHint=true, so the safety profile is well covered. The description adds the 50 MiB size cap and base64 encoding format, which are genuinely useful behavioral details beyond annotations. Does not disclose what happens on large files (error vs truncation), a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the core action ('Read a file') followed by format and size limit. 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?
An output schema exists and the tool has one simple parameter. The 50 MiB limit and base64 format are the key constraints, both disclosed. With a read-only, idempotent tool and rich annotations, the description covers the operational essentials well. Could mention upload_file as the inverse counterpart for discoverability.
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 compensates minimally by naming 'base64' encoding and the 50 MiB limit. However, only one 'path' parameter exists, and its schema description ('Source path on the controlled computer') already conveys its meaning clearly. With a single well-described param, the description's marginal value is limited but adequate.
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 states 'Read a file from the controlled computer as base64' — specific verb (read/download) + resource (file) + direction (controlled computer) with size limit. It clearly complements the sibling upload_file. Could marginally improve by noting the file is transferred to the agent, but 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance or exclusion criteria. Context implies it pairs with upload_file (the inverse direction), but no alternative or caveat is mentioned. For a simple read tool, this is acceptable but not explicit.
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 are present and not contradicted. The description adds that scrolling is vertical and amount direction, but does not detail edge cases or the optional move 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, front-loaded with action, no unnecessary words.
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?
Missing important parameters (instant_move, move_duration, confirm_focus_disruption) that affect behavior. Simple tool but description is incomplete.
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 parameters with high coverage; the description simply restates amount direction, adding minimal 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 clearly states the tool scrolls the mouse wheel vertically, and distinguishes it from sibling mouse actions like mouse_move, mouse_click, and mouse_drag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for vertical scrolling but provides no explicit when-to-use or alternatives. No exclusions are 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 already indicate non-readonly, non-destructive, and idempotent behavior. Description adds minimal extra context (error on not found) but does not elaborate on side effects or prerequisites. 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?
Three concise sentences, front-loaded with purpose, efficient identification guidance, and brief args/returns. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple input schema and existence of output schema, the description covers essential aspects (purpose, identification, return value). Missing edge cases like priority when both handle and title are provided, but overall sufficient.
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 covers all parameters with descriptions. The description adds value by recommending handle over title and clarifying substring matching, but does not address x, y, or display. Partial coverage; baseline 3 adjusted upward slightly for the added hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a window to a new top-left screen position, specifies identification methods (handle or title), and distinguishes from related tools like resize_window. Verb and resource are specific.
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 on when to use move_window versus sibling tools (e.g., resize_window, show_window). The only usage advice is to prefer handle over title, but no when-to or when-not-to context.
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 provide destructiveHint=true and idempotentHint=true. The description adds that the action is irreversible and deletes files, but does not disclose additional traits like permission needs or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, args, returns. Concise, front-loaded, with no unnecessary information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with annotations and output schema, the description is adequate. It covers purpose, input, and output. Could mention error handling or edge cases, but overall 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 summarizes the parameter as 'distro name and whether to delete files,' but the input schema already provides detailed descriptions for each property. With schema coverage per property, the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool terminates and unregisters a WSL distro and deletes its files, specifying the action and resource. It distinguishes from siblings like wsl_destroy_all_temp and wsl_list_distros.
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 does not provide guidance on when to use this tool vs alternatives, nor does it mention prerequisites or contexts. It only notes irreversibility, lacking explicit when/when-not information.
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 and idempotent behavior. The description adds context about process dependency and the condition for full desktop freeing, which goes beyond annotations.
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 concise (4 sentences) with a clear structure: purpose, condition, prerequisite, and Args/Returns block. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, prerequisite, and return format. However, it omits the default parameter value and its relationship to sibling tools like 'create_headless_desktop'.
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%, yet the description only provides a one-line explanation ('desktop name') without detailing allowed values, defaults, or validation 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 clearly states the action ('Release this server's handle') and the resource ('off-screen desktop'), distinguishing it from siblings like 'create_headless_desktop' and 'hide_headless_desktop'.
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 a prerequisite ('close any apps you launched there first') but does not explicitly guide when to use this tool over alternatives or when to avoid it.
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, openWorldHint=true, and destructiveHint=false, fully covering the safety profile. The description adds minimal behavioral context beyond annotations—the 'owned by this server process' scoping note is a small addition. Since annotations carry most of the burden here, a 3 is appropriate; the description confirms the read-only listing behavior but doesn't add detail about return format or edge cases.
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 description, no waste, perfectly sized for a parameterless listing tool. Every word adds value, including the 'owned by this server process' qualifier which conveys an important scoping distinction.
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 list tool with an output schema present and comprehensive annotations (readOnly, idempotent, openWorld, non-destructive), the description is complete. The output schema handles return value documentation, and annotations handle safety semantics. The description only needs to state the purpose, which it does adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden for the schema or description. The baseline for 0-param tools is 4 per the rubric. The description correctly implies no inputs are needed for this operation.
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 'List all headless desktops owned by this server process' has a specific verb (List), a clear resource (headless desktops), and a scoping qualifier ('owned by this server process'). It clearly distinguishes from siblings like 'create_headless_desktop' and 'list_windows'. A slightly higher score would require naming specific sibling alternatives or return characteristics.
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 conveys its purpose clearly but provides no exclusions or alternative tool guidance. With a large sibling set around headless desktops (create, close, show, hide, launch_on, list_windows), an explicit statement of when to use this versus related list tools would strengthen it. The 'owned by this server process' qualifier implies scope distinction from other listing tools, giving some 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 provide limited behavioral info (readOnlyHint=false, destructiveHint=false). Description adds that it works without focusing, but does not disclose side effects, error handling, or permissions. 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?
Extremely concise: two sentences plus Args/Returns. Front-loads key purpose and usage hint. No superfluous text.
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?
Covers basic purpose and usage, but lacks explanation of parameter relationships (e.g., control vs. window), timeout behavior, and output details. Output schema exists but description only says 'JSON with the AHK run result'. Satisfactory for single-param tool with rich 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%, so description must compensate, but it merely lists parameter names without adding meaning. The input schema itself has descriptions, but the tool description offers no additional semantics or context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sends text/keystrokes to background windows via AutoHotkey ControlSend, distinguishes from siblings by emphasizing background operation and reliability over WM_CHAR. Explicitly mentions targeting via 'ahk_id <handle>'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use (background windows, complex apps) and advantages over WM_CHAR, but does not explicitly state when not to use or compare with siblings like win_send_keys. Implied differentiation is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotent behavior ('Existing names are reopened safely'), which is valuable beyond annotations. Annotations already declare idempotentHint=true, readOnlyHint=false, destructiveHint=false, openWorldHint=true — the description adds the 'reopened safely' semantic, reinforcing what actually happens on name collision. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action. Second sentence is clear usage guidance; third is brief. Concise, but no trailing examples or structural formatting beyond a plain paragraph. No waste, but minimal structure.
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?
Has output schema, annotations, and idempotent hint. Description covers the main multi-agent scenario and naming guidance. For a moderately complex tool (3 params, array type), the description plus annotations are reasonably complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description carries full burden. The description explains the prefix/names relationship ('Use a project/agent-specific prefix or explicit names') and mentions generated naming, but doesn't elaborate on the count/names/prefix interplay in detail. It adds some meaning but leaves edge cases unexplored; schema has decent descriptions though coverage signal says 0%.
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?
Clear verb+resource: 'create several independent off-screen desktops.' Distinguishes from sibling 'create_headless_desktop' (singular) by emphasizing 'several' and 'one request.' Doesn't explicitly name the sibling alternative, but the plural/singular difference is evident.
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?
Gives clear context: use prefix/names when several agents share a Windows session. Implies the when-to-use scenario for naming conventions. Doesn't explicitly contrast with create_headless_desktop (single) but the 'one request' for multiple distinguishes it.
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 non-destructive, so the safety profile is clear. The description adds the return format (JSON with ok, available, version) but does not disclose additional behavioral traits like potential errors or network dependencies. This is adequate given the rich annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one for purpose and one for return type. Every word serves a purpose, and it is front-loaded with the key action.
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 tool with an output schema, the description adequately covers what it does and what it returns. It could mention that it only works on Windows or if WSL is installed, but these are implied by the tool name and context. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds no parameter-specific meaning, but the baseline for zero parameters is 4. No issues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Report whether WSL is available on this Windows host.' The verb 'Report' and the specific resource 'WSL availability' are explicit. It distinguishes from sibling tools like 'linux_status' and other WSL tools by focusing on availability status.
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 provided on when to use this tool versus alternatives such as 'linux_status' or 'wsl_list_distros'. The description does not suggest checking WSL availability before using other WSL tools, nor does it mention conditions to avoid using 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 mutations and side effects. The description adds value by explaining that apps have a real GUI but are invisible, can be automated via PrintWindow, and includes return behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes args/returns in a clear structure. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers creation, behavior, parameters, and return format. It lacks prerequisites or error handling but is mostly 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 rephrases the parameter as 'desktop name', which adds minimal value beyond the schema's own description. The schema coverage is 0%, but the description doesn't fully compensate.
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 'Create an off-screen Win32 desktop' with a specific verb and resource. It distinguishes from sibling tools like close, hide, show, and launch by focusing on creation.
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 use for running GUI apps invisibly and mentions 'headless but with GUI' mode, but it does not explicitly compare with alternatives like create_virtual_display or provide 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?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds value by explaining the tool starts a real X server and returns a structured JSON with display info, PID, etc. It also mentions automation and screenshotting capabilities beyond 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 concise and well-structured: a one-sentence purpose, a paragraph on usage context, and a clear parameter/return section. It front-loads the core action and is free of unnecessary 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?
Given the tool's moderate complexity, the description together with annotations and schema provides sufficient information for an AI agent. It covers purpose, usage context, parameters, and return value. Minor omission: does not mention prerequisite (Xvfb must be installed) or platform (Linux), but these are implied by the tool's nature.
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 only lists parameter names and types ('display number, width, height, depth'), adding no meaning beyond what the input schema's property descriptions already provide. Since the schema descriptions are detailed (coverage 100% per schema, though context says 0%—likely referring to the description text not covering parameters), the description adds minimal value.
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 starts an Xvfb virtual display for headless GUI operation. It distinguishes from siblings by noting it's the Linux counterpart of Windows headless desktop and is used for automation and screenshotting, though could more explicitly contrast with the sibling 'create_headless_desktop'.
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 when you need to run GUI apps headlessly for automation or screenshots. It explains the benefit (no visible desktop occupation) but does not explicitly state when not to use or list alternative 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 provide idempotentHint=true and destructiveHint=false. The description adds the return format and confirms cropping is non-destructive. No additional behavioral details (e.g., overwrite behavior, error handling) are given beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with the action. Every sentence adds value—definition, parameter summary, return format—with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with schema and annotations, provides sufficient information for a basic crop operation. Missing details like error cases, format limitations, or coordinate validation, but it is largely complete for a simple 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 coverage is 100% with each parameter described. The description merely summarizes the parameters (source path, crop box, output path) without adding new semantics or constraints. 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 clearly states 'Crop an existing image file to a rectangular sub-region,' specifying both the action (crop) and the resource (image file). There are no sibling tools with similar functionality, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of sibling tools being all about window/process management makes the usage context clear. However, no explicit when-to-use or when-not-to-use guidance is provided, nor are there prerequisites mentioned.
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 idempotent and non-destructive behavior. The description adds context on how hiding works (via hwnd/title, minimize option) and the return format, providing additional behavioral insight beyond 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 efficiently cover purpose, usage example, parameters, and return format. No filler, front-loaded with key 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?
Given the tool's simplicity, annotations, output schema, and sibling tools, the description provides sufficient context: purpose, parameter overview, return format. It could mention prerequisites (e.g., window must exist) but omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the window can be identified by hwnd or title and includes a minimize flag, but does not mention the display parameter. Schema descriptions for parameters are present and detailed, but the tool description covers only part of the parameters. With schema description coverage at 0%, the description should compensate more fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Hide a window again after it was shown', using a specific verb and resource. This distinguishes it from sibling tools like 'show_window' and 'hide_headless_desktop'.
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 after showing a window (e.g., after login), but does not explicitly state when not to use it or compare to alternatives. No exclusion criteria or guidance on choosing between hiding vs minimizing vs closing.
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 show readOnlyHint=false and destructiveHint=false. The description adds that background targeting uses PostMessage and does not bring the window to the foreground, and that foreground clicks confirm focus disruption. This provides behavioral context beyond the minimal annotations.
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 well-structured with a main action sentence, a usage example, and a background targeting section. It is slightly verbose but front-loaded with the core behavior. Every sentence adds value, though it could be more concise.
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 complexity (11 parameters) and minimal annotations, the description explains the two main click modes (foreground vs background) and the confirm_focus_disruption requirement. However, it is incomplete: it does not cover parameters like button, display, interval, instant_move, or move_duration, nor does it describe the return value in detail despite an output schema existing.
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% (the tool description covers few parameters). The description adds meaning for x, y, clicks, hwnd, and window_title (e.g., 'omit to click at current cursor', '2 = double-click'), but omits details for button, display, interval, instant_move, move_duration, and confirm_focus_disruption, leaving the agent to rely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Click a mouse button, optionally at a specific coordinate', specifying the verb and resource. It distinguishes background targeting (via hwnd/window_title) from foreground clicks, differentiating it from sibling tools like mouse_move, mouse_drag, and mouse_scroll.
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 when to use background targeting (hwnd/window_title) vs foreground clicks, and mentions the confirm_focus_disruption parameter for foreground clicks requiring user consent. It does not explicitly state when not to use this tool (e.g., for dragging), but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: UAC prompt on elevation, output format with JSON fields, and a warning about full administrative rights. Annotations already indicate destructiveHint=true, and the description adds context beyond that, though it could detail the confirm_focus_disruption parameter's role.
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 highly concise: two sentences of purpose, then a structured Args/Returns section. Every sentence adds value with no fluff. Front-loaded with the core action.
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 UAC trigger, output format, and a cautionary note. It includes a return type with JSON fields, which is helpful. However, it omits details about timeout behavior or error handling, leaving some gaps for a complex elevated command tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters (command, timeout, confirm_focus_disruption), but the tool description only mentions 'command line and a timeout' in the Args section. While schema coverage is high, the description adds minimal extra meaning beyond a quick summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a shell command with Administrator privileges, distinguishing it from the sibling tool 'run_command' by specifying elevation. It includes details about UAC prompts and output capture, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (when admin rights needed) but does not explicitly contrast with the non-admin sibling 'run_command'. It mentions UAC prompt behavior but no direct 'use this instead of run_command' 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 readOnlyHint and idempotentHint, so the description's addition of return format (JSON with windows details) and filtering options adds useful behavioral 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 concise (two sentences plus a structured Args/Returns section) and well-organized, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema descriptions for parameters, the detailed output format provided in the description, and the simple nature of a list tool, the documentation is fully adequate.
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 already provides descriptions for the two sub-properties (title_filter and include_empty_titles), covering 100% of parameter semantics. The description merely echoes the schema, adding no extra meaning, so 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 clearly states the tool lists 'top-level windows' with specific attributes (titles, handles, positions, sizes), distinguishing it from sibling tools like list_child_windows and list_virtual_display_windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as list_headless_windows or list_virtual_display_windows. Usage is implied by the 'top-level windows' scope, but no exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description adds context about termination requirements and timeout behavior. It explains how to get output and that scripts can perform system actions, complementing 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that covers purpose, usage, and return value without fluff. It is well-organized and front-loaded with the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers input, behavior, output, and prerequisites. The output schema is described in the return section, and the schema documents parameters adequately.
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 briefly mentions parameters (script source, args, timeout, exe path) but does not add significant meaning beyond the schema, which already has detailed descriptions for each parameter. Schema coverage is considered high.
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 'Run an inline AutoHotkey script and capture its output', which is a specific verb+resource. It distinguishes from siblings like ahk_control_send by focusing on running arbitrary scripts.
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 that scripts must terminate or timeout, how to emit output (FileAppend to '*'), and suggests use cases (background input, real hotkeys). It does not explicitly exclude alternatives but provides good 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 destructiveHint=true and readOnlyHint=false. The description adds context: 'close is destructive - it sends the window a close request and the app may prompt to save.' This goes beyond annotations by explaining the actual behavior of close. No contradictions.
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 concise at three sentences plus a block of parameter details. It front-loads the core action list. Every sentence adds value, though the parameter list could be integrated more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, multiple identification methods, platform-specific parameters), the description covers the main aspects: actions, identification, destructive warning, and output format. It is reasonably complete for effective use.
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 0%, so the description bears the full burden. It clarifies that handle and title are alternative identifiers, mentions display is Linux-only, and explains confirm_focus_disruption requires explicit user consent. This adds substantial meaning beyond the schema's basic property 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 tool's purpose: to focus, minimize, maximize, restore, or close a window. It lists all actions and specifies window identification via handle or title. This distinguishes it from sibling tools like move_window or resize_window.
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 basic usage guidance (identify window by handle or title) and warns about close being destructive. However, it does not explicitly state when to use this tool versus alternatives like move_window or resize_window, nor does it mention prerequisites beyond window identification.
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 provide readOnlyHint, idempotentHint, and destructiveHint. Description adds the return format (JSON with ok, count, distros), but no additional behavioral traits beyond what annotations imply.
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?
Extremely concise: two sentences, front-loaded with purpose, then return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an output schema, the description is complete. It explains the return structure adequately.
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?
No parameters (schema coverage 100%), so description doesn't need to add param info. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List installed WSL distros with state, version and default flag', which is a specific verb+resource and distinguishes it from sibling tools like wsl_destroy or wsl_run.
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?
No explicit guidance on when to use or when not to use this tool; however, for a simple listing tool, usage is self-evident from the purpose. Could mention alternatives like wsl_status for different views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it modifies state but is not destructive. The description adds that it restores the normal desktop, and specifies the return format. This adds context beyond annotations, though it doesn't detail side effects or 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?
The description is extremely concise: a single clear sentence for purpose, followed by structured Args and Returns sections. Every sentence is necessary, and the main action 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?
The description provides the essential information: what it does, when to use it, the parameter, and the return value. It lacks explicit information on error cases or preconditions, but for a simple paired tool this is sufficient.
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 the 'name' parameter as 'Name of the off-screen desktop'. The description adds 'for symmetry' which is a small extra context, but not significant enough to raise the score above baseline given the lone parameter and schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('switch the live screen back to the normal desktop'), the resource ('live screen'), and the context ('after show_headless_desktop'). It clearly differentiates from the sibling tool show_headless_desktop.
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 by stating 'after show_headless_desktop', implying when to use it. It does not explicitly state when not to use it or provide alternatives, but the pairing is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint, idempotentHint), the description adds critical behavior: default runs without elevation, launches via pythonw.exe with no terminal/focus change, and details the return JSON format. Also explains the UAC prompt requirement for run_as_admin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, then details, then args/returns. Every sentence adds value, 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?
The description covers what the tool does, defaults, security implications (elevation, UAC), and return format. Missing are error cases or preconditions (e.g., user must be logged in), but overall it is fairly complete for the complexity level.
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 only lists parameter names (run_as_admin, http, host, port) without adding value beyond the schema's detailed descriptions. Schema coverage from tool description is 0%, but the schema itself has good descriptions, so baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'install' and resource 'scheduled task' with outcome 'starts automatically at user logon'. It distinguishes from sibling tools like uninstall_startup and startup_status by focusing on installation.
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 explains default behavior (no elevation, HTTP mode) but does not explicitly state when to use this tool versus alternatives like uninstall_startup or startup_status. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: bringing a window to foreground for human interaction. Annotations already indicate non-destructive and idempotent behavior, so the description complements but does not significantly extend transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then usage context, then parameter and return details. Every sentence adds value without 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?
The description covers the main use case and return format, but it omits details about the 'confirm_focus_disruption' parameter and potential error conditions. The existence of an output schema mitigates the lack of return value details.
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 itself provides detailed descriptions for each parameter. The description's summary ('the window by hwnd or title') adds little beyond the schema, 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 clearly states the tool's purpose: 'Make a hidden/minimized window visible and bring it to the foreground.' It also provides a specific use case (interactive LOGIN) and distinguishes itself from sibling tool 'hide_window'.
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 when to use the tool (for human-interaction steps like LOGIN) and references the sibling 'hide_window' for after use. However, it does not explicitly list when not to use it or compare with other window 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?
The description discloses the return format (JSON with ok, path, frames, duration_seconds), adding value beyond annotations. Annotations indicate non-destructive and non-read-only, which aligns with the description. No behavioral traits are contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes return format. Every sentence is necessary and without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, existing annotations, and an implied output schema (described in text), the description is largely sufficient. However, it does not explicitly state that a recording must be active, which is implicit.
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?
No parameters exist, so schema coverage is 100%. The description does not need to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop the active screen recording') and the resource ('screen recording'), and mentions finalizing the mp4 file. It is distinct from siblings like start_screen_recording and recording_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 description does not explicitly state when to use this tool versus alternatives. It implies usage after starting a recording but provides no explicit guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds context about no UAC prompt and elevated server requirement, enhancing transparency beyond annotations.
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?
Two concise sentences plus return format. No wasted words, but could be slightly more structured (e.g., separating description from return).
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 zero parameters and a simple action, the description fully covers purpose, behavioral caveats, and return format. No output schema exists, so the inline return string is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to add parameter meaning. Schema coverage is 100% by default. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove user startup' with a specific verb and resource. It also differentiates from siblings like install_startup and startup_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 description mentions a condition ('elevated tasks may require an elevated server') but does not explicitly state when to use this tool over alternatives or provide 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?
Annotations already declare destructiveHint=true, and the description reinforces this with 'tear down.' It clarifies the scope ('this session') and return format (JSON with destroyed list and count), adding value beyond annotations. However, it doesn't mention side effects like stopping running processes or deleting files, which would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and one for returns. No redundant information, front-loaded with the action. Every word serves a purpose.
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 tool with an output schema (specified in description), the description covers purpose, scope, and return format. It lacks details on idempotency (though annotation hints true) or potential impact on currently running distros, but is mostly complete for a simple cleanup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters; the input schema is empty with 100% coverage. The description does not need to add parameter meaning. Baseline 4 is appropriate as no additional semantic context is required.
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 'Tear down every throwaway distro provisioned in this session,' using specific verb and resource. Among sibling tools like wsl_destroy (for individual distros) and wsl_list_temp (listing), this tool is uniquely identified for mass cleanup, fulfilling purpose clarity at the highest level.
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 use for session cleanup but does not explicitly state when to prefer this over wsl_destroy (for single distro) or when not to use it (e.g., if only one temp distro needs removal). No guidance on context or alternatives is provided, making it merely adequate.
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, destructiveHint false. The description adds that the tool returns a JSON string with specific fields (ok, count, distros with name, install_dir, source, created_at), providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences), front-loading the core purpose and then specifying the return format. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description covers its purpose and return value well. However, it could mention that the list may be empty if no temp distros exist, but this is minor.
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 input schema has zero parameters, so schema coverage is 100%. With no parameters, the description does not need to add parameter details; baseline is 4 for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'throwaway distros this server session provisioned', specifying the resource (temp distros) and scope (session-provisioned). This distinguishes it from siblings like wsl_list_distros (likely all distros) and wsl_create_temp.
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 listing temporary distros but does not explicitly state when to use this tool over alternatives like wsl_list_distros or when not to use it. No exclusions or prerequisites are mentioned.
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 readOnlyHint and idempotentHint, and the description adds details about the JSON return structure including ok, installed, path, version, enhancing transparency beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, effectively communicating purpose and return format in a single sentence plus output example.
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 status-check tool with no parameters and a simple output, the description is complete: it states what it does and what it returns, sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to add parameter meaning. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports AutoHotkey installation status and location, which is a specific and distinct purpose from sibling tools like run_ahk or ahk_control_send.
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 before running AHK scripts, but provides no explicit guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds return format details, though it says 'JSON like' which is slightly imprecise. Overall, sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with no wasted words. The return format is included in the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool, the description covers purpose and return format. No gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so no additional info needed. Schema coverage is 100%, baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the primary screen resolution in pixels. Verb 'return' and resource 'screen size' are specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or when not; no alternatives mentioned. However, the tool is self-explanatory and straightforward.
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. The description adds useful behavioral context: it returns a JSON string with specific fields ('ok', 'is_admin', 'platform') and notes the platform is Windows. This goes beyond the annotations by detailing the exact return format and platform specificity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that directly state the purpose and return format. It is front-loaded with the key action and resource, with no unnecessary words. Every sentence adds value.
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 no parameters and the presence of an output schema (mentioned in context), the description is complete. It specifies the platform, return format, and purpose. No additional context is needed for an agent to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no parameter information, which is acceptable because none are needed. The baseline for zero parameters is 4, and the description does not detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reporting whether the process is running elevated (as Administrator). It uses a specific verb ('Report whether') and specifies the resource ('server process' running elevated). Among siblings, it uniquely identifies admin status checking, distinguishing itself from action-oriented tools like 'run_command_as_admin'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies use for checking admin status, but no exclusions or context-specific recommendations are given. Since the purpose is clear, the lack of usage guidance is a minor gap.
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; description adds value by explaining the two-step graceful-then-force behavior and warns about data loss. No contradictions.
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?
Very concise: 5 sentences. Each sentence contributes: purpose, parameter guidance, behavior, warning, and return type. Well-structured and easy to scan.
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?
Covers all essential aspects: what it does, how to use it (two parameters alternatives), destructive nature, and return format. Output schema exists, so description doesn't need to elaborate on results. Complete 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 descriptions cover all parameters (100% coverage), but the tool description adds nuance (preferred pid, kill hard vs graceful). Baseline 3 with high schema coverage, and description provides moderate additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb and resource ('Kill a process'), specifying two methods (by PID or exact name), which distinguishes it from sibling tools like list_processes. No 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?
Explicitly states to provide 'pid' (preferred) or 'name', and describes the force flag usage. Lacks explicit when-not-to-use, but the context is sufficient for typical process killing tasks.
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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds details about the return format (parent_hwnd, count, children with coordinates relative to parent) and identifies the parent window by hwnd or title, enhancing transparency beyond 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 concise with two paragraphs plus structured Args and Returns sections. It front-loads the purpose immediately and uses bullet-point-like return description for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers purpose, usage, return format, and coordinate system completely. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'parent window by hwnd or title' but does not elaborate further on parameter fields. The input schema provides descriptions for hwnd, display, and window_title, so the description adds minimal 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 clearly states it enumerates child controls of a window, listing class, text, client rect, and handle. It distinguishes from sibling tools like list_windows (top-level) and other control manipulation 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 explains it is useful for finding exact control handles for background input, with a concrete example (Notepad's Edit control). It lacks explicit when-not-to-use instructions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds the return format (JSON with ok, count, processes array) which provides useful behavioral context beyond 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 concise (two sentences plus a blank line) with front-loaded purpose. Every sentence adds value: purpose, params summary, and return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and comprehensive annotations, the description covers purpose, parameters, and return format. An output schema exists but the description already explains the return structure, making it 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 0% because the description only summarizes parameters ('optional name filter, sort key and limit') without adding detail beyond the schema's own property descriptions. Since schema coverage is effectively high, baseline 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 clearly states 'List running processes with pid, name, memory and CPU usage.' This is a specific verb-resource pair that distinguishes from sibling tools like kill_process which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about what the tool does but does not explicitly state when to use it versus alternatives. However, by naming the output and parameters, usage context is implied.
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. The description adds value by specifying the exact JSON return structure with fields like 'ok', 'recording', 'path', 'frames', and 'elapsed_seconds', which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose in the first sentence, and the return format is clearly listed. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a well-described output format (including the return structure), the description is fully complete. The return specification is detailed enough for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100%. The description does not need to add parameter details. Baseline is appropriately high since no parameters exist.
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 'Report whether a screen recording is currently active.' This is a specific verb+resource combination that distinguishes this tool from siblings like start_screen_recording and stop_screen_recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Usage context is implied but not directly addressed.
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=true and destructiveHint=false. The description adds valuable context about background capture behavior (using PrintWindow) and file saving, without contradicting 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 concise with front-loaded purpose, then a key behavioral detail (background capture), and structured args/returns. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with multiple parameters, background capture capability, and a return value, the description covers all essential aspects: purpose, special behavior, input summary, and output format. No significant gaps.
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%, meaning the description does not add additional parameter details beyond the schema. However, the schema itself provides extensive descriptions for each parameter. The description summarizes parameters but adds no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of a monitor or pixel region and saves it as PNG, with specific emphasis on background capture via hwnd or window_title. This distinguishes it from siblings like screenshot_virtual_display, which targets virtual displays.
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 when to use background capture (unfocused, occluded, off-screen windows) but does not explicitly compare to other screenshot tools or state when not to use it. It provides clear context for a specific use case.
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 non-readonly and non-destructive behavior. The description adds important context: the entire off-screen desktop becomes interactive, a non-dismissible banner with instruction and emergency exit appears, and that the tool is meant for human interaction. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It starts with the primary action, then explains details in a structured manner. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description combined with annotations and output schema (described inline) provides sufficient information for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'desktop name and banner instruction' which covers two of the three parameters. However, it does not describe 'confirm_focus_disruption'. The input schema has descriptions for each property, so the description adds some value but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Temporarily switch the live screen to a headless desktop for human interaction.' It specifies the resource ('live screen') and distinguishes from sibling tools like 'hide_headless_desktop' by referencing 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 description explains when to use the tool (e.g., for LOGIN or manual steps) and mentions the emergency exit and normal restoration via 'hide_headless_desktop'. It provides context but does not explicitly list when not to use it or compare to other headless desktop 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 show non-read-only, non-destructive, non-idempotent. The description adds that recording runs in a background thread, only one at a time, and the return format includes path, fps, and status. This adds behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus structured Args/Returns. Every sentence carries essential information, and the important constraint (single recording) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of output schema, the description covers all key aspects: purpose, single-recording constraint, companion tool, background execution, and parameter summary. No missing critical information.
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% (the tool description does not repeat schema details), but the schema itself has detailed descriptions for each parameter. The tool description just lists parameter names and marks some as optional, which adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Begin recording the screen to an mp4 file in a background thread.' It specifies the resource (screen), the output format (mp4), and provides enough context to distinguish it from siblings like stop_screen_recording and screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Only one recording can run at a time' and directs to call stop_screen_recording to finish. This gives clear usage context and the companion tool, though it does not describe alternatives for similar actions.
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 strong read-only and idempotent hints. The description adds the return format details (JSON keys: ok, installed, details, task_name) beyond what annotations state, offering transparency about the output structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two clear sentences with no unnecessary words. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema shown but description covers the return structure. Given the context and sibling tools, the description is complete enough for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. The description does not need to explain parameter meanings as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the status of a boot-startup scheduled task, specifying both the verb ('Report') and the resource ('boot-startup scheduled task'). It distinguishes itself from sibling tools like install_startup and uninstall_startup.
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 checking status before installation/uninstallation but does not explicitly state when to use it or provide alternatives. There is no mention of 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 indicate readOnlyHint, idempotentHint, and destructiveHint are false. The description adds value by specifying the exact items checked (xdotool, wmctrl, Xvfb) and the return format (JSON with boolean flags).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence and a return type definition, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, annotations provide a full safety profile, and the description completely explains the return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so no additional explanation is needed. The description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports Linux X11 automation tooling availability, listing specific tools like xdotool and wmctrl. This distinguishes it from sibling status tools like ahk_status and wsl_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 description implies usage as a check before using Linux X11 automation tools, but it does not explicitly state when to use or avoid it, nor does it contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly and non-destructive. Description adds behavioral context: 'downloads tiny Alpine minirootfs', 'imports it', 'leaving existing distros untouched'. No contradiction; could mention network/disk usage but sufficient 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?
Description is concise (4-5 sentences), front-loaded with purpose, and efficiently covers key behaviors, alternatives, and return format. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behavior, alternatives, companion tools, and return format (output schema). Missing error cases and prerequisites (e.g., WSL installed), but openWorldHint reduces expectation. Complete for typical 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?
Input schema has full descriptions per parameter. Description lists parameters but adds little beyond schema, except noting 'optional' and 'default Alpine' for rootfs_url. Schema coverage is high, so baseline 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 the specific verb 'provision' with the resource 'throwaway WSL distro'. It clearly distinguishes the tool's purpose from siblings like wsl_run and wsl_destroy, and explains default behavior vs alternatives (clone_from, base_tar).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('to run Linux software', 'throwaway'), provides companion tools (wsl_run, wsl_destroy), and describes alternatives (clone_from, base_tar) with clear context about default Alpine download.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true. The description adds substantial behavioral detail: returns JSON with title, handle, position, size, or null if none active. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a code block showing return format. Every sentence is necessary and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, annotations covering safety, and a description that fully explains return values (with an example), the tool is complete. Output schema exists but description supplements it adequately.
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?
Tool has 0 parameters, baseline 4 per scoring guidelines. Description adds no parameter info, but none is needed. Schema coverage is high, so baseline 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 clearly states 'Return information about the currently focused (active) window,' using a specific verb and resource. It distinguishes from sibling tools like list_windows or get_cursor_position by focusing on the active window.
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 when needing active window details but provides no explicit guidance on when to use this versus alternatives like list_windows or get_screen_size. No exclusions or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it creates the desktop if needed, runs a full GUI on the hidden desktop, and never touches the visible desktop. This aligns with the destructiveHint annotation and provides valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs and an args/returns section. Every sentence adds value, and the main action is front-loaded. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, clear behavior) and the presence of an output schema (implied by return format), the description is complete. It explains the launch process and subsequent operations, covering all necessary guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'desktop name and command line' for parameters, but the input schema already provides similar minimal descriptions. The description does not add extra meaning beyond what the schema provides, so it meets the baseline expectation.
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 it launches a GUI application on an off-screen desktop, creating the desktop if needed. It uses specific verbs and resources, distinguishing it from siblings like launch_on_virtual_display and close_headless_desktop.
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 guidance on using list_headless_windows to find windows and driving them with background input and screenshots. It states the visible desktop is never touched, giving clear context. However, it does not explicitly list when not to use or mention 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?
Discloses that background typing uses WM_CHAR without focusing the window, and that for edit controls win_set_control_text is more reliable. Annotations are minimal (no contradictions), and description adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with Args and Returns sections. Main purpose is stated first. Could be slightly more concise, but all sentences add 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?
Given the output schema exists, return value explanation is sufficient. Description covers main use case, background targeting, and alternatives. For a tool with nested parameters, it is fairly 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?
While the input schema already has detailed descriptions for each property (e.g., text, hwnd, interval), the description adds a holistic explanation of background targeting and the relationship between parameters. It clarifies the overall usage pattern beyond individual property docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool types text into the currently focused window/control, and distinguishes from siblings like win_set_control_text (more reliable for edit controls) and press_keys (key combinations). It also covers background targeting via hwnd/window_title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use background targeting (hwnd/window_title) vs foreground, recommends win_set_control_text for edit controls, and mentions confirm_focus_disruption for foreground typing after consent. Provides clear 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 adds behavioral details: background key posting, message-based (WM_KEYDOWN/UP), and unreliability for modifiers. Annotations don't cover these, so the description adds significant context. Lacks info on error handling for invalid handles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one-line purpose, args/returns summary, and a crucial caveat. No wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output JSON), the description covers purpose, usage hints, and return format. The schema provides parameter details, and the description adds behavioral transparency, making it 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 main description only mentions 'target window plus key names' for the params argument, adding little beyond the schema. However, the input schema provides detailed descriptions for each parameter, making the overall parameter semantics adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool posts key presses to a specific window without focusing it, using Win32 messages. This distinguishes it from sibling tools like `press_keys` (global) and `win_set_control_text` (text entry).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that modifier combos are unreliable for apps checking physical key state, and recommends `win_set_control_text` for text entry. This provides clear guidance on when to use 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context by specifying the return format (JSON with ok, x, y) and that coordinates are in screen pixels. No contradictions.
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 very concise: two sentences that directly state the purpose and return format. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is complete. It explains what it returns and the units (screen pixels). The annotations already cover behavioral aspects.
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 schema coverage is 100%. The description does not need to add parameter semantics. Baseline 4 for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the current mouse cursor position in screen pixels', which is a specific verb+resource. It distinguishes itself from sibling tools like mouse_move, mouse_click, etc., which involve moving or clicking.
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 does not explicitly state when to use this tool versus alternatives, but the simplicity of the tool makes usage obvious. It could benefit from a note that no user interaction is required.
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 indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), idempotent. Description adds important context: 'reliable, no focus needed', 'without bringing the window forward', and specifies the return format (target_hwnd, text_len). No contradictions.
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 paragraphs with front-loaded key insight. No unnecessary words. Includes example and return description. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, mechanism, target identification, background capability, and output format. For a tool with moderate complexity and a described output schema, it is fully adequate and leaves no significant 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 description adds value beyond the schema by stating 'target control by hwnd (preferred) or title' and referencing list_child_windows for hwnd. Schema already includes descriptions for each parameter, so the description reinforces and contextualizes.
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 purpose: 'Set a control's text directly via WM_SETTEXT' and emphasizes reliability and no focus needed. It distinguishes from sibling tools like win_send_keys (keystrokes) and type_text (typing with focus) by specifying background 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?
The description gives concrete usage: 'Pass the control's hwnd (from list_child_windows)' and provides a Notepad example. It implies when to use (background control text setting without focus) but does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![lowlevel-computer-use-mcp MCP server](https://glama.ai/mcp/servers/codingmachineedge/lowlevel-computer-use-mcp/badges/card.svg)](https://glama.ai/mcp/servers/codingmachineedge/lowlevel-computer-use-mcp)

Score Badge

Copy to your README.md:

[![lowlevel-computer-use-mcp MCP server](https://glama.ai/mcp/servers/codingmachineedge/lowlevel-computer-use-mcp/badges/score.svg)](https://glama.ai/mcp/servers/codingmachineedge/lowlevel-computer-use-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/codingmachineedge/lowlevel-computer-use-mcp'

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