lowlevel-computer-use-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation2/5
Several tool pairs are near-duplicates (create_headless_desktop vs create_headless_desktops), and multiple background-input tools (type_text with background targeting, win_send_keys, ahk_control_send) perform essentially the same operation with subtle differences. Additionally, run_command and run_command_as_admin are easily confused.
Naming Consistency3/5
Tool names are largely snake_case and verb-first, but domain prefixes are inconsistently placed (wsl_list_temp vs list_windows) and some names are singular/plural mismatches (create_headless_desktop vs create_headless_desktops). The overall pattern is readable but has clear deviations.
Tool Count2/5
With 57 tools, the server is over-stuffed. Many are status/probe tools (ahk_status, linux_status, wsl_status) or nearly redundant variants, which could be consolidated. The breadth of computer-use automation justifies a larger set, but 57 exceeds what is reasonable without causing confusion.
Completeness4/5
The tool set covers the full lifecycle of desktop automation: input, window management, process control, screenshots/recording, headless desktops (Windows and Linux), WSL provisioning, and admin/startup operations. Minor gaps exist (e.g., no clipboard tool, no Linux child-window enumeration), but the surface is highly comprehensive for its stated purpose.
Average 4.1/5 across 57 of 57 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false/unhelpful, and the description does not disclose important behavioral traits such as the possibility of focus disruption, background key delivery, the need for user confirmation, or the AutoHotkey fallback behavior. The only behavioral addition is that multiple keys are pressed together and confirmation is returned, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a usage note, an Args section, and a Returns section. Every sentence contributes meaningful information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich nested schema, the description is too thin for a complex tool with optional background targeting, focus-confirmation requirements, and platform-specific display settings. It does not explain when or how to use these options, nor does it contextualize the tool among its many siblings. The output schema spares return-value detail, but behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mischaracterizes the 'params' argument as a 'list of pyautogui key names', when it is actually a HotkeyInput object with additional fields (hwnd, display, prefer_ahk, window_title, confirm_focus_disruption). It adds useful list semantics but may mislead an agent into omitting the object wrapper or ignoring all optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press a keyboard combination') with concrete examples (Ctrl+C, Alt+Tab) and the resource (keyboard). It is specific and unambiguous, though it does not explicitly differentiate this from sibling tools like win_send_keys 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives basic input semantics (single vs. multiple keys) but provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. For example, it does not mention when background delivery (hwnd/window_title) might be appropriate or when confirm_focus_disruption is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the action and return value but omits important behavioral details. It does not mention that x/y causes a movement before scrolling, that instant_move and move_duration affect visible behavior, or that confirm_focus_disruption implies scrolling can disrupt focus and requires user consent. The presence of the confirm_focus_disruption parameter signals a side effect not disclosed in the description, and annotations (readOnlyHint=false) only indicate a mutation, not these nuances.
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, using two sentences and a simple Args/Returns structure. Every word earns its place, with no repetition or fluff. It front-loads the core purpose and stays focused.
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?
Although the operation seems simple, the tool has six input fields (including focus disruption and movement options) that are not described in the tool description. The description does not explain when to set x/y, how instant_move differs from move_duration, or that confirm_focus_disruption is required after explicit user consent. Given the complexity of the nested input and the presence of an output schema, the description is under-specified and would leave an agent uncertain about correct usage.
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's top-level parameter 'params' has no description, and the overall schema description coverage is 0%, so the tool description must compensate. It does explain 'amount' with direction and mentions 'optional position', but it fails to detail x, y, instant_move, move_duration, and confirm_focus_disruption. The nested schema fields have their own descriptions, but the tool 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 starts with a specific verb and resource: 'Scroll the mouse wheel vertically.' This clearly distinguishes it from sibling tools like mouse_click, mouse_move, and mouse_drag by specifying the exact action. It also clarifies direction conventions (positive up / negative down), which removes ambiguity.
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 you need to scroll vertically) but does not explicitly state when to use this tool over alternatives, nor does it mention exclusions beyond the 'vertical' qualifier. There is no comparison with sibling tools or guidance on prerequisites (e.g., focus requirements).
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 idempotentHint=true and destructiveHint=false, and the description adds the absolute coordinate behavior and return value. However, it omits the focus disruption risk that moving the cursor can cause, even though the schema parameter confirm_focus_disruption implies this requirement.
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 with clear sections for purpose, args, and returns. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and return format but lacks usage guidance relative to sibling tools and does not mention the focus disruption caveat. It is adequate for a simple tool but incomplete for fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions x, y, and optional duration, but fails to cover the 'instant' and 'confirm_focus_disruption' parameters. Since schema description coverage is 0% per the signal, the description must compensate and does so only partially.
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 the mouse cursor to an absolute screen coordinate, using a specific verb and resource. This distinguishes it from related tools like mouse_click, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives or any context for selection. It merely states what the tool does without mentioning scenarios 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 already flag this as destructive and open-world. The description adds important context by stating it executes arbitrary commands with the server's privileges, and details the captured output (stdout, stderr, exit code). It does not contradict annotations and provides transparency about the powerful, side-effectful nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The Args and Returns sections are minimal and directly useful, and there is no gratuitous text. 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?
Given the rich schema annotations and output schema, the description covers the essential aspects: purpose, privilege level, output format, and timeout behavior implicitly through the return value. It does not provide an example invocation or explicitly state defaults (e.g., shell=true), but these are documented in the schema, so the description is sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only lists parameter names ('command, shell flag, cwd and timeout') without explaining their meaning. Although the input schema contains detailed descriptions, the context signal indicates 0% schema description coverage in the tool description, and the description fails to compensate by adding semantics beyond names.
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's action: 'Run a system/shell command and capture its stdout, stderr and exit code.' It also specifies that it executes arbitrary commands on the host with server privileges, which helps distinguish it from siblings like wsl_run or run_command_as_admin, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. There is no mention of run_command_as_admin for elevated privileges, wsl_run for WSL commands, or any exclusion criteria. The broad statement 'executes arbitrary commands' implies general use, but that is not enough to guide alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description consistently describes a listing operation but adds little beyond the annotations beyond mentioning the return format and the Xvfb context. No additional behavioral traits (e.g., error handling, need for an active display) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and includes a clear structured Args/Returns breakdown. Every sentence is informative and there is no waste or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and annotations that declare its safety, the description covers the purpose, the parameter, and the return format. It lacks usage guidelines and prerequisite details, but given the tool's simplicity and the output schema, it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the outer 'params' parameter, but the description merely says 'display number', which is already provided in the inner schema's description for the 'display' property. This is redundant and adds no meaningful clarification beyond what the agent would already find by examining the parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'windows on an Xvfb virtual display'. This distinguishes it from sibling tools like list_windows or list_headless_windows by explicitly scoping to Xvfb virtual displays, making it immediately clear what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, nor does it mention any prerequisites or exclusions. While the name is somewhat self-explanatory, there is no explicit direction for an agent to select it over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose that the drag may disrupt focus or require explicit user consent, despite the confirm_focus_disruption parameter in the schema. Annotations provide little behavioral context (readOnlyHint=false, destructiveHint=false), so the description carries the burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with an action summary followed by Args and Returns sections. Every sentence is informative, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description explains the basic operation, it lacks important context about when confirm_focus_disruption should be set and what happens when start is omitted (the schema explains this, but the description does not). The rich schema partially compensates, but the description alone is not fully complete for safe and correct usage.
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 gives a high-level summary of arguments (start, end, button, duration), but the schema already provides detailed descriptions for all properties. The description omits confirm_focus_disruption, and the summary is slightly ambiguous about which parameters are optional. It 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 the action: 'Press a mouse button at a start point and release it at an end point.' This verb+resource phrasing distinctly differentiates it from sibling tools like mouse_click, mouse_move, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for dragging but does not explicitly discuss when to use it instead of alternatives such as a mouse_move followed by a mouse_click. No exclusion criteria or alternative tools 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 discloses the UAC prompt behavior, output capture, and the full administrative rights with a cautionary note. This adds meaningful context beyond the destructiveHint=true annotation, though it does not detail potential system-wide effects.
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 and well-structured, with a clear opening statement, a warning, and an Args/Returns breakdown. It avoids unnecessary verbosity while conveying essential information, though it could be slightly more streamlined.
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 UAC, timeout, and the return format, which are key aspects. However, it does not mention the confirm_focus_disruption parameter, and given the destructive nature, more safety context could be provided. The presence of an output schema reduces some burden, but the gap around parameters prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden of explaining parameters. It only mentions 'the command line and a timeout,' omitting the 'confirm_focus_disruption' parameter entirely. This provides minimal added meaning over the schema and fails to cover all inputs.
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 'Run a shell command with Administrator privileges,' specifying both the action and the elevated context. This distinguishes it from the sibling tool 'run_command' and makes the tool's purpose immediately apparent.
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 tool is for commands requiring admin rights and warns 'use with care,' but does not explicitly state when to choose this over alternative tools like 'run_command'. No direct comparison or exclusion is provided, so usage guidance remains implied rather than explicit.
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 idempotentHint=true; the description adds the critical fact that deletion is irreversible and that files are deleted. It also discloses the return value format. 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, with a clear first sentence and a compact Args/Returns section. The Returns section is somewhat redundant with the output schema, but it adds context without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with a single parameter, the description covers the essential behavior, irreversibility, and return format. It stops short of explaining edge cases like non-existent distros, but the output schema and annotations provide sufficient context for an agent to invoke 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?
With schema description coverage at 0%, the description must compensate. It summarizes the parameters as 'distro name and whether to delete files', which conveys the core purpose but omits details like remove_files defaulting to true and being optional. This is minimal but acceptable compensation.
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 'Terminate and unregister a WSL distro' with a specific verb and resource, and highlights the irreversible deletion of files. This distinguishes it from read-only WSL tools like wsl_status and wsl_list_distros, though it could still be confused with wsl_destroy_all_temp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention wsl_destroy_all_temp for bulk temp destruction or any conditions for using wsl_destroy, leaving the agent to rely on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, establishing the tool's mutation profile. The description adds the behavioral detail that it captures stdout/stderr/exit code and returns a JSON structure, but does not disclose additional side effects or safety caveats 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loading the purpose in a single sentence followed by a concise Args/Returns structure. It omits unnecessary elaboration and only includes information that adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter list, and return format in a structured way, while annotations and schema fill in safety and parameter details. It does not describe error conditions or prerequisites beyond the distro example in the schema, but it is sufficient for a command runner.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for all parameters (distro, command, user, cwd, timeout), so the description's list of parameter names adds no new semantic meaning. The term 'optional' for user, cwd, and timeout merely restates the schema's default null values, keeping this at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run a shell command' with a specific resource 'inside a WSL distro' and states it captures stdout/stderr/exit code. This clearly distinguishes it from sibling tools like run_command, which typically target the Windows environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for executing commands within a WSL distro, but it does not explicitly provide when-to-use vs alternatives or any exclusion criteria. While the context is clear, there is no mention of alternatives such as run_command for Windows commands, so guidance is only implied.
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 convey that this is a safe, read-only, idempotent operation. The description adds the JSON return structure (installed, path, version), which is useful context, but it does not describe edge cases or behaviors beyond what the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The 'Returns:' block provides a quick reference to the output shape, though it might be redundant given the output schema. Still, every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with no inputs, comprehensive annotations, and an output schema, the description is complete. It tells the agent what the tool does and what the response looks like, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so the description correctly adds no parameter details. The baseline for zero-parameter tools is 4, and nothing here reduces 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 states 'Report whether AutoHotkey is installed and where' – a clear verb+resource combination. It distinguishes itself from sibling status tools by explicitly naming AutoHotkey, so the agent knows this is not a general system status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like wsl_status or linux_status. The description does not mention prerequisites, exclusions, or typical use cases beyond the implicit 'check AHK status'.
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=false, destructiveHint=false, and idempotentHint=true. The description adds useful behavior: it states the return value is 'JSON with the window's updated geometry, or an error if not found', disclosing the error case. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the main purpose in the first sentence. The Args/Returns structure is clear and wastes no space. Every sentence adds purpose, parameter context, or return behavior.
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 focused tool with a rich input schema and annotations covering safety, the description adequately conveys the action and return contract. It does not explain the nuances of window selection (title vs handle) or platform-specific display behavior, but the schema fills those gaps. The output schema also removes the need to detail return fields.
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 parameter summary ('target window plus new width, height') is generic, but the input schema provides rich, per-field descriptions for title, width, handle, height, and display. Since the schema effectively covers parameter semantics, the description adds little new meaning, aligning with a baseline of 3 rather than a higher or lower score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Resize a window to a new width and height', which is a specific verb+resource pair. It clearly differentiates this tool from siblings like move_window (position change) and get_screen_size (read-only) by focusing on resize semantics.
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 move_window or window_action. It does not state prerequisites, preferred window identification method (title vs handle), or exclusions. Context is limited to 'target window plus new width, height', which is not enough for an agent to choose correctly among many window-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds no extra behavioral details beyond the basic operation (e.g., overwrite behavior, permissions, directory creation). It is consistent with annotations and not misleading, but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It front-loads the action and provides exactly enough information for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering destructive behavior and an output schema present, the description is sufficient for a simple write operation. It does not discuss return values, but that is covered by the output schema. Minor gap: does not mention overwrite behavior, but overall 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 schema already describes both parameters: path as 'Destination path on the controlled computer' and content_base64 as 'UTF-8/base64 file bytes'. The description adds no additional parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Write), resource (base64 file payload), and destination (controlled computer). It clearly distinguishes from sibling download_file by specifying direction. The operation 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?
Usage context is implied by the description: use when you need to write a file to the controlled computer. However, it does not explicitly mention alternatives like download_file or specify when not to use it. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides useful context beyond annotations by explaining it does not focus the window and uses Win32 messages. However, it does not disclose potential failure modes, side effects, or reliability limitations (those are in schema notes). Annotations indicate a mutation but not destructive, which is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the essential behavior. Including args/returns format adds structure without bloat. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with a rich input schema and output schema. It explains the core functionality and return type, though it omits edge-case handling like multiple window matches or invalid handles, which is somewhat covered by the schema's descriptive fields.
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 gives a high-level summary ('target window plus key names') and does not add detail per parameter. The input schema itself provides thorough descriptions for hwnd, keys, display, and window_title, 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 a specific verb and resource: 'Post key presses to a specific window WITHOUT focusing it (Win32 messages).' This clearly distinguishes it from sibling tools like press_keys or win_set_control_text and states the mechanism.
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 a use case (sending keys to a background window without focusing) but does not explicitly state when to use this over alternatives or mention exclusions. The schema's note about preferring win_set_control_text is not part of the tool description itself.
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 establish the tool as read-only and idempotent. The description adds valuable behavioral context beyond annotations: it returns content as base64, has a 50 MiB limit, and reads from the controlled computer. However, it does not disclose error behavior for missing files or size violations, though annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence starting with the verb 'Read', containing no fluff or redundant repetition. It efficiently packs the key details: file, location, encoding, and size limit.
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?
Together with the annotations (read-only, idempotent, non-destructive) and an output schema, the description covers the essential behavior of the tool: retrieving a file's content as base64 with a 50 MiB cap. It omits failure modes (e.g., file not found, size exceeded) and path resolution details, but for a single-purpose file-read tool with strong annotations, this is largely adequate.
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 describes 'path' as 'Source path on the controlled computer', but the tool description does not add further detail about the parameter (e.g., accepted path formats, absolute vs relative, permissions). With schema description coverage reported as 0%, the description fails to compensate by not explicitly addressing the path parameter beyond implying it identifies a file.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read'), identifies the resource ('file from the controlled computer'), and specifies the output format ('as base64') and size limit ('up to 50 MiB'). This clearly distinguishes it from sibling tools like upload_file, which performs the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing file content from the controlled computer and imposes a size limit, but it does not explicitly state when to use this tool over alternatives or mention exclusions. For example, it does not reference upload_file or note that files over 50 MiB should be handled differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the scope ('whole' display) and the return JSON structure (path, width, height), providing useful context beyond the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clear one-sentence overview followed by compact Args and Returns blocks. It is front-loaded and contains no extraneous information, efficiently conveying purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, parameters, and return format, and the output schema and annotations fill additional gaps. It omits behavior when output_path is null or when the display does not exist, but given the tool's simplicity, it is largely 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 schema provides detailed descriptions for 'display' and 'output_path', but the context signal indicates 0% parameter coverage from the description. The description merely restates 'display number and output path' without adding semantics like default behavior, constraints, or null handling, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Capture' and names the exact resource ('whole Xvfb virtual display') and output format (PNG), clearly distinguishing it from the sibling 'screenshot' tool which likely targets the main 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 use for virtual displays but does not explicitly state when to choose this over alternatives like 'screenshot' or mention exclusions. No alternative tools are referenced, so the guidance is implied rather than 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 already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false. The description adds context about background operation and reliability compared to WM_CHAR, but does not disclose side effects, potential errors, or behavior on timeout. Since annotations lower the bar, the description adds some value but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main behavior in the first sentence. It includes a short usage hint, a compact Args list, and a Returns line. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (five parameters, background targeting), but the description covers the core use case, the target format, and the return type. With good annotations and a rich input schema, the description is largely sufficient. However, it could better clarify when to use this tool over sibling send tools and what happens on timeout, so a perfect score is not warranted.
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 itself provides detailed descriptions for all parameters (text, window, as_keys, control, timeout), so the schema coverage is effectively high. The tool description merely lists parameter names ('text, window/control targets, as_keys, timeout') without adding new meaning, so it does not go beyond the schema. 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 opens with a specific verb and resource: 'Send text or keystrokes to a background window/control via AutoHotkey ControlSend.' This clearly distinguishes the tool from siblings like win_send_keys, type_text, and press_keys by emphasizing background/control targeting and the AutoHotkey ControlSend mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Works without focusing the window' and 'often more reliable than raw WM_CHAR for complex apps.' It also gives a target-format hint with 'Target a HWND with ahk_id <handle>.' However, it does not explicitly name alternative sibling tools or state when NOT to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotency and non-destructiveness. The description adds the return format and clarifies the input is an existing file, but does not discuss edge cases like out-of-bounds crop boxes or auto-generated output path behavior, which would be valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a compact Args section, and a clear Returns section. Every sentence contributes meaningful information 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?
For a relatively simple crop operation, the description covers the essential purpose, parameters, and return value. Annotations provide safety and idempotency. Missing error-handling notes are a minor gap, but the tool's complexity is low enough that this is not a major deficiency.
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 schema description coverage at 0%, the description compensates by summarizing the nested params object into 'source path, crop box (left/top/width/height), output path'. This adds semantic grouping beyond the flat schema, although the schema itself provides detailed property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('crop') and resource ('existing image file') with a clear outcome ('rectangular sub-region'). This clearly differentiates the tool from siblings like screenshot or image capture tools, which operate on displays rather than files.
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 by stating the operation, but provides no explicit 'when to use' or 'when not to use' guidance nor mentions alternatives. It is functionally clear but does not help the agent choose among competing image-related 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?
The description adds a meaningful behavioral fact ('creates it if needed') and documents the return JSON with display, pid, and command. It does not elaborate on cleanup or side effects related to the destructiveHint, but the annotation already flags destructiveness, so this is not a major gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the first sentence states the core action, followed by concise Args and Returns sections. Every sentence earns its place without unnecessary detail.
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 covers the key points: purpose, parameters, and return format. It could benefit from a note about cleanup or stopping the virtual display, but the sibling tools include stop_virtual_display, and the description is otherwise sufficient for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's nested properties `command` and `display` already carry clear descriptions and constraints. The tool description simply restates them as 'display number and command line,' adding little semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and target: 'Launch a GUI app on an Xvfb virtual display.' The parenthetical '(creates it if needed)' adds a useful scope clarification and helps distinguish this from sibling tools like create_virtual_display or launch_on_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?
It clearly conveys the intended use case—launching a GUI application on an Xvfb virtual display—and notes that the display will be created if necessary. It does not explicitly contrast with alternatives or state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it reveals that window capture uses Win32 PrintWindow and works even when the window is not focused, hidden, or on a headless desktop. This goes beyond the simple readOnlyHint and destructiveHint, giving the agent critical expectations about the tool's capabilities.
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 well-structured with a clear purpose statement, a dedicated 'BACKGROUND CAPTURE' section, and a concise Args/Returns summary. Every sentence adds value, and the entire text is appropriately sized for the tool's complexity.
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 behavior, background capture, and return format. It includes the output JSON structure (ok, path, width, height), which complements the output schema. However, it doesn't mention any prerequisites or limitations (e.g., platform-specific behavior beyond Linux display), so it's not fully complete but is sufficient given the schema richness.
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 'Args' line provides only a high-level summary ('monitor index, optional region, output path, optional window target and client_only flag') and doesn't explain the individual parameters in detail. The schema itself has rich descriptions for each parameter, but the description adds little beyond that. With schema description coverage reported at 0%, the description fails to compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of a monitor or pixel region and saves as PNG. It uses a specific verb ('Capture') and resource ('screenshot'), which distinguishes it from generic operations. However, it doesn't explicitly differentiate from the sibling tool 'screenshot_virtual_display', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context, particularly the 'BACKGROUND CAPTURE' section, explaining when to use window capture (unfocused, hidden, off-screen) via hwnd or window_title. It doesn't explicitly mention when to use this tool over alternatives like screenshot_virtual_display, so it lacks an explicit exclusion, 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?
Annotations already mark it destructive and idempotent. The description adds value by explicitly stating it terminates apps launched on the display, and discloses the return JSON shape. This goes beyond annotation basics.
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 brief, front-loaded with the main action, and clearly separates Args and Returns. Every sentence is useful with no 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 tool is simple, and the description covers its scope, side effects, and return format. It doesn't explain edge cases like missing displays, but given the structure and annotations, it's adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'display' as 'Xvfb display number'. The description repeats this as 'display number' without additional detail. Since the top-level schema coverage is 0%, the description partially compensates but doesn't add meaningful semantics 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 stops an Xvfb virtual display and terminates its apps. The verb 'stop' and resource 'Xvfb virtual display' differentiate it from siblings like create_virtual_display or launch_on_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?
Usage is implied by the purpose: it's for stopping a display. However, there is no explicit guidance on when to use this vs alternatives, or when not to use it. The context from sibling names helps but the description doesn't directly address selection.
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 tool's safe, non-destructive nature. The description adds the return format and field details but no additional behavioral context like authentication, rate limits, or side effects, which is acceptable given strong 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 a single-sentence purpose followed by a clear Returns section. It is front-loaded and free of fluff, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with strong annotations, the description is quite complete. It covers the output structure and fields. It does not mention behavior for empty results, but the count field implicitly handles that, so the overall description 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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('List') and resource ('installed WSL distros') and explicitly mentions the fields returned (state, version, default). This distinguishes it from sibling tools like wsl_status 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?
The description does not state when to use this tool vs alternatives or mention any exclusions. Usage is implied by the tool name and purpose, but there is no explicit guidance for selecting it over other WSL-related 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 adds context beyond the destructiveHint annotation by explaining that the desktop is fully freed only after all processes exit, and it describes the return JSON with a 'closed' boolean indicating actual closure. This is useful operational insight.
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, leading with the main action, followed by a relevant note and then an Args/Returns block. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cleanup tool, the description covers the key behavior, the prerequisite, and the return format. It is sufficient for an agent to use it correctly, though it could mention the default value or idempotency, but those are in schema/annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines a 'name' property with a description, but the tool description does not add meaning beyond labeling it 'desktop name'. The parameter is a nested object, and the description's phrasing 'params (HeadlessDesktopInput): desktop name' could mislead the agent to pass a string directly, given the schema requires an object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it releases the server's handle to an off-screen desktop, with a specific verb and resource. It distinguishes from sibling tools like create_headless_desktop and list_headless_desktops by focusing on closing/releasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (closing apps first) and explains the freeing behavior, implying it should be used when done with a desktop. However, it does not explicitly compare with alternatives like stop_virtual_display or wsl_destroy, so it doesn't fully distinguish when to choose 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?
Adds behavioral context beyond annotations by explaining that apps have a real GUI, never appear on the visible desktop, and can be captured. Annotations already indicate non-read-only, idempotent, non-destructive; description aligns and enriches this without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear summary, explanation, Args, and Returns sections. Every sentence contributes value with no redundant 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?
Covers purpose, behavior, and return format adequately. It lacks explicit guidance on alternatives and potential edge cases, but for a simple creation tool with strong annotations and an output schema, it is sufficiently 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 description says 'params (HeadlessDesktopInput): desktop name', which is misleading because params is a wrapper object containing a name field, not the name itself. Schema coverage is low and the description fails to clarify the nested object structure, potentially causing incorrect invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: creating an off-screen Win32 desktop for running GUI apps invisibly. It distinguishes this from visible desktop environments and explains the 'headless but with GUI' mode, making the tool's unique purpose 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?
Provides clear context for when to use the tool: when you need GUI apps to run and be automatable/capturable via PrintWindow without appearing on the visible desktop. However, it does not explicitly name alternatives or exclusion conditions, though sibling tools like create_virtual_display exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it runs without elevation, uses pythonw.exe in HTTP mode, and causes no terminal or focus change at logon. This complements the destructiveHint/idempotentHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a one-sentence behavioral note, and a compact args/returns summary. Every sentence earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: task installation, logon trigger, elevation behavior, and HTTP mode. The output schema handles return structure, so the return description is not strictly necessary. It lacks an explicit note about Windows prerequisites, but the overall context is sufficient for a well-scoped tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only lists parameter names ('run_as_admin, http, host and port options') without explaining their semantics. Since the schema description coverage is reported as 0%, the description does not compensate for the lack of parameter meaning, even though the nested schema itself contains descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Install a scheduled task so this server starts automatically at user logon.' This directly states the tool's function and distinguishes it from related sibling tools like uninstall_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (automatic startup at logon) and explains the default execution mode (HTTP via pythonw.exe, no elevation). However, it does not explicitly mention alternatives or exclusions, such as checking startup_status first or using a different installation method.
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 read-only, idempotent, and non-destructive hints, so the safety profile is clear. The description adds value by specifying the exact JSON return shape and the Windows platform, which is not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose, the second lists the return format. No wasted words, and the purpose 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?
For a zero-parameter status check with strong annotations and an output schema (as indicated by context signals), the description fully covers the tool's behavior and return format. There are no missing details that an agent would need.
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 nothing to explain in the schema. The description adds context about the return value, which is informative even though parameter semantics are moot. Baseline 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 states 'Report whether this server process is running elevated (as Administrator)' with a clear verb and resource, making the tool's function unambiguous. This distinguishes it from sibling tools like run_command_as_admin, which perform actions rather than checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't mention checking admin before running admin commands, nor does it exclude any contexts. Given many sibling tools, this lack of usage context is a 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the return JSON structure (ok, name, count, windows with specific fields) and specifies 'top-level windows,' providing useful behavioral context beyond annotations. It doesn't describe error behavior, but for a read-only list tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main sentence, followed by a clear Args/Returns breakdown. Every sentence serves a purpose, and there is no unnecessary verbosity.
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, idempotent), the description is sufficiently complete. It includes the return format, acting as an informal output schema. Minor omissions like error handling or prerequisite desktop existence don't significantly impact usability.
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 already describes the 'name' parameter as 'Name of the off-screen desktop.' The description redundantly states 'params (HeadlessDesktopInput): desktop name,' adding no new information. With schema description coverage reported as 0%, the description should compensate but does not clarify the default value, constraints, or how to discover available desktops.
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 top-level windows living on an off-screen desktop,' specifying the action (list), resource (windows), and scope (off-screen desktop). It distinguishes itself from siblings like list_windows (likely for the regular desktop) and list_child_windows.
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 that the tool is for headless desktops and requires a desktop name via params. It does not explicitly name alternatives or exclusions, but the context is unambiguous. Slight deduction for not mentioning when not to use it or comparing to list_virtual_display_windows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value by detailing the exact return JSON structure ({ok, count, processes} with specific fields) and the optional filtering/sorting behavior, 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 compact and well-structured with Args and Returns sections. Every sentence carries useful information and there is no redundant filler, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with strong read-only annotations, a complete schema for its parameters, and the description's explicit return format, the combined context fully covers functionality, inputs, and outputs. No missing behavioral or output details for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's nested properties (limit, sort_by, name_filter) include detailed descriptions, so effective coverage is high. The description merely lists 'optional name filter, sort key and limit' without adding semantics beyond identifying optionality, which is a minor addition 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 'List running processes with pid, name, memory and CPU usage', using a specific verb and resource. It includes the scope ('running') and the key output fields, which distinguishes it from sibling tools like kill_process or list_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 implies usage through its clear purpose—when you need to inspect running processes—but provides no explicit when-to-use vs alternatives or exclusionary guidance. It mentions optional filters/sort/limit, which hints at flexibility but does not compare to sibling 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 adds meaningful behavioral context beyond annotations: it discloses that background targeting does NOT focus the window and uses WM_CHAR, and it notes that win_set_control_text is more reliable for edit controls. It also states the return value. 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 front-loaded with the main purpose and includes a focused BACKGROUND TARGETING section. It is concise and every sentence adds meaningful guidance, though the Args/Returns formatting could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behaviors, includes return value information, and gives an alternative tool pointer. It does not explain the confirm_focus_disruption requirement or edge cases, but given the output schema exists and the description is relatively complete for a typing tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining the purpose of hwnd/window_title and mentioning interval and target, but it does not mention all parameters (display, confirm_focus_disruption). The JSON schema already provides detailed descriptions for every parameter, so the description is supplementary but not fully comprehensive. Given the low schema coverage signal, this is adequate with gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Type a string of text into the currently focused window/control') and differentiates itself from siblings by explicitly mentioning background targeting and recommending win_set_control_text for edit controls, which distinguishes it from win_send_keys and press_keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use background targeting (set hwnd or window_title) and gives an alternative (win_set_control_text) with a condition ('For edit controls'). However, it does not explicitly contrast with press_keys or win_send_keys, so it lacks a complete exclusion matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey mutating, idempotent, and non-destructive behavior. The description adds a concrete return format ('{"ok": true, "hwnd": N, "visible": false}') which is not covered by annotations, helping the agent verify success. It also clarifies the action is a re-hide of a previously shown window.
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 and well-structured, with a clear purpose sentence followed by an args summary and return format. Every sentence adds value; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested params object and multiple optional properties, the description provides sufficient context: it states the core action, gives a typical use case, and describes the return format. The rich schema covers parameter details, and annotations cover safety. The only minor gap is not explicitly mentioning the Linux-only display parameter, but that is handled by the schema.
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 parameters as 'window by hwnd or title, and a minimize flag', which maps to most schema properties. However, the schema itself already provides detailed descriptions for all properties, including the 'display' parameter not mentioned in the tool description. Thus 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 the tool hides a window, using the specific verb 'hide' and resource 'window'. It distinguishes from sibling tools like show_window by specifying 'again after it was shown', and provides a concrete use case ('once login is complete').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (after a window has been shown, e.g., after login) and implies it is the counterpart to show_window. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and not read-only. The description adds valuable context: the process runs with a full GUI on a hidden desktop, the desktop is created if needed, and the visible desktop is unaffected. This discloses side-effects (process launch, desktop creation) beyond the annotations. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear purpose sentence, a usage note, then Args/Returns sections. Every line conveys necessary information without fluff. The front-loaded purpose statement makes it easy to understand the tool at a glance.
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 that launches GUI apps on a hidden desktop, the description is remarkably complete. It explains the hidden-desktop behavior, how to interact with the launched app (list_headless_windows, screenshot), the return payload (JSON with ok, desktop, pid, command), and that the visible desktop is untouched. The output schema is described textually, and no critical operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning this description must compensate for parameter documentation. It only says 'desktop name and command line,' which adds no detail beyond the schema's own descriptions. It fails to mention the default name, required command, or how the command should be formatted. The schema already covers these, but the description adds no extra value for an agent trying to understand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+environment: 'Launch a GUI application on an off-screen desktop (creates it if needed).' This clearly states the core function and distinguishes it from siblings like create_headless_desktop and launch_on_virtual_display. The phrase 'creates it if needed' also clarifies that it combines desktop creation with app launch.
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 explicit workflow guidance: use list_headless_windows to find windows, drive with background input, and capture with screenshot(hwnd=...). It also states the visible desktop is never touched, implying when to choose this tool over alternatives. However, it does not explicitly name when-not-to-use or compare with launch_on_virtual_display, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is established. The description goes further by specifying the exact return JSON structure, including the parent_hwnd, count, children fields, and that coordinates are relative to the parent window's top-left. This meaningful behavioral detail goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized into summary, use-case, args, and returns. Every sentence contributes useful information, and it avoids redundant fluff. The structure makes it easy for an agent to quickly extract key usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the main input, output format, coordinate semantics, and a practical example. It does not mention whether child enumeration is recursive or only immediate children, nor what happens if the parent window is not found. These are notable but not critical gaps, so the tool remains 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 summarizes the single parameter as 'the parent window by hwnd or title,' which adds some meaning beyond the empty top-level schema description. However, it omits the 'display' field (Linux-specific) and does not explain precedence between hwnd and window_title. The nested schema provides detailed field descriptions, so the parameter semantics are partially covered but not fully clarified by the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Enumerate the child controls of a window' and lists the included attributes (class, text, client rect, handle). It also gives a concrete example (finding the Edit control inside Notepad), which distinguishes it from sibling tools like list_windows that deal with top-level windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful for finding the exact control handle to target with background input' and mentions positioning for background clicks. It does not explicitly mention when not to use it or name alternative tools, but the guidance is contextual enough for an agent to select this tool appropriately.
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 openWorldHint, providing the safety profile. The description adds the exact return JSON structure and mentions filtering capabilities, which is useful context beyond annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear Args and Returns sections. The purpose statement is front-loaded and every sentence is informative, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool, the description covers the return format and the available filtering options. With strong annotations and a well-defined output schema, it is sufficiently complete, though it doesn't mention edge cases like inaccessible windows or empty results.
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 outer 'params' parameter has no schema description (0% coverage), but the nested schema provides detailed descriptions for title_filter and include_empty_titles. The description merely says 'optional title filter and empty-title toggle' without repeating type/default info, so it adds only marginal 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 opens with 'List top-level windows with their titles, handles, positions and sizes.' This is a specific verb and resource, clearly distinguishing from sibling tools like list_child_windows and list_headless_windows by the 'top-level' modifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by emphasizing 'top-level windows' and listing the returned properties, which suggests it is for enumerating main desktop windows. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining window identification semantics (exact handle vs. case-insensitive title substring) and the return format (updated geometry or error). Annotations already cover mutation (readOnlyHint=false), idempotency, and non-destructiveness, so this extra context is sufficient, though it does not clarify precedence if both handle and title are provided.
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 front-loaded with the primary action, uses a compact Args/Returns structure, and every sentence contributes meaningful information without redundancy. It is appropriately sized for the tool's complexity.
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 and presence of an output schema, the description covers the core operation, identification methods, and return value. It lacks minor details such as coordinate system origin or behavior when both handle and title are provided, but these are not critical for basic usage.
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% per context, so the description must compensate. It clarifies that handle is preferred and exact, title is substring, and x/y are new position coordinates. However, it omits details about the display parameter and does not explicitly map all schema fields (e.g., units for x/y, display specifics), leaving needed compensation 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 states a specific verb and resource: 'Move a window to a new top-left screen position.' It clearly distinguishes from siblings like resize_window and window_action by focusing on positional movement, and it also specifies the target identification method (handle or title).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a window needs to be repositioned on screen. It provides identification guidance (handle preferred, title substring) but does not explicitly mention alternatives or when not to use it, such as for resizing or other window 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by detailing the return structure (ok, recording, path, frames, elapsed_seconds) and indicating that the tool reports current activity, which is not evident from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose statement, followed by a return value specification. The 'str: JSON' phrasing is slightly awkward but acceptable; overall, every sentence contributes useful information without padding.
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 simplicity of the tool (no parameters, strong annotations, and an output schema), the description adequately covers the behavior. It explains what the tool reports and the shape of the result, making it sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description has no parameter details to add. Per the rubric, a baseline of 4 is appropriate when no parameters exist, and the description does not need to compensate for schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and resource ('whether a screen recording is currently active'), clearly distinguishing it from sibling tools like start_screen_recording and stop_screen_recording. It precisely conveys that this is a status query, not a state-changing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only status-reporting purpose implies when to use this tool—for checking recording state—but there is no explicit guidance about alternatives or when not to use it. The sibling list shows start/stop recording tools, yet the description does not mention them, leaving usage context implicit.
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 annotation readOnlyHint=false already indicates a write operation, but the description adds behavioral details: recording happens in a background thread, the single-recording constraint, and that the file is flushed upon stop. These are informative beyond the structured metadata and help the agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: purpose in the first line, key usage constraint in the second, and a compact args/returns section. Every sentence is purposeful and no redundant content exists, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that starts an asynchronous recording, the description covers the key operational aspects: the background thread, the one-at-a-time limit, the need to call stop_screen_recording, and the return JSON structure. With an output schema present, detailed return values need not be repeated, and the description is sufficiently complete for an agent to invoke and manage the recording.
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 parameter group ('fps, monitor, optional region and output path') but the schema already contains detailed descriptions for every property (e.g., fps 'Frames per second to capture', output_path auto-generation). The description adds minimal semantic value beyond the schema, which carries the full explanatory load.
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 'Begin recording the screen to an mp4 file in a background thread', specifying the exact action and resource. It is easily distinguished from sibling tools like screenshot (single capture) and stop_screen_recording (stops recording), preventing confusion.
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: 'Only one recording can run at a time' and instructs to call stop_screen_recording to finish. This gives practical guidance on when to use the tool and how to properly end a session, though it does not explicitly mention alternatives like screenshot for still captures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds the return value structure and handles the edge case of no active window, which is 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?
Two concise sentences: the first states purpose, the second gives return format. No fluff, and the description is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description fully covers behavior and return values, including the null case. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters; the description correctly has nothing to add about parameters, satisfying the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return information' and clearly identifies the resource as 'currently focused (active) window'. It distinguishes from sibling tools like list_windows by specifying the active window, even though it doesn't explicitly compare.
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 querying the active window through the phrase 'currently focused (active) window', but it provides no explicit when-to-use guidance or alternatives. It does not mention list_windows or other window enumeration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation safe and non-destructive. The description adds valuable behavioral detail: the return type is a str containing a JSON object with width/height format, and it specifies 'primary screen' scope.
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 clean lines, front-loaded with the main purpose followed by a concrete return example. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only getter with a clear output format and rich annotations, the description fully covers the necessary context. Nothing significant is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100%. The baseline for 0 params is 4, and the description correctly adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the primary screen resolution in pixels' with a specific verb and resource. It distinguishes this from sibling tools like get_cursor_position or list_headless_desktops.
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 usage context or alternatives are provided. Usage is implied by the tool's simple getter nature, but the description does not mention when to use it or contrast with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds a return format (JSON string with ok, display, session_type, xdotool, etc.), which provides behavioral context beyond the annotations. 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 two concise parts: a one-sentence purpose and a return format example. Every piece is informative, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check with annotations and an output schema, the description fully covers purpose and return behavior. It is complete for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% and the description need not discuss parameters. The description instead focuses on the output, which is appropriate for a parameterless status tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Report Linux X11 automation tooling availability' with a specific verb and resource, and lists example tools (xdotool, wmctrl, Xvfb), distinguishing it from sibling status tools like wsl_status and ahk_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 use for checking X11 tooling availability but does not explicitly state when to use versus alternatives, nor does it mention any prerequisites or exclusions. It names specific tools, giving some context, but lacks explicit 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds useful context about ownership scope, which goes beyond the annotations. It does not describe the return format, but an output schema is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the verb, resource, and scope. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool, the description is complete. The output schema exists, so return values do not need to be explained. The ownership scope is clearly stated, making the tool's behavior unambiguous.
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 are no parameter semantics to explain. The baseline for 0 params is 4, and the description correctly focuses on what the tool does rather than on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (headless desktops), and adds a specific scope ('owned by this server process'). This distinguishes it from sibling tools like list_headless_windows, which lists windows rather than desktops.
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 (call when you want to see the headless desktops owned by the server), but does not explicitly state when to use this tool over alternatives, nor any exclusions or prerequisites. The 'owned by this server process' context provides some guidance but no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behaviors: omitted x/y result in a click at the cursor, background targeting uses Win32 PostMessage without bringing the window to the foreground, and the deepest child control at the given client coordinate receives the click. This adds meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a clear main-action sentence, a background-targeting paragraph, and a brief Args/Returns section. Every sentence contributes 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?
For a tool with 10 parameters and two distinct targeting modes, the description plus the schema is highly complete. It covers the return format (JSON string), foreground vs background behavior, coordinate semantics, and leaves detailed parameter specifics to the schema, which is present and thorough.
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 params as 'position, button, click count, interval, optional target' and adds semantic notes about x/y omission and clicks=2. However, it does not mention display, instant_move, move_duration, or confirm_focus_disruption; the detailed nested schema descriptions carry that weight, so the description adds only marginal 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 opens with 'Click a mouse button, optionally at a specific coordinate', using a specific verb and resource that clearly distinguishes it from sibling tools like mouse_move, mouse_drag, and mouse_scroll. The background-targeting section further clarifies scope by introducing window handles/titles as alternative targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: clicks=2 for double-click, omitting x/y for current cursor position, and using hwnd/window_title for background targeting. It does not explicitly name alternative tools for when-not-to-use, but the context is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that scripts must terminate or run until timeout, and explains how to emit output via FileAppend to stdout. Also documents the return JSON structure. These add value beyond the annotations' destructiveHint and openWorldHint.
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 front-loaded with the purpose and uses a compact, structured format. Every sentence adds relevant context, including termination behavior, output method, and use cases, 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?
For an arbitrary-code execution tool, the description covers key operational details: termination requirement, timeout handling, output capture, return format, and ideal use cases. Combined with the schema and annotations, it is fully specified.
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 parameters ('script source, optional args, timeout, optional exe path') but does not add details beyond the schema, which already provides descriptions for all properties with defaults and constraints. The description adds no new meaning to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool runs an inline AutoHotkey script and captures output. The use-case note ('reliable background input (ControlSend/ControlClick) and real hotkeys') distinguishes it from siblings like run_command and ahk_status.
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?
Mentions AHK is ideal for background input and real hotkeys, giving clear context for when to use this tool. It does not explicitly name alternatives or state when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds a useful behavioral detail about the return format ('str: JSON {ok, installed, details, task_name}'), which is not captured by annotations. No additional context such as auth requirements, but the return format disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the purpose and include a compact return format. No wasted words; every sentence contributes.
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?
This is a simple 0-parameter read-only tool with strong annotations (readOnly, idempotent) and an output schema. The description clearly explains what it does and its return shape, making it complete for an interaction model. No further elaboration is necessary.
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 0 parameters, so there is nothing to explain. Per the rubric, 0 parameters yields a baseline of 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Report') and resource ('the boot-startup scheduled task'), and specifies what it reports (installed status and state). This distinguishes it from siblings like install_startup and uninstall_startup, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking startup task status but provides no explicit guidance on when to use it vs. alternatives (e.g., install_startup/uninstall_startup). No mention of exclusions or prerequisites, so the guidance is merely 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 indicate read-only, non-destructive, idempotent behavior. The description adds the session-specific scope and the exact return schema (JSON with count and distro details). This adds value beyond annotations, though it does not discuss potential error conditions 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?
The description is extremely concise: one sentence for purpose, one for return format. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description fully covers what it lists, the session scoping, and the return structure. Given the presence of annotations and the output schema description, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema provides no ambiguity. The description correctly omits parameter details. The baseline for 0 params is 4, and no further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and a specific resource ('throwaway distros this server session provisioned'). It clearly distinguishes from sibling tools like wsl_list_distros by scoping to session-provisioned temporary distros.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (listing temp distros) but does not explicitly mention alternatives or when not to use this tool. No exclusions or comparisons to wsl_list_distros or wsl_destroy_all_temp are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds context by stating the return format (JSON string with ok, available, version), which goes beyond the annotations and gives the agent expectations about the output.
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 the purpose front-loaded and the return format in a code block. Every sentence earns its place, and there is no wasted 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 no parameters, a simple purpose, and the return format already described, the tool is fully specified. No additional information is necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, there is no parameter burden on the description. The baseline of 4 applies, and the description does not need to explain any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports WSL availability on the current Windows host, using the specific verb 'Report' and identifying the resource. It distinguishes itself from sibling WSL tools like wsl_list_distros or wsl_run by focusing exclusively 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for when to use this tool is implied: to check WSL availability. It does not explicitly contrast with alternatives or state exclusions, but the purpose is straightforward enough that an agent can infer when to call 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 idempotency and non-destructiveness, but the description adds specific behavioral detail with 'Existing names are reopened safely.' This goes beyond the annotations by explaining what happens on name collisions, and 'independent off-screen desktops' clarifies isolation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core functionality, and the second adds necessary usage guidance. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully describes parameters and an output schema exists, the description covers the essential context: what the tool does, when to use it, and an important behavioral nuance. It could mention the count default or limits, but those are already in the schema, so the description is adequately complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptive text for count, names, and prefix, so the baseline is 3. The tool description adds value by explaining why 'prefix' and 'names' matter ('project/agent-specific ... when several agents share a Windows session') and how existing names behave ('reopened safely'), which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create several independent off-screen desktops in one request.' It clearly distinguishes from the singular sibling 'create_headless_desktop' by emphasizing multiple desktops in a single call, and 'off-screen' differentiates from 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 provides clear context: 'Use a project/agent-specific prefix or explicit names when several agents share a Windows session.' This implies the tool is for multi-agent scenarios and gives naming guidance, though it does not explicitly name alternatives like 'create_headless_desktop' or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey safety hints (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral detail: it runs a real X server without a physical screen and returns a JSON with pid, which helps the agent understand the side effects and result. It does not mention cleanup or failure conditions, but that is acceptable given the annotation coverage.
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 efficient and well-structured: two impactful opening sentences establish purpose and use case, followed by structured Args and Returns sections. Every sentence carries information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, what inputs it takes, and what it returns. It does not explain how to interact with the created display using other tools (e.g., launch_on_virtual_display), but that is beyond the scope of a creation tool. The output schema exists, so the return format is already documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the top-level 'params' parameter is 0% (no description on that property). The description compensates by explicitly listing the contained fields: 'display number, width, height, depth'. The return example also illustrates the format (e.g., ':99' and '1280x800x24'), adding semantic context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Start an Xvfb virtual display'. It clearly distinguishes itself from sibling tools like create_headless_desktop by describing itself as the 'Linux counterpart of the Windows 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?
It provides clear context for when to use the tool: when GUI apps need headless execution with automation (xdotool) and screenshots (mss) on Linux. It implicitly contrasts with the Windows headless desktop, but does not explicitly name alternatives or state 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 already mark it as non-readOnly, idempotent, and non-destructive. The description adds context that it brings the window to the foreground for user interaction, and describes the return JSON. It does not contradict annotations and adds useful behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a front-loaded action, a brief use-case paragraph, and a simple Args/Returns section. No redundant or filler 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?
The tool is simple (one nested param) and the description includes use case, workflow, and return format. It could mention the focus disruption confirmation requirement explicitly, but the schema covers that. Overall complete for an agent to select and invoke.
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 tool description summarizes params as 'the window by hwnd or title,' which maps to the hwnd and window_title properties. However, it omits display and confirm_focus_disruption. The referenced input schema provides detailed descriptions for all properties, so the description adds marginal value but does not fully compensate for the top-level 0% 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 opens with a specific verb and resource: 'Make a hidden/minimized window visible and bring it to the foreground.' This clearly distinguishes it from sibling tools like hide_window and move_window. The title 'Show Window (Foreground)' reinforces the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: when an automated app needs the human, typically for interactive LOGIN. It also provides an alternative workflow: show it, let the user sign in, then call hide_window. This gives clear context and excludes misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the destructiveHint annotation by explaining that 'close is destructive - it sends the window a close request and the app may prompt to save.' This clarifies the exact side effect. However, it does not mention the confirm_focus_disruption requirement for focus actions, which is only disclosed in the schema, so the description is not fully transparent about all behavioral traits.
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 four sentences, front-loaded with the primary purpose, includes a critical warning about the destructive close action, and uses a clear Args/Returns structure. Every sentence contributes useful information without redundancy or verbose padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, destructive close behavior, window identification, and return format (including error handling). It omits the focus disruption confirmation and platform-specific display parameter, but these are documented in the schema. For a tool with one nested parameter and an output schema, the description is sufficiently complete, though a bit more detail on focus side effects would make it fully robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides thorough descriptions for all parameters (action, title, handle, display, confirm_focus_disruption), so the baseline is 3. The description adds value by explicitly stating 'Identify the window by handle or title' and by enumerating the allowed actions in the first sentence, which reinforces the semantics of the action parameter and the selection criteria. This lifts it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Focus, minimize, maximize, restore or close a window.' The verb+resource combination is specific and clearly differentiates from sibling window tools like move_window or resize_window, as the enumerated actions are unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly identifies the target window via 'handle or title' and warns about the destructive nature of 'close'. While it doesn't explicitly contrast with alternatives, the action set (focus/minimize/maximize/restore/close) is distinct enough that usage context is clear. It omits explicit 'when not to use' guidance, but the unique actions make this unnecessary for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool mutates state (readOnlyHint=false) and is idempotent. The description adds valuable behavioral detail: the underlying mechanism (WM_SETTEXT), that it works without focus, and that it operates on background windows. It also documents the return format. 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, well-structured with Args/Returns sections, and front-loaded with the core purpose. Every sentence adds value—the example with Notepad and the focus-free behavior are relevant and not wasteful.
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 mutation tool with nested parameters and an output schema, the description provides enough context: it explains the target, the method, the source of hwnd, and the return JSON. It could mention failure cases or platform limitations, but overall it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description summarizes params as 'target control by hwnd (preferred) or title, plus text', clarifying the primary identifier and required input. It also points to list_child_windows as the source for hwnd. Although the schema covers detailed property descriptions, the description adds practical guidance and preference, partially compensating for the low schema_description_coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set a control's text directly via WM_SETTEXT'. It identifies the target resource (a control identified by hwnd) and differentiates from sibling tools like win_send_keys by emphasizing 'reliable, no focus needed' and that it works on background windows.
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 context: pass a control hwnd (from list_child_windows) to modify text without bringing the window forward. It does not explicitly name alternative tools or state when not to use it, so it lacks a clear exclusion clause.
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=false, destructiveHint=false, and idempotentHint=false. The description adds valuable context beyond annotations: it explains that existing distros are left untouched, describes the default source as a tiny Alpine minirootfs, and gives the return format. It does not mention every side effect, but the annotations plus this context are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It leads with the main action, explains the default behavior, names related tools, lists alternatives, and includes an Args/Returns summary. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of a well-detailed schema, the description provides enough context for correct invocation: it names all relevant parameters, gives the return format, and places the tool in the wsl lifecycle. It does not cover prerequisite details like admin rights or cleanup edge cases, but these are not essential for a basic agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for each property in WslCreateInput, so the baseline is 3. The description merely lists the parameter names ('optional name, rootfs_url, clone_from, base_tar, timeout') and mentions the default Alpine source, but does not add meaningful semantics beyond what the schema already documents.
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: 'Provision a throwaway WSL distro on demand for running Linux software.' It uses a specific verb (provision/create) and resource (throwaway WSL distro), and distinguishes itself from sibling tools like wsl_run and wsl_destroy by explicitly referencing them as complementary steps in the lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: default behavior (download Alpine), relationship to sibling tools ('Use wsl_run to run commands in it and wsl_destroy to tear it down'), and alternative configuration paths ('Alternatively clone_from an existing distro or import base_tar'). This clearly tells the agent when and how to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds behavioral context by specifying the coordinate system ('screen pixels') and the return structure (JSON with ok, x, y), which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sections: a clear one-sentence purpose and a return format example. No wasted words. The 'Returns' block is a bit unusual but adds clarity without bloat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter getter with an output schema. The description states what it does and the return format. Annotations cover safety and idempotency. Given the low complexity and structured metadata, the description is fully sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so there is nothing to document. Per the rubric, 0 params baseline is 4. The description doesn't need to add parameter info; its mention of the output format is helpful but not required for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current mouse cursor position in screen pixels, using a specific verb ('Return') and resource ('mouse cursor position'). This distinguishes it from sibling tools like get_screen_size (returns screen dimensions) and mouse_move (changes position).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need the current cursor coordinates. It doesn't explicitly mention alternatives or exclusions, but for such a simple getter the intended use is obvious. The sibling list shows related mouse operations that are functionally different.
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=false and destructiveHint=false, so the safety profile is known. The description adds context beyond annotations: it specifies the return value ('JSON {"ok": true, "restored": true}') and notes the parameter is 'for symmetry,' indicating it may not be functionally used. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one main sentence plus an Args/Returns section. It front-loads the core purpose, then clearly documents the parameter and return value. No wasted words; every line 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?
This is a simple tool (1 parameter, no nested objects, no output schema provided but return documented in description). The description covers what it does, when to use it, what the parameter means, and what the return value is. Given the low complexity and presence of annotations, the description is fully adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the top-level parameter is 0%, but the description explains the parameter's purpose: 'the off-screen desktop name (for symmetry).' This adds meaning beyond the schema, which only provides a property description for 'name.' The 'for symmetry' note clarifies that the parameter is likely ignored or just for API consistency, which is valuable for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Switch the live screen back to the normal desktop after show_headless_desktop.' It uses a specific verb ('switch back') and resource ('live screen', 'normal desktop'), and directly distinguishes itself from the sibling tool show_headless_desktop by referencing it explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: 'after show_headless_desktop.' It implies the tool is the inverse operation, giving a strong usage signal. It does not explicitly mention alternatives or exclusions, but the reference to show_headless_desktop suffices for a simple state-reversal tool.
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, the description reveals key behaviors: it is temporary, the off-screen desktop becomes interactive and visible, there is a topmost non-dismissible banner with an EMERGENCY EXIT button that restores the normal desktop. It also discloses the return JSON fields. No contradiction with annotations; annotations indicate mutation (readOnlyHint=false) and non-destructive behavior, which align with the description.
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 separate paragraphs for purpose, behavior, arguments, and returns. Each sentence adds meaningful detail. It is a bit longer than strictly necessary, but no part is wasted, and the use of sections makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core behavior, return format, and companion tool. It does not mention prerequisites (e.g., whether a headless desktop must already exist) or the confirm_focus_disruption parameter, but given the output schema is present and the description is otherwise thorough, it is sufficiently complete for a moderately complex 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 description mentions 'desktop name and banner instruction,' which maps to the 'name' and 'instruction' properties, but it omits 'confirm_focus_disruption.' Although the schema provides detailed descriptions for each nested property, the context signal indicates 0% schema description coverage at the top level, placing a burden on the description to compensate. The description only partially covers the parameters, missing a critical confirmation flag.
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: 'Temporarily switch the live screen to a headless desktop for human interaction.' It uses a specific verb and resource, and distinguishes itself from siblings by describing the interactive handoff scenario and referencing the companion tool 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'so a person can complete a LOGIN or any manual step.' It also provides an explicit alternative/next step: 'Call hide_headless_desktop to switch back normally afterwards.' This gives clear usage context and differentiates from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds concrete behavioral details: it finalizes the mp4 file and returns a JSON with path, frames, and duration. This gives the agent useful expectations about side effects and output.
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 the return format in a clear code block. No unnecessary words or repetition.
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 no-parameter tool with a simple action, the description fully covers what it does and what it returns. The output schema is documented in the description, and no additional edge cases or prerequisites are needed for basic 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?
The tool has zero parameters, and the schema is empty (100% coverage). Per the rubric, a baseline of 4 applies, and the description correctly focuses on behavior rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: stopping the active screen recording and finalizing the mp4 file. It uses a specific verb ('stop') with a clear resource ('screen recording') and differentiates it from sibling tools 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'active screen recording' implies the correct usage context: call this when a recording is in progress. It doesn't explicitly name alternatives or exclusions, but the context is unambiguous, and sibling recording_status exists for checking status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations' destructive and readOnly hints, the description adds that UAC is not shown and that elevated tasks may require an elevated server, which are useful behavioral constraints. It also discloses the return format, adding meaningful context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and includes a structured return type block. Every phrase earns its place: action, UAC behavior, elevation caveat, and return format. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter destructive tool with output format specified, the description covers the core purpose, behavioral caveats, and return value. The elevation caveat is especially important for proper invocation. The description is complete enough 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?
The tool takes zero parameters, so schema coverage is trivially 100%. The description lacks parameter details by necessity, and the baseline for zero-parameter tools is 4, which is appropriate here.
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 removes user startup entries without UAC, which distinguishes it from sibling install_startup and other startup management tools. The verb 'remove' and resource 'user startup' are specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by noting the UAC-free operation and the elevation requirement for elevated tasks, indicating when this tool is appropriate. However, it does not explicitly name alternatives or exclusions, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is set. The description adds context about what gets destroyed ('every throwaway distro provisioned in this session') and describes the return payload, going beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the return format clearly listed. No filler or redundant content; every part 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?
For a no-parameter destructive cleanup tool with annotations covering destructiveness and idempotence, the description fully clarifies the operation's scope and result. The output schema exists and the inline return example augments it; nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description needs no parameter-level guidance. The empty schema is fully covered, and the function's behavior is self-contained; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Tear down every throwaway distro provisioned in this session.' It clearly differentiates from sibling tools like wsl_destroy (targets one distro) and wsl_list_temp (lists only), making the scope explicit.
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 scope 'every throwaway distro provisioned in this session' provides clear context for when this tool is appropriate. It does not explicitly name alternatives or exclusions, but with wsl_destroy as a sibling the intended distinction is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description explicitly warns: 'This is destructive and may cause the target application to lose unsaved data.' It also discloses unintended consequences like killing all processes with a matching name (case-insensitive) and explains the graceful-then-force behavior, adding significant context not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded in the first line, followed by concise parameter guidance, a clear destructive warning, and structured Args/Returns sections. Every sentence earns its place, and the length is appropriate for a destructive tool with multiple safety considerations.
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 the essential behavioral aspects: pid/name selection, force semantics, destructive consequences, and return format (JSON with ok, killed, count). Combined with a well-described schema and annotations, the tool is fully understandable for an agent to invoke correctly and safely.
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 semantic value by stating pid is 'preferred' and explaining the relationship between pid and name (name ignored if pid given). It also clarifies the force flag's effect. While the schema already has good descriptions, the description's concise summary and prioritization guidance provide additional 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 opens with a specific verb and resource: 'Kill a process by PID, or all processes matching an exact name.' This clearly identifies the tool's action and scope, and differentiates it from sibling tools like list_processes (read-only) and run_command (general execution).
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 pid vs name ('Provide either pid (preferred) or name') and explains the force flag for hard vs graceful termination. However, it does not explicitly mention alternative tools or situations to avoid using this tool, but the guidance is sufficient for the primary use case.
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/Ding-Ding-Projects/lowlevel-computer-use-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Ding-Ding-Projects/lowlevel-computer-use-mcp)

Score Badge

Copy to your README.md:

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

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