hypr-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct resource or action. Overlapping categories (type_text, key_press, paste_text) are clearly differentiated by use case, and OCR tools (find_text_on_screen, wait_text, click_text) have precise roles. No ambiguity that would cause an agent to select the wrong tool.
Naming Consistency5/5All tools follow a consistent snake_case verb_noun pattern (list_monitors, switch_workspace, mouse_click, clipboard_write). The verbs are predictable and the naming is uniform, making the set highly readable and navigable.
Tool Count2/5With 27 tools, the count exceeds the 25+ threshold for 'too many'. While the domain is broad (window management, input, OCR, clipboard), the tool surface feels heavy and could potentially be consolidated. The scope justifies many tools, but the sheer number edges into over-provisioning.
Completeness4/5The toolset covers window lifecycle, workspace switching, input control, OCR, clipboard, and screenshots. Minor gaps exist (e.g., no minimize or workspace creation), but core automation workflows are fully supported, and agents can accomplish most tasks without dead ends.
Average 3.3/5 across 27 of 27 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.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
- 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 discloses only the surface action ('Drag in absolute coordinates') but leaves essential behaviors undisclosed: whether it is a press-move-release, how duration/timing is handled, button behavior (left/right/middle), potential side effects, or whether the mouse is moved with the button held. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of fluff, which is good. It gets to the core verb and mode immediately. However, its brevity sacrifices essential detail, so while there is no waste, it is under-specified rather than just concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (4 required), no annotations, and an output schema that does not compensate for missing explanation, the description is far from complete. It does not cover what 'absolute coordinates' refer to, the coordinate space, typical usage patterns, or how the drag is intended to behave. An agent cannot confidently predict the tool's effect or its return outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only says 'absolute coordinates' but gives no indication that start_x/start_y define the drag origin and end_x/end_y the destination, nor does it describe the button parameter (left/right/other). The description adds almost no meaning beyond the parameter names themselves.
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 states a specific action ('drag') and the coordinate system ('absolute'), which distinguishes it from move/click/scroll siblings. However, it leaves the object (mouse) and the nature of the drag (button held, press/release behavior) implicit, so the purpose is only moderately clear.
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 is provided about when to use this tool versus the many sibling tools (e.g., mouse_move, mouse_click). There is no mention of scenarios that favor dragging, no exclusions, and no alternative routing. The usage context is only implied by the word 'drag'.
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, the description carries the full burden of behavioral disclosure. It says what is listed but does not mention default behavior (e.g., all windows vs. current workspace), ordering, whether hidden/minimized windows are included, or any side effects. The output schema exists but is not shown in the description, so return format details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and attributes. It is efficient with no fluff, but it sacrifices useful detail about parameters and behavior.
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?
The tool has a relatively simple listing purpose, and the output schema exists (though not shown), which compensates somewhat. However, the unexplained optional parameters and lack of behavioral context (default scope, filtering semantics) leave meaningful gaps for an agent deciding how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the optional 'monitor' and 'workspace' parameters at all. It does not clarify their format, allowed values, or filtering effect. The schema provides only type and default, leaving agents to guess how to use these filters.
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 a specific verb ('List') and a resource ('windows'), and specifies the returned attributes (class, title, size, position). It distinguishes the purpose from siblings like focus_window or close_window, though it could more explicitly contrast with list_monitors/list_workspaces.
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, such as filtering by monitor/workspace or when a more specific window lookup is needed. The optional parameters suggest filtering, but the description does not state their purpose or when to use them.
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, and it falls short. It does not reveal what occurs when x/y are null (presumably scroll at current position), whether the tool mutates state permanently, what the response contains, or how amount and direction map to actual scroll distance. The 'optionally after moving' phrase hints at a combined behavior but leaves its semantics unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and the core action is front-loaded, which is structurally sound. However, the brevity borders on under-specification; every word has a purpose, but several essentials are omitted entirely, so the conciseness does not fully serve the agent.
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 4 parameters, 0% schema coverage, and no annotations, the description is markedly incomplete. Even with an output schema present, the agent lacks crucial call-time information: direction value enumeration, amount semantics, null-coordinate behavior, and any side-effect or return details. The single sentence is not enough for correct invocation.
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 all four parameters (x, y, amount, direction) are undocumented in both the schema and the description. The description only glosses x and y as 'absolute coords' and implies a scroll operation, but never clarifies valid values for direction (up/down/left/right), the meaning of amount (lines vs. pixels), or the null behavior for x/y. It adds minimal meaning but does not fill the coverage gap.
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 states a specific verb ('scroll'), a resource ('wheel'), and adds the scope detail 'optionally after moving to absolute coords,' which differentiates it from siblings like mouse_move (which only moves without scrolling) and mouse_click (which clicks). This is clear enough for an agent to distinguish it from the toolbar cluster, though it stops short of naming an explicit sibling comparison.
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 given on when to choose this tool over alternatives. It does not state that mouse_move should be used when only repositioning is needed, nor describe a scenario (scrolling through content) that would select this tool. The only implicit signal is the verb itself, which is insufficient among 28 keyboard/mouse siblings.
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 it is an 'OCR-search' and returns coordinates but does not disclose that OCR may be slow or error-prone, what happens if text is not found (returns null? throws?), how it determines scope (e.g., auto-detect), or any system prerequisites. It also doesn't indicate whether it performs a single search or a continuous loop. The description is too thin for a tool that could have significant behavioral side effects (e.g., triggering OCR engine).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded with the key purpose and output. There is no wasted text. However, it is perhaps too short given the need for parameter and behavior information, but conciseness is about efficiency, not completeness. It earns a 4 for being succinct and front-loading the critical info.
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?
The tool is moderately complex with 5 parameters and an output schema. Given the context of a screen interaction tool, the description should explain the meaning of 'scope', 'region', 'window', 'monitor', and what the return value looks like (e.g., x, y coordinates or null). It lacks clarity on how to use these parameters effectively. Also, it should note that the tool is often used with 'mouse_click' and 'click_text'. The description is insufficient for effective usage.
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%, meaning the description provides no details about 'target', 'scope', 'region', 'window', 'monitor'. The description says search for text, but 'scope' and 'region' are ambiguous; 'window' and 'monitor' suggest scoping, but no explanation is given. With zero coverage, the description must compensate, but it doesn't. It adds only the trivial 'target' is the text, which is inferable from the 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 states a specific verb ('OCR-search') and a clear resource ('text') and importantly specifies the output ('absolute coords for mouse_click'), which distinguishes it from OCR-recognition tools. It doesn't name any sibling explicitly, but the context (sibling tools like 'click_text', 'wait_text') implies it's the search part of the pipeline. It is clear and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies usage by the name and output ('for mouse_click'), but doesn't mention that it should be used before 'click_text' or how it differs from 'wait_text' (which likely searches for text but waits). There is no 'when not to use' or alternative mentions.
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?
Without any annotations, the description must disclose behavioral traits. It only states the action without mentioning side effects, persistence, whether it fails on certain window states, or if it alters the active window. The description is a bare operation statement, providing no additional behavioral context beyond the obvious resizing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It is efficient and free of filler. However, it may be too terse, lacking any structure to accommodate additional necessary context, but for pure conciseness it scores well.
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 has an output schema (though not shown), return values may be covered there, but the description itself is incomplete for a window-resizing action. It does not mention behavior in edge cases, error conditions, or whether the operation is atomic or reversible. With no annotations and minimal description, an agent would lack essential context to safely invoke this tool.
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?
With 0% schema description coverage, the description carries the full burden for parameter clarity. It mentions 'pixel dimensions', implying width/height units, but does not explain the optional 'target' parameter at all. There is no clarification on constraints (e.g., min/max, positive integers) or how 'target' selects a window. The description adds minimal value beyond what the schema already shows.
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 states a specific action (resize), a clear resource (window), and the manner (to pixel dimensions). It is unambiguous about the primary function. However, it does not differentiate from sibling tools like move_window or focus_window, but the core purpose is clear enough.
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?
There is no guidance on when to use this tool versus alternatives. It does not specify prerequisites like having an active/selected window, nor does it contrast with sibling tools. The phrase 'active/selected' hints at context but offers no explicit usage instructions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains the action enum but does not say what happens when target is null, whether the change affects the focused window or a specified target, or whether the operation has side effects such as toggling layout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core operation, and the action values are listed compactly. It is concise without fluff, though it achieves brevity at the cost of leaving target semantics unexplained.
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?
For a state-changing tool with no annotations and undocumented parameters, this description is incomplete. An agent cannot confidently invoke it because critical context about target resolution and the effect of each action is missing, even though an output schema exists.
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. It adds meaning for the action parameter by listing 'set'|'unset'|'toggle', but it gives no semantics for the target parameter, which remains ambiguous between a window id, workspace name, or null meaning the focused window.
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 states a specific operation, 'Set floating state', and tells the agent the possible values for the action parameter. It is clear enough on what the tool does, though it doesn't explicitly distinguish itself from the sibling toggle_special beyond the word 'floating'.
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?
There is no guidance on when to use this tool versus alternatives like toggle_special, focus_window, or switch_workspace. The description implies the purpose but never states a condition or context that would route an agent to this tool.
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?
There are no annotations, so the description carries the burden of disclosing behavior. It implies the tool changes the active window, which is a mutating action (not read-only), but does not state any side effects like changing the user's current focus, potential to steal focus from the application, or whether it requires a visible window. It also doesn't mention what happens if the target is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, with selector format inline. It is not overly verbose, and the length is appropriate for the tool's simplicity. Every word adds value, except it could be slightly clearer about the selector syntax.
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?
This is a simple tool with one parameter and an output schema (though its content is not shown). The description explains the core functionality and the selector format, but does not clarify the output (likely void or success status), nor the exact selector syntax. For a simple tool, it is adequate but not complete—missing edge cases like invalid selectors or focus failure behavior.
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%, meaning the schema provides no description for the 'target' parameter beyond its type. The main description gives examples of valid selectors ('class:firefox', 'title:Doc', 'address:0x...'), which is helpful, but does not explain the syntax in detail (e.g., how to use wildcards, escaping, multiple criteria). This partial guidance is insufficient for the single required parameter.
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: to focus a window, using a selector format. It specifies the verb 'Focus' and the resource 'window', and the selector types are given as examples. While it doesn't explicitly distinguish from sibling tools like list_windows or close_window, the purpose is clear enough for a simple 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 does not mention that this tool is for setting focus rather than listing or modifying windows, and there are many window-related siblings. Without a 'when to use' or 'when not to use' note, agents may pick this tool incorrectly.
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 does not state whether the window is also focused after moving, what happens when both pixels and workspace are specified, how 'special:name' works, or any failure modes. The description is silent on side effects and edge cases, leaving significant ambiguity.
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 concise sentence with no redundancy. The core action and object are front-loaded ('Move active/selected window'), making it immediately scannable. Every word contributes to stating the tool's basic function.
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?
Despite having an output schema, the description does not mention return values. More critically, it leaves 'target' and 'special:name' unexplained, and does not cover parameter combinations. For a tool with four optional parameters, this level of incompleteness is inadequate for reliable agent invocation.
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 clarify parameter meanings. It mentions 'pixels' (likely x,y) and 'workspace', but does not explain the 'target' parameter at all. It also does not clarify the format of 'special:name' or how parameters interact. The description adds minimal meaning beyond the bare 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 uses a specific verb ('Move') with a clear resource ('active/selected window') and specifies the action (to pixels and/or workspace). It distinguishes from siblings like focus_window, but could better differentiate from switch_workspace, which also involves workspaces. Still, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that switch_workspace should be used for switching the active workspace, nor does it state any prerequisites or conditions. The phrase 'active/selected window' implies context, but fails to provide actionable 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, the description carries the full burden of explaining side effects. It states that the tool 'Toggle[s]' a workspace, which implies a state change, but it does not disclose what changes: visibility, active status, or existence, nor whether the operation can create or destroy the scratchpad.
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 one concise sentence with no filler. 'Toggle' states the action, 'special (scratchpad) workspace' defines the resource, and 'by name' identifies the input, making the structure front-loaded 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?
This is a state-changing operation with no annotations and only minimal behavioral disclosure. An agent cannot tell whether toggling a nonexistent name is an error, whether this overlaps with switch_workspace, or what the expected output represents. The description is adequate as a label but not as complete invocation guidance.
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 for the lone `name` parameter. It does clarify that `name` is used as the workspace's name, not an ID, which adds a small amount of meaning beyond the schema. However, it stops short of explaining expected format, exact-match behavior, or what happens when the name is unknown.
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 uses a specific verb ('Toggle') and identifies the exact resource ('special (scratchpad) workspace') plus the selection criterion ('by name'). It is distinguishable from siblings like switch_workspace and list_workspaces, though it relies on the domain term 'scratchpad' rather than explicitly contrasting it with those 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?
The description gives no guidance about when to use this tool instead of switch_workspace or list_workspaces, nor what qualifies as a 'special' workspace. It also does not state prerequisites, such as whether the named scratchpad must already exist or whether this is the canonical way to show/hide a scratchpad.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention whether the clipboard is overwritten, whether system clipboard access is required, or any platform limitations.
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 short sentence that gets directly to the point. Every word earns its place.
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?
For a simple one-parameter tool, the description provides basic completeness. However, without annotations or usage context, an agent cannot infer side effects, failure modes, or when this tool is preferred over clipboard_read.
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 single 'text' parameter is referenced by the description, making its role clear. However, with 0% schema description coverage, the description adds no detail about formatting, size limits, or special characters.
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 ('Write text to clipboard') and the resource (clipboard). It is specific enough to distinguish from clipboard_read, though it does not explicitly contrast with related tools like paste_text or type_text.
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 given about when to use this tool versus alternatives such as paste_text or type_text. The description does not mention exclusions, prerequisites, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool sends WM_CLOSE and that apps may prompt to save, which is useful behavioral context. However, it does not disclose what happens if the target is invalid, whether the tool waits for the window to close, or how it handles multiple windows with the same title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loads the action and mechanism. It earns its place by adding the WM_CLOSE detail and the save-prompt caveat, though it could be slightly more structured.
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?
With no annotations, no parameter explanation, and a nullable target, the description is incomplete. An agent cannot reliably know what value to pass for 'target' or what to expect after calling. The output schema exists but the description does not reference it.
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%, and the description does not explain the 'target' parameter at all. The schema only shows it is a nullable string with a default of null, leaving the agent to guess whether it is a window title, ID, or handle. The description should have clarified this.
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 states a specific verb ('Close') and resource ('a window'), and mentions the mechanism (WM_CLOSE) and a key behavioral caveat (apps may prompt to save). It is clear enough to distinguish from siblings like focus_window or move_window, though it does not explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you want to close a window rather than focus, move, or resize it. It does not explicitly state when not to use it or mention alternatives like wait_window or toggle_special. The context is clear but exclusions are absent.
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 only states that it types text via wtype, but does not explain details such as whether the typing is simulated at the OS level, if there are any side effects (like interfering with the focused window), or if there are rate limits or timing considerations. The description is too sparse for a tool that performs an input action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is to the point)Skip empty line. There is no fluff, but it is under-specified, so it earns a 4 for conciseness rather than a 5 because it lacks necessary detail.
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 that this tool has an output schema (though not described) and two parameters, the description is quite minimal. It does not explain what the output is, if any, or provide sufficient context for how the tool behaves in the broader environment. An agent might need to guess at the effect of 'delay_ms' or whether the tool returns a success indicator. The description is insufficient for robust 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?
Schema description coverage is 0%, meaning the schema does not document the parameters. The description itself does not explain the parameters, but the parameter names ('text', 'delay_ms') are self-explanatory to some extent. However, the description does not add any context about the 'delay_ms' parameter (e.g., units, purpose), so the description only partially compensates for the lack of schema documentation.
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 states the verb 'Type' and the resource 'text', and specifies the implementation tool 'wtype', which gives clarity about its function. It is distinct from sibling tools like 'key_press' or 'paste_text', though it does not explicitly differentiate itself from them. The purpose is clear enough for an agent to understand the core action.
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 does not explicitly state when to use this tool versus alternatives like 'key_press' or 'paste_text'. However, the context implies it is for typing arbitrary text as a string, while 'key_press' is for individual keys and 'paste_text' likely for clipboard content. The usage is implied rather than explicitly guided.
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, the description must carry behavioral details; it does disclose OCR-based lookup and window focusing before clicking. However, it does not explain behavior when text is not found, how region/monitor constrain the search, or whether the click is immediate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action, with the window-focus detail in a second clause. It is appropriately sized, though the brevity leaves behavior and parameters underspecified.
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?
For an 8-parameter tool with no annotations and zero schema descriptions, a one-sentence description is insufficient. The output schema may cover return values, but the meanings of scope, region, occurrence, button, and double are unexplained, leaving important invariants unclear.
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% and the description only adds semantics for window ('focusing window first'). The other seven parameters (target, region, monitor, occurrence, button, double, scope) receive no explanatory value beyond their names.
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?
States a specific verb ('click'), method ('OCR-find'), and target ('text'), plus the window-focus precondition. This clearly distinguishes it from coordinate-based mouse_click and from find_text_on_screen, which only locates text.
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?
Provides no explicit when-to-use or when-not-to-use guidance and names no alternatives, despite siblings like mouse_click and find_text_on_screen occupying adjacent roles. The only implied context is the tool's name and the phrase 'OCR-find text and click it.'
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 reveals only that it can set/unset/toggle between fullscreen and maximize, but it does not disclose the target (active window, workspace, monitor), failure conditions, or side effects. The core mutation is clear, but the behavioral context is incomplete.
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 compact two-clause sentence with no filler: purpose first, then the parameter value list. Every segment contributes to selecting values correctly.
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?
For a simple two-parameter tool with an output schema, the essential values are present, and an agent can construct basic calls. However, the lack of usage or behavioral context and the missing target-window semantics leave meaningful gaps for an agent deciding when and how to invoke the 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?
With 0% schema description coverage and no enums in the schema, the description adds critical meaning by enumerating the valid strings for both mode and action. It maps each value directly to its parameter name, making the tool immediately callable. It does not define each value's behavior, though the terms are largely self-explanatory.
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 and resource: 'Set fullscreen state.' It adds the applicable mode and action values, and the name plus description distinguish it from sibling toggle_* tools like toggle_floating/toggle_special. It doesn't explicitly differentiate those siblings, but the fullscreen resource makes the intent clear.
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?
There is no guidance on when to use this tool versus alternatives, nor mention of prerequisites such as which window or display is affected. The description only lists mode/action options and leaves the selection context to the agent.
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 format of keys but does not explain potential side effects such as key presses affecting the focused window, whether the tool waits for the key release, or if there are any restrictions on which keys can be used. The output schema exists but the description does not clarify what the tool returns or if it can fail (e.g., invalid key combo). This is insufficient for a tool that sends system-level key events.
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 two sentences with no waste, front-loading the core function and examples. It is concise and to the point, 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's actual complexity—a system-level key input with potential side effects—the description is minimal. It does not address error handling, target behavior, or interaction with the focus system. While the output schema exists, the description does not mention return values or failure modes. For a tool that could disrupt user workflows if misused, more detail is needed.
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% as neither 'keys' nor 'target' have descriptions. The description provides some semantics for 'keys' by giving examples like 'ctrl+c' and 'Return', which helps understand the expected format. However, 'target' is left unexplained, and the description does not clarify whether it is for specifying a window or application to receive the key press, leaving a gap for this parameter.
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: pressing keyboard shortcuts or single keys, with examples of both. It identifies the specific action (press) and resource (keyboard input), making it distinguishable from siblings like mouse_click or type_text, though it doesn't explicitly name an alternative.
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 keyboard shortcuts, but provides no guidance on when to use it versus type_text for text entry or paste_text for pasting. It does not mention any exclusions or alternative tools, leaving the agent to infer appropriate 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?
With no annotations, the description is the primary source of behavioral information. It states the action but does not disclose side effects, OS event generation, screen boundaries, or whether the movement is instantaneous. The parenthetical 'pixel-accurate' is minimal added value beyond the action itself.
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 sentence with no filler, front-loading the action and adding the qualifier 'pixel-accurate' immediately. Its brevity is a strength here, as the tool is simple.
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?
For a simple two-parameter tool with an output schema, the description is adequate but thin. It lacks sibling tool differentiation, coordinate origin, and cross-monitor behavior details, which an agent might need to avoid misusing it in a multi-display setup.
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 coverage is 0%, so the description must compensate for the otherwise opaque x and y parameters. It defines them as 'absolute coordinates' using pixels, but does not clarify the coordinate origin or monitor scope, leaving a meaningful but incomplete 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 explicitly states the verb 'move' and resource 'cursor' with the qualifier 'to absolute coordinates (pixel-accurate)', making the core action clear. It does not explicitly differentiate from siblings like mouse_drag or mouse_click, but the phrase 'absolute coordinates' implies a standalone pointer repositioning 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 such as mouse_drag, and it does not mention when to avoid it. The usage context is implicit—'when you need to move the cursor'—but no alternatives or conditions are given.
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 does disclose a key behavior: the tool returns an inline JPEG with coordinate mapping, and that coordinates are absolute. It also discloses the alternative behavior of saving a PNG to disk. However, it doesn't disclose other important behaviors such as what happens with the region/window/monitor parameters, whether the screenshot captures the entire screen by default, or any side effects. The description adds some value but leaves 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 two sentences with zero waste. The primary behavior is front-loaded in the first sentence, and the alternative usage is in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is incomplete. It explains the core output (inline JPEG + coordinate mapping) and the path alternative, but it doesn't explain the other 6 parameters, the default capture scope, or how coordinates are returned. An agent would likely need to guess or experiment to use the tool correctly for non-default scenarios.
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 the 7 undocumented parameters. The description only mentions 'path' (save full-res PNG to disk) and implicitly references the inline JPEG output. It does not explain the meaning of region, window, monitor, quality, max_width, or include_cursor. This is a significant gap for a tool with 7 parameters and no schema descriptions.
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 states a specific verb and resource: 'Screenshot to inline JPEG + coordinate mapping (coords are absolute).' It clearly identifies the tool's primary function and distinguishes it from sibling tools like list_monitors or find_text_on_screen. However, it doesn't explicitly name a sibling alternative for comparison, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 the tool and even gives an alternative usage: 'Pass path to save full-res PNG to disk instead (no token cost) — for debugging OCR without an inline image.' This explains a specific scenario (debugging OCR) and the trade-off (token cost). It doesn't explicitly state when NOT to use the tool or name alternative tools, but the guidance is strong enough for a 4.
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 adds useful behavior ('returns instantly on match', title-change-based waiting), but it does not disclose timeout behavior, what happens on no match, whether it polls, or whether it has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose, and every sentence adds value. No filler or redundant restating of the tool name.
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?
For a wait tool with no annotations, the description is not complete enough for correct invocation. The 'target' parameter is undocumented, the relationship between 'target' and 'title_contains' is unclear, and timeout failure behavior is not addressed.
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 the parameters. It explains title_contains only through an inline example, gives no meaning for 'target' at all, and does not clarify the timeout semantics beyond the schema's default 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 tool waits for a window to exist or reach a title, which distinguishes it from siblings like list_windows, focus_window, and wait_text. It is specific enough about the resource and the condition, though the meaning of the 'target' parameter is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: after launch_app or navigation, with title change as the load signal, and positions the tool as a replacement for blind sleeps. It does not explicitly name alternatives like wait_text or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that coordinates are in absolute layout space rather than screen or window-relative coordinates, which is a meaningful non-obvious detail. The get prefix and zero-parameter signature imply a read-only operation, so additional safety disclosure is less critical.
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?
A single, front-loaded sentence with no filler. It names the resource and the coordinate system without wasting words.
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?
For a zero-parameter read-only query with an output schema, the description covers the key contextual detail (absolute layout coordinates) and needs little else. It does not explicitly describe return values, but the output schema supplies those.
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 parametersaine; baseline is 4. The description adds no parameter information because none exists, and the coordinate-space detail indirectly clarifies what the return value means.
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 states the resource (cursor position) and its coordinate space (absolute layout coordinates), making the tool's purpose immediately understandable. It does not explicitly use a verb, but the tool name 'get_cursor_position' supplies the read action. It is clearly distinct from sibling tools like mouse_move or screenshot.
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 gives no guidance on when to use this tool versus related mouse/input tools, such as before mouse_move or to verify current pointer state. While the purpose is obvious from the name, explicit usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of disclosing behavior. The description only lists the returned fields; it does not state whether the operation is read-only, has side effects, requires permissions, or has any rate limits. For a simple list operation, the lack of explicit safety info is a gap, though the phrasing 'List' implies a read action without stating it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and output fields. It is minimal with no filler, and every word adds value. Efficiently structured for an agent to parse quickly.
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 an output schema exists (indicated by 'Has output schema: true'), the description need not explain returns. The tool is simple with no parameters, and the description covers the purpose and output fields. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100%). The description contains no parameter details, but none are needed. Per the rule, with 0 parameters, the baseline is 4, and the description adequately handles the absence of parameters.
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 states exactly what the tool does: 'List monitors with resolution, position, active workspace.' It uses a specific verb ('List') and resource ('monitors') and specifies the returned attributes. This clearly distinguishes it from sibling tools like list_workspaces or list_windows, which target different resources.
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 vs. alternatives, nor does it mention any prerequisites or exclusions. The context implies it is for querying monitor information, but it does not explicitly say 'use this when you need monitor details' or compare with other tools. Lacks any usage direction.
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 burden. It discloses the mechanism (clipboard + ctrl+v) and the reliability rationale, which is useful behavioral context. However, it doesn't mention side effects like clipboard overwriting, which is a notable gap for a tool that manipulates the clipboard.
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?
One sentence, front-loaded with the key purpose and the differentiator. Every word earns its place; no 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?
The description is adequate for a simple paste operation but lacks details about the 'target' parameter, clipboard side effects, and return behavior. Given the output schema exists, return values are covered, but the missing parameter semantics and side-effect disclosure leave 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 the purpose of the 'text' parameter implicitly (the text to paste) but doesn't clarify the 'target' parameter at all. The description adds some meaning for the main parameter but leaves the optional parameter undocumented.
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 states a specific verb ('paste') and resource ('text'), and explains the mechanism (clipboard + ctrl+v). It distinguishes itself from type_text by noting wtype chokes on unicode/long text, which helps differentiate from the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: for unicode/long text where wtype (likely used by type_text) fails. It doesn't explicitly name the alternative tool or state when not to use it, but the context is clear enough for an agent to select it appropriately.
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 only states 'Switch' which implies mutation, but does not explain what happens on invalid workspace names, whether the operation is synchronous, or if there are side effects like changing focus. For a state-changing action, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and immediately provides illustrative examples. There is zero waste, and the key information is conveyed efficiently.
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?
The description is minimal and adequate for a simple switch operation, but it omits error-handling behavior and any mention of the return value (despite an output schema being present). It also doesn't note that special workspaces might require a prefix. For a tool with no annotations and a single parameter, this is acceptable but not thorough.
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 a single parameter 'workspace' with no description (0% schema coverage). The description compensates by providing example formats ('1', 'special:scratchpad'), which clarifies the expected value shape. However, it doesn't explain the meaning of the 'special:' prefix or enumerate all valid formats, so it adds value but leaves 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 states the action 'Switch to a workspace' with a specific resource (workspace) and provides concrete examples ('1', 'special:scratchpad'). This clearly distinguishes it from sibling tools like list_workspaces (which lists) and toggle_special (which toggles special workspaces). The verb+resource combination is specific 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its purpose (switch to a workspace) but provides no explicit guidance on when to use it versus alternatives. It doesn't mention prerequisites like listing workspaces first, nor does it clarify the difference from toggle_special. However, the examples hint at the workspace naming convention, giving some implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the truncation behavior via max_chars, but does not mention potential issues like clipboard access permissions, empty clipboard handling, or return format nuances. It is minimally sufficient for a simple read operation.
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 sentence that front-loads the primary purpose and includes the key truncation detail with zero fluff. It is efficient and well-structured.
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?
For a simple read tool with one parameter and an output schema present, the description covers the core behavior and the parameter effect. It does not elaborate on error cases or return value details, but for the simplicity of the tool it is reasonably complete.
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 has no descriptions (coverage 0%), but the description explains that max_chars truncates the clipboard text, adding meaning beyond the bare integer type and default value. This effectively compensates for the schema coverage gap.
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 states a specific action ('Read clipboard text') and resource, and mentions truncation, making it distinct from sibling clipboard_write. The verb and object are explicit 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus clipboard_write or any other sibling. It does not mention any prerequisites, alternatives, or cases where it should not be used, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it 'Returns instantly on match,' which is a positive-case behavior, and implies blocking via 'Replaces blind sleeps.' However, it does not disclose timeout behavior (e.g., what happens if the text never appears) or any side effects. The description covers the core operation but omits failure semantics, which is a notable gap for a wait operation. Thus a 3 is appropriate.
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. The first sentence states the core function, the second provides usage context, and it front-loads the most important information. Every sentence earns its place; there is no fluff or redundancy. This is a model of efficiency for a tool description.
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 is an output schema (not shown but flagged as true), return values need not be described. However, the tool has six parameters and zero annotation coverage, and the description only partially explains usage scenarios. It lacks parameter semantics and timeout behavior, which are essential for correct invocation. While the usage guidance is helpful, the overall completeness is moderate, leaving agents with unanswered questions about region, monitor, and timeout handling. A 3 is appropriate.
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%, meaning the description must explain the parameters, but it does not. It implicitly mentions the target (text to wait for) but fails to explain region, window, monitor, timeout, and disappear. The only hint is 'appear (or disappear)' which maps to the disappear parameter, but it's not explicit. With six parameters, the description adds minimal value beyond the schema, leaving agents to guess the meaning of most parameters. A score of 2 reflects this significant gap.
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: 'Wait for on-screen text to appear (or disappear).' It specifies the action (waiting), the resource (on-screen text), and the optional disappearance condition. It also adds context that it 'Replaces blind sleeps,' which helps differentiate it from more primitive approaches. While it doesn't name sibling tools, the unique behavior of text-waiting is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use for in-window state no compositor event covers: button flips (UPDATE→PLAY), page content, dialogs.' This gives concrete scenarios where this tool is appropriate, implying it's for cases where compositor events (e.g., wait_window) won't fire. It doesn't explicitly list when not to use it, but the examples and the 'no compositor event covers' condition are strong enough to route the agent. A score of 4 is warranted because it lacks explicit alternative names but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only behavioral disclosure. It communicates two non-obvious behaviors: `window` is focused first, and coordinates remain absolute even after focusing. This helps an agent avoid a common API misuse. It does not mention button-specific behavior or effect of `double`, but those are more parameter-level semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The main action is front-loaded, and the window/coordinate caveat is placed exactly where it adds value. No redundant restatement of tool name or basic click meaning.
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?
With an output schema present, return values need no explanation. The description covers the core invocation logic: whether to provide coordinates or click at current position, and how `window` affects them. It does not document button or double behavior, but their defaults and names are obvious enough for safe basic invocation.
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 coverage is 0%, so the description must compensate. It gives meaning to `x`/`y` as optional (clicks at current position when omitted) and clarifies `window` behavior with a note on absolute coordinates. However, it adds nothing about `button` choices or the `double` boolean beyond their defaults, leaving full compensation incomplete.
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 states the specific action ('Click') and the object (coordinates or current cursor position), which clearly distinguishes it from siblings like `click_text` (clicks on text) and `mouse_move`/`mouse_scroll` (no click). The nuance about `window` and absolute coordinates further scopes the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to click at specific screen coordinates or at the current cursor position) but provides no explicit 'when not to use' or alternatives such as `click_text` for text-based click. It lacks clear guidance among the 27 sibling automation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that the app is launched detached, bypasses the shell, and waits for the window. It could mention error behavior on timeout or missing binary, but the essential side effects are covered.
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?
Three short sentences, each carrying distinct information. The main behavior is front-loaded)Skip no filler. Formatting is scannable and efficient.
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?
For a simple two-parameter tool with no nested objects and an output schema present, the description covers the essential invocation semantics alert(clarification). Minor gaps: no explicit timeout units or failure-mode note, but these are inferable from the timeout guidance.
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 has no field descriptions, so the description must compensate. It explains that command is passed directly (binary + args only) and frames timeout as a tunable for fast vs slow apps. This adds meaningful semantic context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: launching an app detached from the shell, with binary plus arguments only. It also states that it waits for the app's window, which is precise and distinct from the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical guidance on adjusting the timeout for slow vs fast apps, using Steam as a concrete example. It does not explicitly state when not to use it, but there is no directly competing sibling tool, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'List' conveys a non-mutating read, and it additionally reveals that output includes window counts and an [focused] marker on the active workspace. For a simple query tool this is sufficient; no side effects, auth, or rate-limit caveats are expected.
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 short sentences, no filler, with the main action first and the active-workspace behavior second. Every word adds information.
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?
For a parameterless listing tool with an output schema, the description is complete: it identifies the resource, the extra field (window counts), and the special marking for the active workspace. Return format is already covered by the output schema.
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 takes zero parameters, so there is nothing for the description to explain. The baseline of 4 applies because parameter semantics are a non-issue.
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 uses a specific verb ('List') and resource ('workspaces') and adds two distinguishing details: window counts and the [focused] marker. It is immediately clear what this tool does and how it differs from sibling list tools such as list_windows or list_monitors.
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 read-only listing purpose is clear, and the [focused] marker signals that this tool is useful for identifying the active workspace. It does not explicitly name alternatives like switch_workspace or state when not to use it, but the context alone is 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: