GNOME Desktop MCP
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as separate mouse actions (click, drag, scroll) and window operations (maximize, minimize, move_resize). However, some overlap exists between key_press and key_combo, which could cause confusion if an agent needs to press a single key versus a combination, though descriptions help clarify.
Naming Consistency5/5All tool names follow a consistent snake_case pattern with clear verb_noun structure, such as activate_workspace, close_window, and screenshot_area. There are no deviations in naming conventions, making the set predictable and easy to parse.
Tool Count3/5With 30 tools, the count is borderline high for a desktop automation server, as it includes many granular actions like separate mouse_down and mouse_up. While comprehensive, it may feel heavy and could be streamlined by grouping related operations, though it covers a broad scope reasonably.
Completeness5/5The tool set provides complete coverage for GNOME desktop automation, including window management (list, focus, close, resize), workspace control, input simulation (keyboard, mouse, typing), screenshots (full, area, window), and system checks (ping, enable/disable). No obvious gaps exist; agents can perform end-to-end automation tasks without dead ends.
Average 3.4/5 across 30 of 30 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Close a window' implies a destructive action (window termination), but it doesn't specify whether this is reversible, what happens to unsaved content, if it requires specific permissions, or what the expected outcome is. For a potentially destructive tool with zero annotation coverage, this is a critical gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with zero wasted language. It's front-loaded with the core action ('Close a window') and doesn't include unnecessary details. For such a simple tool, this brevity is appropriate and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's potential complexity (destructive action with no annotations), the description is incomplete. While an output schema exists (which might cover return values), the description fails to address critical behavioral aspects like safety, reversibility, or prerequisites. For a window management tool among many siblings, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a window' which loosely corresponds to the 'window_id' parameter, but it doesn't explain what a window ID is, how to obtain it, or its format. With 0% schema description coverage (the schema only provides a title 'Window Id' and type 'integer'), the description adds minimal semantic value. Since there's only one parameter, the baseline is higher than for multi-parameter tools, but the description doesn't fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close a window' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this tool from potential alternatives (like 'minimize_window' or 'unmaximize_window') or clarify what type of window is being closed (application window, browser tab, etc.). While the verb 'close' is clear, the description lacks the context needed to differentiate it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. With sibling tools like 'minimize_window', 'unmaximize_window', and 'focus_window' available, there's no indication of when closing is appropriate versus minimizing or other window management actions. No prerequisites, exclusions, or alternative suggestions are mentioned.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Minimize a window') but doesn't explain what happens (e.g., window goes to taskbar/dock, state changes, reversibility with 'unminimize_window'), permissions needed, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Minimize a window.') with no wasted words, making it front-loaded and easy to parse. However, this conciseness comes at the cost of completeness, as it lacks necessary details for effective tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 1 parameter, no annotations, but an output schema exists), the description is incomplete. It doesn't cover parameter semantics, behavioral context, or usage guidelines, and while the output schema might handle return values, the description doesn't reference it or provide enough context for the agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about parameters. The description doesn't mention 'window_id' or explain what it represents (e.g., identifier from 'list_windows'), leaving the parameter's meaning and usage undocumented. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Minimize a window' states the verb (minimize) and resource (window), which is clear but basic. It doesn't differentiate from sibling tools like 'close_window', 'maximize_window', or 'unminimize_window', leaving ambiguity about when to choose one over another. The purpose is understandable but lacks specificity about scope or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'close_window', 'maximize_window', or 'unminimize_window'. The description implies it minimizes a window but doesn't specify prerequisites (e.g., window must be open), exclusions, or contextual cues. This leaves the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Release mouse button' implies a low-level UI automation action but doesn't specify effects (e.g., whether it triggers events, requires prior mouse_down, or has side effects), leaving significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it states the action concisely without unnecessary words. It's appropriately sized and front-loaded, earning full marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a UI interaction tool with 3 parameters) and no annotations, the description is incomplete. It lacks details on behavior, parameter usage, and how it integrates with sibling tools, even with an output schema present, making it insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no parameter information. It doesn't explain what x, y, or button mean, their units, or typical values (e.g., button=1 for left click), failing to provide meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Release mouse button' clearly states the action (release) and resource (mouse button), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'mouse_down' or 'mouse_click', which would require explicit comparison for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'mouse_down' or 'mouse_click', nor does it mention prerequisites or context. It's a standalone statement with no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Drag from one position to another' implies mouse movement with button pressed, but doesn't specify which button defaults to left-click (button=1), whether it automatically handles button down/up events, what happens if coordinates are out of bounds, or any performance/rate limit considerations. For a mouse manipulation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loaded with the core action. Every word earns its place - 'Drag' specifies the action, 'from one position to another' defines the scope. There's zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which presumably handles return values), the description's job is reduced. However, for a mouse manipulation tool with 5 parameters, 0% schema description coverage, and no annotations, the description should provide more context about coordinate systems, button behavior, and interaction patterns. It's minimally adequate but leaves the agent guessing about important implementation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'from one position to another' which implies two coordinate pairs (x1,y1 and x2,y2), but doesn't explain the coordinate system, units, origin point, or what the 'button' parameter controls. With 5 parameters completely undocumented in schema descriptions, the description adds minimal semantic value beyond what's obvious from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Drag from one position to another' clearly states the action (drag) and resource (mouse cursor), providing a specific verb+resource combination. It distinguishes from sibling tools like mouse_click, mouse_move, and mouse_up/down by specifying a dragging motion between two points rather than single-point actions or button states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose mouse_drag over mouse_move+mouse_down/up combinations, or when it might be preferable to other mouse manipulation tools. There's no context about prerequisites, timing, or integration with other 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?
No annotations are provided, so the description carries full burden. It implies a mutation ('enable or disable'), but doesn't disclose behavioral traits like permissions needed, whether changes are reversible, side effects (e.g., stopping active automations), rate limits, or error conditions. This is inadequate for a tool that likely alters system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just three words—with zero wasted text. It's front-loaded and efficiently conveys the core action, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (mutating automation state) and lack of annotations, the description is incomplete. It doesn't explain what 'automation' entails, how it interacts with siblings, or what the output schema returns. With an output schema present, return values might be documented elsewhere, but the description fails to provide enough context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 1 parameter and 0% schema description coverage, the description doesn't add specific parameter details, but it implicitly clarifies the 'enabled' parameter's purpose (to toggle automation on/off). Since there are 0 parameters with descriptions in the schema, the baseline is 4, as the description provides minimal but sufficient context for the single boolean input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable or disable automation' states a clear verb ('enable/disable') and resource ('automation'), but it's vague about what specific automation is being controlled. It doesn't distinguish this tool from potential siblings like 'activate_workspace' or other configuration tools, leaving ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With siblings like 'get_enabled' (likely for checking status), 'activate_workspace', and various window/input tools, there's no indication of prerequisites, context (e.g., system-wide vs per-workspace), or exclusions, leaving the agent to guess.
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?
No annotations are provided, so the description carries the full burden. It states the tool checks a status, implying a read-only operation, but doesn't disclose behavioral traits such as permissions needed, rate limits, or what 'enabled' means in this system. This leaves gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally complete. However, for a tool with no annotations and in a context with many siblings, it lacks depth on automation scope and usage context, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't add unnecessary information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if automation is enabled' clearly states the tool's purpose with a specific verb ('Check') and resource ('automation'), but it doesn't differentiate from siblings like 'set_enabled' or explain what 'automation' refers to in this context. It's adequate but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or comparisons to siblings like 'set_enabled' or other automation-related tools, leaving usage context implied at best.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Maximize a window' implies a visual state change but doesn't specify effects (e.g., whether it affects other windows, requires focus, or has side effects like hiding taskbars). It also doesn't mention error conditions (e.g., invalid window_id) or response format, leaving critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word ('Maximize', 'a', 'window') earns its place by conveying essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, no annotations, and an output schema (which likely covers return values), the description is minimally complete. It states what the tool does but lacks context on behavior, usage, and parameter meaning. For a simple state-change tool, this might be adequate, but gaps in transparency and guidelines reduce completeness below optimal levels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (window_id) with 0% description coverage, so the description must compensate. 'Maximize a window' implies a window identifier is needed but doesn't explain what window_id represents (e.g., system handle, application-specific ID) or how to obtain it (e.g., from list_windows). This adds minimal semantic value beyond the schema's type information, meeting the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Maximize a window' clearly states the action (maximize) and target resource (a window), making the purpose immediately understandable. It distinguishes from siblings like 'minimize_window' and 'unmaximize_window' by specifying the opposite operation. However, it doesn't specify what 'maximize' means in this context (e.g., full-screen vs. filling available space), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'unmaximize_window' or 'move_resize_window'. It doesn't mention prerequisites (e.g., window must exist or be visible) or typical use cases. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention side effects (e.g., potential UI changes), performance characteristics, error conditions, or what the double-click actually triggers in the system. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool and front-loads the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (basic UI interaction) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema description coverage, it should provide more context about behavior and parameters to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only implies parameters through 'screen coordinates' (hinting at x and y). It doesn't explain the 'button' parameter or provide any format details. The description adds minimal value beyond what the schema structure shows, meeting baseline expectations for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Double-click') and target ('at screen coordinates'), providing a specific verb+resource combination. It distinguishes from siblings like 'mouse_click' by specifying the double-click action, though it doesn't explicitly contrast with other mouse operations beyond the name difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'mouse_click' or other mouse operations. There's no mention of prerequisites, typical use cases, or when not to use it, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the action but doesn't disclose behavioral traits such as whether this requires focus on a specific window, if it's reversible, or what happens if coordinates are out of bounds. More context is needed for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's action, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 3 parameters) and no annotations, the description is minimal. It states the action but lacks details on parameters, usage context, or behavioral effects. With an output schema present, return values are covered, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no parameter information. The description doesn't explain what x, y, or button represent, leaving parameters undocumented. Baseline is 3 since schema coverage is low but description fails to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press mouse button down') and specifies 'without releasing', which distinguishes it from a full click. However, it doesn't explicitly differentiate from sibling tools like 'mouse_click' or 'mouse_up' beyond the implied difference in action completion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'mouse_click' or 'mouse_up' is provided. The description implies it's for initiating a mouse press, but lacks context on typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'character by character' typing, which implies a sequential, potentially slower operation, but doesn't cover critical aspects like execution speed, error handling, or whether it simulates human-like typing. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, with the core purpose stated upfront in the first sentence and parameter details neatly organized in an 'Args' section. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (simulating text input) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and low schema coverage, it lacks details on behavioral traits and parameter nuances, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with only one parameter 'text' documented minimally in the schema. The description adds a brief explanation ('Text to type'), which provides basic semantics but doesn't elaborate on constraints (e.g., length, special characters) or examples. Given the low schema coverage, this is a baseline compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Type text character by character') and specifies the resource ('text'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'key_press' or 'key_combo' that might also input text, leaving some ambiguity about when to choose this specific method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'key_press' or 'key_combo' for text input. It lacks context about scenarios where character-by-character typing is preferred over other methods, offering minimal usage direction.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't describe what 'unmaximize' entails (e.g., restoring to previous size/position), whether it requires specific window states or permissions, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Unmaximize a window.' It's front-loaded with the core action and wastes no words. Every part of the sentence directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, simple action) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral context, it leaves gaps in understanding how the tool behaves in practice. It meets basic requirements but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage and 1 parameter (window_id), the schema only indicates it's a required integer. The description doesn't explain what window_id represents (e.g., how to obtain it from list_windows) or its format. However, with only one parameter, the baseline is 4, but since no value is added, it scores 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unmaximize a window' clearly states the action (unmaximize) and resource (a window) with a specific verb. It distinguishes from siblings like maximize_window and minimize_window by indicating the opposite action of maximizing. However, it doesn't explicitly differentiate from unminimize_window, which is a similar but distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., window must be maximized), when-not-to-use scenarios, or explicit alternatives like minimize_window or move_resize_window for window state management. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('unminimize/restore') but doesn't mention side effects (e.g., whether it changes window focus, requires specific permissions, or has rate limits). This is a significant gap for a mutation tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, using just one sentence that directly states the tool's purpose. Every word earns its place, with no redundant or unnecessary information, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, but with an output schema), the description is minimally adequate. It explains what the tool does but lacks details on usage context, behavioral traits, or parameter meaning. The presence of an output schema means return values are documented elsewhere, but the description should still cover more for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the schema provides (a single 'window_id' parameter). With 0% schema description coverage, the description doesn't compensate by explaining what 'window_id' represents or how to obtain it. However, since there's only one parameter, the baseline is 4, but the lack of any semantic context reduces it to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('unminimize/restore') and resource ('a window'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'maximize_window' or 'unmaximize_window', but the verb 'unminimize' is specific enough to imply its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites (e.g., the window must be minimized) or compare it to similar tools like 'unmaximize_window' or 'focus_window', leaving the agent to infer usage context from the name alone.
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?
No annotations are provided, so the description carries full burden. It describes the action ('Switch to a workspace') but lacks behavioral details such as whether this changes the active workspace globally, requires specific permissions, has side effects (e.g., rearranging windows), or what happens on invalid input. The description is minimal and misses key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, no annotations, and an output schema (which handles return values), the description is minimally adequate. It states the purpose and parameter semantics but lacks usage guidelines and behavioral transparency, leaving gaps in understanding when and how to use the tool effectively. It's complete enough for basic use but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 1 parameter and 0% schema description coverage, the description adds essential meaning by specifying the parameter is an 'index (0-based)', which clarifies the input type and format beyond the schema's generic 'integer'. This compensates well for the low schema coverage, though it doesn't detail constraints like valid range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Switch to') and resource ('a workspace'), specifying it's done by index (0-based). It distinguishes from siblings like 'list_workspaces' (which lists) and 'focus_window' (which targets windows), but doesn't explicitly differentiate from all workspace-related tools, as there are none other than 'list_workspaces' in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites (e.g., needing to know workspace indices from 'list_workspaces'), exclusions, or compare to other navigation tools like 'focus_window'. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. 'Remove all temporary screenshot files' implies a destructive operation, but doesn't specify whether this is reversible, what 'temporary' means, which directories are affected, or whether user confirmation is required. For a destructive tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a simple cleanup operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations but with an output schema (which handles return values), the description is minimally adequate. It states what the tool does but lacks important behavioral context about the cleanup scope, safety considerations, and relationship to other screenshot tools. The output schema existence prevents this from being a 1 or 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for parameterless tools where the schema provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target resource ('all temporary screenshot files'), providing a specific verb+resource combination. It doesn't explicitly differentiate from sibling tools like 'screenshot' or 'screenshot_area', but the purpose is unambiguous within the context of screenshot-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like whether screenshots must exist), timing considerations, or relationship to sibling screenshot tools. The agent must infer usage from 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states it's a listing operation but doesn't disclose whether it requires permissions, how data is formatted, if there are rate limits, or what happens on failure. The description is functional but lacks depth for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded with the core action ('List all monitors') and adds only essential detail ('with their geometry and scale'). Every word serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, has output schema), the description is adequate but minimal. It explains what data is returned but doesn't provide context about the operating environment, data format, or error handling. The existence of an output schema reduces the need to describe return values, but more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage, so no parameter documentation is needed. The description appropriately focuses on what the tool does rather than inputs, earning a high baseline score for not introducing unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all monitors'), specifying what data is returned ('with their geometry and scale'). It distinguishes this as a read-only listing tool among siblings that include window manipulation and screenshot tools, though it doesn't explicitly contrast with specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for retrieving monitor information, it doesn't mention prerequisites, timing considerations, or compare it to other tools like 'get_window' or 'list_windows' that might provide related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Press') but doesn't clarify effects like whether this triggers system shortcuts, requires specific permissions, or has side effects (e.g., opening applications). This is a significant gap for a tool that interacts with the system at a low level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, with a clear purpose statement followed by a brief parameter explanation. Every sentence adds value, and it's front-loaded with the main action, making it efficient for quick understanding without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interacting with system inputs) and the presence of an output schema, the description is minimally adequate. It covers the basic action and parameter format but lacks details on behavioral traits, error handling, or output interpretation, which are crucial for safe and effective use in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains the 'keys' parameter as a combo with examples like 'Ctrl+Alt+t', clarifying the expected format and syntax. This compensates well for the schema's lack of documentation, though it could specify more about valid key names or modifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press a key combination') and specifies the resource (key combinations like 'Ctrl+Alt+t'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'key_press' or 'type_text', which might have overlapping functionality for keyboard input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'key_press' or 'type_text' from the sibling list. It lacks context about scenarios where key combinations are preferred over single key presses or text typing, leaving the agent without usage direction.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it lists workspaces but doesn't describe what 'properties' include, whether it's a read-only operation, if there are rate limits, or how results are returned (e.g., pagination). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally complete. However, with no annotations and siblings like 'activate_workspace', it could benefit from more context on usage or behavior. The output schema likely handles return values, so the description doesn't need to explain those, but overall completeness is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. Baseline for 0 parameters is 4, as the schema fully covers the absence of inputs, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all workspaces with their properties'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'list_windows', but for a zero-parameter tool with no direct siblings for listing workspaces, this is adequate. The description avoids tautology by specifying what gets listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it lists only active workspaces or all available ones. With siblings like 'activate_workspace' and 'get_window', some usage context would help, but none is given.
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?
No annotations are provided, so the description carries full burden. It mentions the direction mapping for dy, which is useful behavioral context. However, it fails to disclose critical traits: whether scrolling is relative or absolute, if it requires focus on a window, potential side effects, or response format. For a tool with 4 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with zero waste. It front-loads the core action ('Scroll at screen coordinates') and adds essential direction clarification. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and an output schema (which reduces need to explain returns), the description is minimally complete. It covers the tool's basic function and dy semantics but misses details on other parameters, behavioral context, and usage scenarios. For a low-complexity tool, it's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains dy's meaning (negative=up, positive=down), adding value beyond the schema. However, it doesn't cover x, y, or dx parameters, leaving their purposes unclear (e.g., x/y as coordinates, dx as horizontal scroll). With 4 parameters and low coverage, this partial explanation is minimal but adequate for baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Scroll at screen coordinates' specifies the action (scroll) and target (screen coordinates). It distinguishes from siblings like mouse_move or mouse_click by focusing on scrolling. However, it doesn't explicitly mention what is being scrolled (e.g., windows, content), leaving some 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining coordinate system and direction: 'dy negative=up, positive=down' suggests when to use specific dy values. However, it lacks explicit guidance on when to choose this tool over alternatives like mouse_drag or key_press for scrolling, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('Focus and raise') but lacks details on behavioral traits: e.g., what 'raise' means (bring to front), whether it requires specific permissions, if it works on minimized windows, or error conditions. The description is minimal and doesn't compensate for missing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the purpose clearly, and the second provides essential parameter guidance. Every sentence earns its place with no wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic action and parameter source but lacks details on behavioral aspects like what happens on failure or system-specific constraints, leaving gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful context: it explains that 'window_id' is a 'stable ID (from list_windows)', clarifying the parameter's source and purpose beyond the schema's basic type (integer). With only one parameter, this compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Focus and raise a window') and identifies the resource (a window). It distinguishes from siblings like 'close_window' or 'minimize_window' by specifying the focus/raise action. However, it doesn't explicitly differentiate from potential overlap with 'activate_workspace' or 'get_window' in terms of window management context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing 'window_id: The window's stable ID (from list_windows)', suggesting this tool should be used after obtaining window IDs from 'list_windows'. No explicit guidance on when not to use it or alternatives is provided, though the context hints at a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the button mapping (1=left, 2=middle, 3=right) but fails to explain critical behaviors like whether this triggers a full click event (down and up), if it requires focus on a specific window, or what the output schema contains. This is inadequate for a mutation tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly convey essential information: the action and button semantics. Every word earns its place, and it is front-loaded with the core purpose, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has an output schema), the description is partially complete. It covers parameter semantics adequately but lacks behavioral context and usage guidelines. The presence of an output schema reduces the need to explain return values, but overall completeness is limited due to missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains that 'x' and 'y' are screen coordinates and defines the 'button' parameter values (1=left, 2=middle, 3=right), including a default not explicitly stated in the schema. This compensates well for the low schema coverage, though it could specify coordinate ranges or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Click') and resource ('at screen coordinates'), distinguishing it from sibling tools like mouse_move, mouse_drag, or mouse_double_click. It explicitly defines the verb and target, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mouse_double_click or mouse_drag. It lacks context about typical use cases, prerequisites, or exclusions, leaving the agent without usage direction.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not describe what happens after the move (e.g., whether it triggers events, requires permissions, or has side effects like cursor visibility changes). For a tool that interacts with the system UI, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 simple parameters) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks behavioral details. It covers the basic action but misses context like error conditions or system dependencies, which are important for UI automation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context by specifying that coordinates are 'absolute screen coordinates,' which clarifies the parameter semantics beyond the schema's basic integer types. With 0% schema description coverage and 2 parameters, this compensates well, though it could further explain coordinate systems (e.g., origin at top-left).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Move the mouse') and target ('to absolute screen coordinates'), distinguishing it from sibling tools like mouse_click, mouse_drag, or mouse_scroll which involve different mouse interactions. It precisely communicates the tool's function without redundancy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where mouse_move is appropriate compared to mouse_drag (for dragging) or mouse_click (for clicking after moving), nor does it specify prerequisites like requiring the system to be enabled or in a certain state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format but omits critical details like permissions needed (e.g., screen capture access), potential side effects (e.g., if it requires focus or alters state), error handling, or performance implications (e.g., rate limits). This leaves significant gaps for a tool interacting with screen data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured sections for args and returns. Every sentence adds value without redundancy, making it efficient and easy to parse. The bullet-point style enhances readability without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (screen interaction with 2 parameters), no annotations, and an output schema that covers return values, the description is partially complete. It explains the basic operation and return format but lacks context on behavioral aspects like permissions or errors, making it adequate but with clear gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that x and y are coordinates in pixels, which clarifies their purpose beyond the schema's basic integer types. However, it doesn't detail coordinate origin (e.g., top-left vs. bottom-left) or valid ranges, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the pixel color') and resource ('at screen coordinates'), distinguishing it from sibling tools like screenshot or mouse operations. It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like screenshot tools or other screen-related functions. It lacks context about prerequisites, such as screen accessibility or coordinate system details, and offers no explicit when/when-not scenarios.
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?
No annotations are provided, so the description carries the full burden. It describes the tool as getting detailed properties, which implies a read-only operation, but doesn't disclose behavioral traits like whether it requires specific permissions, rate limits, or what 'detailed properties' includes. The description adds basic context but lacks depth for a tool with no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the main purpose stated clearly in the first sentence and additional parameter details in a concise 'Args' section. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), no annotations, but an output schema exists, the description is fairly complete. It covers the purpose and parameter semantics adequately. However, it could benefit from more behavioral context, such as what 'detailed properties' entails, but the output schema likely handles return values, so this isn't critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% schema description coverage. It explains that window_id is 'The window's stable ID (from list_windows),' clarifying its source and stability. This compensates well for the low schema coverage, though it doesn't detail format or constraints beyond the basic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get detailed properties of a specific window,' which is a specific verb (get) and resource (window properties). It distinguishes from siblings like list_windows (which lists windows) and screenshot_window (which captures images), but doesn't explicitly contrast with all similar tools like focus_window or maximize_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the window_id comes 'from list_windows,' suggesting this tool should be used after listing windows. However, it doesn't provide explicit guidance on when to use this versus alternatives like focus_window or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'Returns JSON array' without detailing behavioral aspects like whether it's real-time/snapshot data, permissions needed, rate limits, or error conditions. It mentions output structure but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second specifies return format. No wasted words, front-loaded with core functionality, and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, 100% schema coverage, and an output schema (implied by return description), the description is mostly complete. However, it lacks behavioral context (e.g., data freshness, errors), which is a minor gap for a read-only tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100% (empty schema). The description adds no parameter info (none needed), so it meets the baseline of 4 for zero-parameter tools without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all open windows with their properties'), making the purpose specific and unambiguous. It distinguishes from siblings like 'get_window' (single window) and 'list_workspaces' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving window information, but provides no explicit guidance on when to use this versus alternatives like 'get_window' (for a specific window) or 'list_workspaces' (for workspace-level info). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('press and release') but doesn't mention important behavioral aspects like whether this simulates a keyboard event, what system context it operates in, potential side effects, or error conditions. The description is minimal and leaves key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core purpose in the first sentence. The parameter documentation is brief but informative. Every sentence earns its place with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (single parameter, has output schema), the description is adequate but minimal. With no annotations and a basic input schema, it could benefit from more context about system dependencies, error handling, or practical usage examples. The presence of an output schema reduces the need to describe return values, but more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 1 parameter, the description compensates well by providing specific examples of valid key names ('Return', 'a', 'F5', 'Ctrl', 'Escape'). This adds meaningful context beyond the bare schema, though it doesn't provide a comprehensive list or formal specification of allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Press and release a single key') and distinguishes it from sibling tools like 'key_combo' (which likely handles multiple keys) and 'type_text' (which likely handles text strings). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single-key actions, but doesn't explicitly state when to use this vs. alternatives like 'key_combo' or 'type_text'. It provides clear context about what the tool does, but lacks explicit exclusions or comparisons with 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?
No annotations are provided, so the description carries full burden. It mentions the action but lacks behavioral details like permissions needed, whether it captures only visible areas, if it requires screen recording access, or error conditions. The description doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a well-structured parameter breakdown. Every sentence adds value with no wasted words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations) and the presence of an output schema, the description is mostly complete. It explains parameters thoroughly but lacks behavioral context like side effects or error handling, which would be helpful despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining all 6 parameters in detail: pixel coordinates, dimensions, cursor inclusion, and output format options. It adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a screenshot') and resource ('rectangular screen region'), distinguishing it from sibling tools like 'screenshot' and 'screenshot_window' by specifying region-based capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing screen regions but doesn't explicitly state when to use this vs. alternatives like 'screenshot' (full screen) or 'screenshot_window' (specific window). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the action ('Take a full screenshot') and output options ('path' or 'base64'), but lacks details on permissions, side effects, or error handling. It adds some behavioral context but is incomplete for a tool with no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a structured 'Args:' section that efficiently explains parameters. Every sentence earns its place with no wasted words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description covers the purpose and parameters well. However, it lacks details on behavioral aspects like permissions or errors. The output schema likely handles return values, so this is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for both parameters: 'include_cursor' explains its effect on the screenshot, and 'format' details the two return options with their meanings. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a full screenshot of the entire screen') with the resource ('screen'), distinguishing it from sibling tools like 'screenshot_area' and 'screenshot_window' which target specific regions or windows. This provides immediate clarity on what the tool does differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing the entire screen, but does not explicitly state when to use this tool versus alternatives like 'screenshot_area' or 'screenshot_window'. It provides clear context for full-screen captures but lacks explicit exclusions or named alternatives.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the core action (taking a screenshot) and mentions output format options, but doesn't cover important behavioral aspects like file storage location, permissions needed, error conditions, or whether the operation is blocking/non-blocking. The description adds basic context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise: a clear purpose statement followed by a bullet-point style parameter explanation. Every sentence earns its place, with no redundant information. The information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but has output schema), the description covers the essential purpose and parameters well. Since an output schema exists, the description doesn't need to explain return values. However, for a tool that interacts with the system GUI and creates files, more behavioral context about permissions, file management, and error handling would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 4 parameters: window_id's source (list_windows), include_frame's effect (window decorations), include_cursor's effect (mouse cursor), and format's options/meaning (path vs base64). Each parameter's purpose is explained beyond just naming them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a screenshot') and resource ('of a specific window'), distinguishing it from sibling tools like 'screenshot' (general screenshot) and 'screenshot_area' (area screenshot). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'of a specific window' and referencing 'list_windows' as the source for window_id, which helps differentiate it from other screenshot tools. However, it doesn't explicitly state when NOT to use this tool or name alternatives like 'screenshot_area' for partial screenshots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond basic functionality by stating 'Unmaximizes first if needed,' which informs about side effects and preconditions. However, it doesn't cover other behavioral aspects like error conditions, permissions needed, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core functionality stated first ('Move and resize a window. Unmaximizes first if needed.') followed by a structured Args section. Every sentence earns its place, and there is no redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 5 parameters), no annotations, and an output schema present, the description is fairly complete. It covers the main action, side effects, and parameters, but could benefit from more behavioral details like error handling or coordinate system explanations. The output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explicitly lists all 5 parameters with brief explanations (e.g., 'New X position'), adding meaning beyond the schema's titles. This clarifies the purpose of each parameter, though it doesn't provide detailed constraints or units (e.g., pixel coordinates).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('move and resize a window') and distinguishes it from sibling tools like maximize_window, minimize_window, and unmaximize_window. It also mentions the unmaximization behavior, which adds specificity beyond just the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to move and resize windows) and implicitly distinguishes it from alternatives like maximize_window or minimize_window. However, it lacks explicit guidance on when not to use it or detailed prerequisites, such as whether the window must be visible or focused.
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?
No annotations are provided, so the description carries the full burden. It effectively discloses the tool's behavior as a health check that returns a response indicating operational status. However, it doesn't specify what the response format is (though an output schema exists) or mention potential failure modes like timeouts or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any redundant words. It's front-loaded with the core action and appropriately sized for a simple diagnostic tool, making it easy to parse and understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema provided), the description is complete. It clearly explains what the tool does, when to use it, and its behavioral intent. The output schema will handle return value details, so no additional explanation of results is needed in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, but it implicitly confirms there are no required inputs by focusing solely on the check action. This aligns perfectly with the empty input schema, providing adequate semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check if the extension is running and responding') with a precise verb ('Check') and resource ('the extension'). It distinguishes itself from all sibling tools, which perform various window management, input simulation, and screenshot operations, by focusing solely on system health verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Check if the extension is running and responding.' This provides clear context for verifying system availability before attempting other operations. No sibling tools serve this diagnostic purpose, making the usage guidance complete and unambiguous.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/sbuysse/gnome-desktop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server