Universal Computer Control MCP
Server Quality Checklist
Latest release: v0.1.1
- Disambiguation4/5
Most tools target a single, distinct action or resource, and the shared target resolution rules do not create real confusion. The main overlap is that observe subsumes screenshot and get_ui_tree, while find_text and find_visual both locate on-screen targets, but their text-vs-visual distinction keeps them usable.
Naming Consistency4/5The majority of tool names follow a clear action_object snake_case pattern, such as focus_window, get_clipboard, and list_windows. A few outliers like observe, screenshot, backend_status, and emergency_stop break the verb_noun pattern but remain readable and stylistically consistent.
Tool Count2/5At 29 tools, the namespace is too large for a single agent-facing surface; the selection cost is significant even though the tools cluster into clear functional groups. Some observation tools such as screenshot, observe, and get_ui_tree could be consolidated, which would reduce count without losing capability.
Completeness5/5The set covers the full GUI automation loop: observing state, searching for targets, input, window lifecycle, clipboard, launching applications, shell commands, and safety controls. There are no obvious dead ends, and wait_for plus backend_status close the verification and error-handling gaps.
Average 3.7/5 across 29 of 29 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action and defers target rules to computer.click; it does not disclose side effects, whether verification is supported, or any potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Referencing computer.click avoids repeating a long list of target rules, keeping it appropriately concise.
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 no annotations, no output schema, and an undocumented verify parameter, the description leaves critical context undeclared. An agent would need to inspect sibling tool descriptions or schemas to understand target rules and verification 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%, so the description must compensate. It adds some meaning by pointing out target rules match computer.click, but it does not explain the target format or the purpose of the verify 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 action ('Right-click') and the resource ('a UI element'), so an agent can tell the tool performs a right-click action. It references computer.click for target rules, which is useful for understanding intent, but it relies on a sibling tool for detail rather than fully defining its own scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use right-click versus click, double-click, or other input tools. It does not mention common use cases like opening a context menu or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure. It only names the action and input types; it does not explain whether the drag presses and releases a mouse button, whether coordinates are absolute or relative, or what side effects occur.
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 focused sentence with no filler or redundant wording. The core action and target types are front-loaded, making it easy to parse quickly.
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 physical computer-action tool with no annotations and no output schema, and the description is too minimal to support confident invocation. It omits the drag behavior details, duration semantics, coordinate format, and any notion of return value or success feedback.
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 phrase 'text, element ids or coordinates' adds meaning to start and end by mapping them to the schema's string/object union. However, the optional duration_s parameter is completely undocumented in the description, leaving its semantics to be inferred from its name.
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 ('Drag from one target to another') and enumerates the accepted target types ('text, element ids or coordinates'), making it clearly distinct from sibling tools like click or move_mouse. It is concise and unambiguous about what the tool does, though it does not explicitly contrast it with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 any mention of exclusions or prerequisites. The tool name and sibling list imply it is for drag-and-drop, but the description does not help an agent decide between this and similar pointer actions.
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 indicates the action (maximize) but does not disclose side effects (e.g., whether the window is brought to front), failure behavior if the window is not found, or whether the tool is idempotent. This is a notable gap for a state-changing tool.
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 efficient sentence with no filler, front-loading the action and the key parameter semantics. It is concise, though it sacrifices behavioral detail.
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 is adequate: it names the action and how to identify the target window. However, with no annotations and no output schema, the agent is left without information on success/failure signals, error conditions, or any return value, making it minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'by title/application' gives partial meaning to the `window` parameter beyond 'string,' but it is ambiguous whether it matches partial strings, is case-sensitive, or which format is preferred. Some value is added, but not enough for full clarity.
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 ('Maximize') and resource ('a window'), and adds the identification mechanism 'by title/application,' making the tool's purpose clear. It implicitly distinguishes from sibling tools like get_active_window or click, though it does not 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 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, no exclusions, and no mention of preconditions such as the window existing or being on screen. The agent must infer usage from the single sentence.
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 the action and target, but does not disclose what happens if the window is already minimized, if no matching window is found, whether exact title matching is required, or whether minimizing by application affects all windows of that app. These are important behaviors for the agent to predict the outcome.
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 one short sentence with no redundant words, and the core action is front-loaded. It is appropriately concise for a simple tool, though it could have used the extra space to add behavioral details without becoming verbose.
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 one required parameter, no output schema, and no annotations, so the description is the only source of guidance. While the operation is simple, the description omits critical matching and failure behavior and provides no context about how it relates to sibling window-management tools. A few more details would make it complete enough for reliable 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?
The input schema provides only a parameter name 'window' with no description, and schema description coverage is 0%. The description adds some meaning by clarifying that the parameter can be a title or application, but it does not specify matching semantics, casing sensitivity, or how to disambiguate multiple matches. It partially compensates for the schema gap but not fully.
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 ('Minimize') and resource ('a window'), with a qualifier ('by title/application') that distinguishes it from related window actions like maximize, restore, and close. However, it does not explicitly differentiate itself from sibling tools, and 'application' is slightly ambiguous as to whether it means an app name or all windows of an app.
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 alternatives like focus_window, restore_window, or close_window. The context of wanting to minimize is implied but no explicit conditions, prerequisites, or exclusions are provided.
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. It adds nothing beyond the tool name about behavior: no mention of key down/up behavior, modifier support, what happens on invalid keys, or whether the target window needs focus. Minimal disclosure for a tool that sends input events.
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?
A single clear sentence with useful examples and zero filler. The key action is front-loaded. Slightly more detail could be added, but it remains appropriately concise for a simple tool.
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 single-parameter tool with no output schema, the description is close to sufficient, but it leaves behavioral questions open (e.g., modifier combinations, error behavior, focus requirements). Given the low complexity, the gaps are notable but not severe.
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 adds valid key examples ('enter', 'tab', 'escape', 'f5') that give meaning to the 'key' parameter. However, it doesn't specify formatting rules, case sensitivity, or whether arbitrary key names are accepted. Partial compensation only.
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?
States a specific verb ('Press') and resource ('keyboard key') with concrete examples ('enter', 'tab', 'escape', 'f5'). Clear what the tool does, though it does not explicitly differentiate itself from a potential keyboard 'type' sibling.
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. There are no conditions, exclusions, or mentions of prerequisites (e.g., window focus). The context is implicit from 'keyboard key' but never made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does state the core behavior: restoring a minimized or maximized window. However, it does not disclose what happens if the window is already in a normal state, whether focus changes, or how invalid window references are handled, so transparency is only partial.
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 compact sentence with no wasted words and the core action is front-loaded. It earns a high conciseness score, though not a perfect one because a short clarifying clause about expected state could have been added without harming readability.
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 simple one-parameter tool with no output schema, the description is close to minimal, but it is not complete enough: the parameter semantics are entirely absent and there is no annotation safety or usage context. An agent would know the intent but not enough details to invoke it reliably.
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 adds no meaning to the required 'window' parameter. It does not explain what identifier or format is expected (title, ID, handle, etc.), leaving the agent guessing how to populate the 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 identifies the operation ('restore') and the resource ('window'), and it is naturally set apart from sibling tools like minimize_window and maximize_window by naming the opposite action. It loses a point because 'restore' is not fully disambiguated: it covers both minimized and maximized windows without specifying the resulting state.
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 the usage condition: call it when a window is minimized or maximized and needs to be restored. It does not explicitly mention alternatives or exclusion cases (e.g., when to use focus_window instead), so guidance remains implicit rather than explicit.
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, but it only states the action and target rules. It does not explain side effects, whether the mouse moves, what happens on failure, or any post-conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core action immediately and adds a useful pointer to sibling behavior without unnecessary 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 no annotations, no output schema, and 0% parameter description coverage, this description is too thin. The verify parameter is undocumented, and the behavior on double-clicking non-interactive elements or invalid targets is absent, so the agent may misinvoke the 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?
Schema description coverage is 0%. The phrase 'same flexible target rules as computer.click' gives some meaning for the target parameter by pointing to another tool, but the verify parameter is completely unexplained, and the target's actual format/behavior is not defined here.
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 action: 'Double-click a UI element', which is a specific verb and resource. It distinguishes itself from sibling tools like click and right_click through the 'double' qualifier, and references computer.click for target rules, reinforcing its role.
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 double_click versus click or other pointer tools. It only references target rules from computer.click, which is about parameter semantics, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explains cross-platform backend behavior (Windows UI Automation or Linux AT-SPI) and promises an explanatory error when no accessibility backend is available, which is useful and non-obvious.
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 compact: two sentences, front-loaded with the core behavior, followed by platform and error details. Every sentence adds meaningful information with no filler.
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 covers the main output shape and backend error behavior, but lacks explanation of the max_depth parameter and does not specify what happens for invalid windows or unsupported platforms beyond the backend error. It is adequate for simple use but leaves meaningful gaps.
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 partially explains the 'window' parameter via 'active (or a named) window', but it does not clarify 'max_depth', its meaning, limits, or how values affect the returned tree.
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 gets the accessibility tree of the active or named window, and specifies the output as a nested structure of roles, names, and bounding boxes. It is specific about the resource and result, though it does not explicitly differentiate itself from sibling tools like observe or find_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?
The description implies the tool is for retrieving an accessibility tree, but gives no guidance on when to choose it over alternatives such as screenshot, observe, or find_text. No when-not-to-use conditions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly states that it moves the mouse cursor, which is the core behavior. It adds some value by enumerating target types, but it does not disclose whether this only hovers, what happens with invalid targets, or whether any side effects such as hover-triggered UI changes occur. With no annotations, the description carries the full burden, and it only partially covers this.
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 or redundant information. It front-loads the action and then immediately clarifies the three accepted target forms. This is an appropriate level of brevity for a simple tool.
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 there are no annotations and no output schema, the description alone must provide enough context for correct invocation. It specifies the three target types but fails to explain how coordinates should be structured, whether text is exact or fuzzy, or what the tool returns or does after moving. An agent might struggle to construct a valid 'target' object for coordinates.
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 provides no descriptions for the 'target' parameter and only says it is a string or an object with additional properties. The description significantly compensates by explaining that target can be text, element id, or coordinates. However, it does not specify the exact structure for coordinates or how element IDs are represented, so some ambiguity remains.
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 and resource: 'Move the mouse cursor to a target.' The target types (text, element id, coordinates) add useful specificity. However, it does not explicitly differentiate this tool from siblings like click, double_click, or drag, which also relate to cursor positioning and interaction.
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 use this tool versus alternatives. The description does not say 'use before click' or 'for interacting with elements use click instead.' The intended context is implied but not stated, leaving the agent without explicit routing information.
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 present, so the description carries the full burden. It explains positive/negative amount direction and coordinate options, but does not disclose behavior when coordinates are omitted (presumably current cursor position), whether scrolling at coordinates moves the pointer, or any return value. Core behavior is covered, but operational 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the core action and includes the most important semantic details without redundancy. Every clause 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 input tool with no output schema, the description covers action, direction, and coordinates. However, it leaves null-coordinate behavior and coordinate-frame assumptions implicit. With zero annotations, these gaps are meaningful but not critical for a basic scroll operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that positive amount scrolls up, negative down, and that x/y are optional coordinates. The schema only provides types and defaults. It does not define the unit of amount or the coordinate system, but the added semantics justify above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Scroll the mouse wheel,' and clarifies direction semantics and optional coordinates. This distinguishes it from sibling mouse tools like click or move_mouse, though it does not explicitly name them.
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?
Usage is implied: an agent would use this when a scroll action is needed. However, there is no explicit guidance on when not to use it or which alternative tools to prefer, such as drag or keyboard-based scrolling. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the core mechanism (template matching or optional vision model) and the return type (bounding box), which is helpful for a read-only lookup. However, it does not mention failure behavior, timeouts, coordinate conventions, or what happens when neither template nor description resolves a match.
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 filler. It front-loads the core purpose, then gives the two matching modes, and ends with the return value. Every clause 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 tool with no annotations and no output schema, the description gives the essential purpose and return shape, but leaves gaps an agent would need for reliable invocation: threshold semantics, whether at least one of template/description is effectively required, and failure/coordinate details. It is adequate for a simple read-only lookup but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for 'template' (image template name, configured template directory) and 'description' (natural-language via optional vision model). However, 'threshold' is left completely unexplained, and the interaction between the three parameters is not clarified.
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 and resource: 'Find a UI element visually.' It also distinguishes itself from sibling tools by naming the two matching modes (template name or natural-language description) and the return value (a bounding box). This clearly separates it from text-based alternatives like find_text.
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 locate a UI element by visual appearance rather than by text or tree structure. However, it does not explicitly contrast it with sibling tools such as find_text, get_ui_tree, or observe, nor does it state when not to use it. Usage is inferable but not 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 carries the burden of behavioral disclosure. It does add value by stating partial matching and OS-level operation without app-specific integration. However, it omits edge-case behavior such as multiple matches, no match found, or whether a minimized window is restored.
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 filler. The essential mechanism is front-loaded, and the integration note is a single useful clause.
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 is mostly adequate, but without an output schema or annotations, it should at least note failure behavior or ambiguity handling. It does not state what happens if the window is not found or multiple windows match.
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 coverage is 0%, but the description compensates well for the single 'window' parameter by defining it as a partial title or application name with a concrete example. This gives the agent the necessary format and matching semantics.
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 ('focus') and resource ('real OS window') and clarifies it matches by partial title or application name. This clearly distinguishes it from sibling window-management tools like minimize_window, maximize_window, and close_window.
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 explains what the tool does but gives no guidance on when to use it versus alternatives. It does not mention that list_windows can provide window identifiers, that this should precede click/type actions, or that it is not needed for the active window.
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 discloses the core behavior (read operation) but does not specify whether the tool has any side effects, performance implications, or failure modes (e.g., if no window is focused, or on different OSes). For a read-only tool, this is a notable 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 conveys the essential information in under 90 characters. It front-loads the action ('Get') and lists the exact output fields (title, application, process). There is no fluff or repetition.
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 tool with zero parameters and no output schema, the description covers the basic return values (title, application, process) adequately. However, it could be more complete by indicating the format of the output (e.g., a structured object or JSON) and any potential edge cases, but it is largely sufficient for a simple read-only 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?
The input schema is empty (no parameters), so there is no schema information to clarify. The description correctly implies no parameters are needed, which is unambiguous. The baseline for 0 params is 4 because the description is sufficient to understand the tool's inputs—there are none.
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 is precise: it specifies the verb 'Get' and the resource 'title, application and process of the currently focused window'—exactly what the tool does. It distinguishes itself from sibling tools like screenshot or get_ui_tree, which return visual or hierarchical data, not process metadata.
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 the tool is used to inspect the active window, but does not explicitly state when to use it versus alternatives. For example, it doesn't mention that get_ui_tree would be used to inspect deeper structural details, or that observe might be used for raw screenshots. However, given the tool's simplicity, the implied usage is fairly clear.
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 the behavioral burden. It states the core action—simulating a key combination press—and the examples clarify the expected input. It does not discuss key release, focus requirements, or error behavior, but for a simple input-injection tool the described behavior is largely transparent.
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 sentences with no filler; the purpose is front-loaded and concrete examples immediately follow. Every sentence in the description earns its place.
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 single-parameter tool with no output schema, the description covers the purpose and the parameter format, which is sufficient for invoking it. The only meaningful gap is the lack of guidance for choosing between this and the similar computer.press 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?
The input schema only says the keys parameter can be a string or an array of strings, so the description adds real value by showing 'ctrl+s' as a string and ['ctrl', 'shift', 't'] as a list. It compensates for the 0% schema description coverage, though it could list more valid key 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 opens with the specific action 'Press a key combination' and immediately shows the accepted input formats, making the resource and intent clear. It doesn't explicitly distinguish this from the sibling computer.press, which may also be used for key input, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'key combination' implies this tool is for multi-key shortcuts, and the examples reinforce that. However, there is no explicit when-to-use guidance, no mention of when to prefer computer.press or other siblings, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly indicates a non-destructive listing operation, but it does not disclose edge cases such as whether all window states are included, whether minimized windows are listed, or what 'top-level' excludes. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that front-loads the action and resource, then lists the returned fields. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description adequately conveys what an agent gets back. The absence of output schema means the description's field list is the main contract; it is sufficient, though it could mention sorting or window visibility caveats.
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 and the schema coverage is 100%, so nothing is missing from the input side. The description adds meaning by clarifying that the result includes title, application, pid, and state, which is valuable beyond the empty 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 ('List') and resource ('all top-level OS windows') and specifies return fields (title, application, pid, state). It clearly distinguishes the tool from siblings like get_active_window and focus_window, although it does not explicitly name them.
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 context implies this is a read-only enumeration tool for top-level windows, useful before actions like focus, close, or observe. However, it does not explicitly state when to prefer this over computer.get_ui_tree or computer.find_text, nor any exclusions or caveats.
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 carries the burden of revealing behavior. It clearly identifies that the operation writes to the clipboard, but it does not explicitly mention that existing clipboard contents are replaced, nor does it discuss errors or return behavior. This is adequate for a simple setter but not richly transparent.
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 short sentence front-loads the action and appends a useful parenthetical use case. Every word earns its place; no redundancy or filler.
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 one-parameter setter, the core purpose and use case are present, but the absence of annotations and an output schema leaves overwrite behavior and success/failure semantics unstated. The description is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description helps by indicating that the sole parameter 'text' is the content to be written. However, it adds no format, length, or encoding details; the single self-explanatory parameter keeps this from being a serious weakness.
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 ('Write') and resource ('clipboard') to state exactly what the tool does, and the parenthetical 'useful as a typing fallback' adds a helpful intended-use cue. It distinguishes the tool from get_clipboard and typing-oriented siblings, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'typing fallback' phrase gives a clear context for when to reach for this tool: when direct keyboard typing is not practical. It does not name sibling tools or state when not to use it, so it stops short of a full routing guide.
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 must carry the full behavioral burden. It explains that the tool blocks until a screen change occurs and defines the expectation semantics. However, it does not disclose timeout behavior, what happens when no change occurs, or whether the tool returns any result, leaving some uncertainty for the agent.
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 filler. It front-loads the core behavior, then gives compact parameter semantics, then gives usage context. Every sentence contributes uniquely useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple waiting tool, the description covers the main expectation types and typical usage. However, there is no output schema and no mention of return values or timeout failure behavior, which an agent would reasonably need to know when deciding whether the tool succeeded. The missing timeout semantics are the main gap.
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 adds meaningful semantics for 'expectation' and 'value', explaining the window-title and OCR-text matching behavior. It does not explain 'timeout_s', leaving the agent to infer its meaning from the name and 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 identifies the action ('Wait until something changes on screen') and the resource being acted on. It also lists the three expectation types, making the tool's scope concrete. It doesn't explicitly distinguish this from sibling observation tools like computer.observe or computer.get_ui_tree, but 'wait' conveys a blocking operation, which separates it enough.
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 usage context: 'Use after actions to await UI reactions instead of blind sleeps.' This tells the agent when the tool is appropriate and what it should replace. It stops short of naming sibling alternatives or stating when not to use it, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately states the read-only nature, but gives no additional context such as behavior with an empty clipboard, system permissions, or return value details. The basic operation is clear, yet the description adds minimal behavioral transparency beyond the literal action.
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 only four words, every one earning its place. It is front-loaded with the action and target, contains no filler, and is significantly concise without losing clarity.
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 trivial parameterless read operation with no output schema, the description fully covers what an agent needs to know to invoke it correctly. There are no hidden requirements, side effects, or conditions that need clarification.
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 input schema is complete and no parameter documentation is needed. Baseline for 0-param tools is 4, and the description does not need to compensate for any schema gaps.
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 verb ('Read') and a clear resource ('the clipboard text'). It precisely distinguishes the tool from siblings like set_clipboard, which writes to the clipboard, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of context, prerequisites, or related operations such as set_clipboard. The agent must infer usage entirely from the name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, non-destructive operation. The description adds useful behavioral context beyond annotations: the screenshot is saved to a persistence directory and the path is returned, which is valuable for an agent deciding how to use the result.
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. It front-loads the main action and capture modes, then states the persistence and return behavior without any wasted words.
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 screenshot tool with read-only annotations, this covers the primary workflow well. However, since there is no output schema and schema description coverage is 0%, the omission of return_image behavior and any note about parameter exclusivity or coordinate conventions leaves noticeable 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 for missing parameter details. It does explain the region format ([left, top, right, bottom]) and the monitor option, but it does not explain the return_image parameter, whose behavior is left to inference from its name and default value.
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 a specific verb and resource: 'Take a screenshot' of the virtual desktop, a monitor, or a region. It also enumerates capture modes, making it easy to distinguish from sibling tools like get_ui_tree or observe.
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 the tool—whenever a screenshot of the desktop, monitor, or region is needed—but it does not explicitly name alternatives or state when not to use it. No exclusions or routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the use of OCR + accessibility, fuzzy matching tolerance (case, arrows, small typos), and that matches come with bounding boxes. This gives the agent a solid model of the tool's behavior, though it does not mention failure modes or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. The core action is front-loaded, followed by the output format and matching tolerance. Every sentence 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?
The description covers the main behavior and output format, but for a tool with no output schema and no annotations, it leaves the meaning of limit and threshold underspecified. An agent could still use sensible defaults, but the missing parameter guidance creates a gap.
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 only indirectly addresses the threshold parameter through the fuzzy matching example, and it does not explain the 'limit' parameter at all. Query is implied as the text to find, but threshold/limit semantics are left to inference.
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 verb ('Find'), a clear resource ('text anywhere on screen'), and the method (OCR + accessibility). It also mentions fuzzy matching and bounding boxes, which distinguishes it from sibling tools like find_visual and get_ui_tree without needing to open the schema.
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 context is clear: use this tool when you need to locate text on screen and get clickable coordinates. It implies the text-focused alternative to visual/UI-tree tools, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does well by disclosing Unicode/multiline support, automatic clipboard fallback, and that typed content is never logged. These are non-obvious behavioral details not inferable from the schema, though the behavior of the verify parameter and failure modes remain unexplained.
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 sentences with no wasted words: the core action is front-loaded, and the supporting behavioral facts are packed efficiently. Every sentence earns its place without repeating schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core typing semantics well, but it omits the verify parameter and does not state what happens when no input is focused or whether the tool will attempt to focus one itself. Given the sibling context (click, focus_window), an agent can infer prerequisites, but the description alone is not fully self-sufficient.
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 needed to compensate and clarify both parameters. It adds useful meaning for 'text' by describing Unicode/multiline support and no-logging, but it says nothing about the 'verify' parameter, leaving its meaning and effect completely opaque to the agent.
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 action ('Type text') and the target ('at the currently focused input'), and emphasizes Unicode/multiline handling, which distinguishes it from sibling key-press tools like computer.press and computer.hotkey. This is a specific, non-tautological definition that an agent can understand immediately.
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 phrase 'currently focused input' establishes the precondition that an input must already be focused, and the Unicode/multiline support signals when this tool is preferable for text entry. It does not explicitly name alternatives or exclusion cases, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It clearly communicates the tool's scope: reporting health/availability of named backends, security settings, and emergency-stop state. The wording 'Report' strongly implies a read-only diagnostic operation, though it does not specify the output format or whether any side effects occur.
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 core purpose ('Report health/availability') and then efficiently enumerates the specific categories covered. Every part adds useful information; there is no filler.
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 status tool with no output schema, the description provides a strong overview of what is reported: backend health/availability, security settings, and emergency-stop state. It could be more complete by specifying the output shape or possible status values, but given the tool's simplicity, the coverage is adequate.
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 and an empty input schema, so there are no parameter semantics to clarify. The baseline for a parameterless tool is 4, and the description appropriately focuses on what the report contains rather than parameter handling.
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 names a specific verb ('Report') and resource ('health/availability of every backend') and enumerates the backend types plus security settings and emergency-stop state. This clearly distinguishes it from the sibling action-oriented tools like computer.click or computer.type, which perform operations rather than report status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a diagnostic use case: checking backend health/availability, security settings, and emergency-stop state. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any alternative tools, though none of the siblings appear to be direct substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the resolution pipeline (accessibility → OCR → vision) and states that it verifies the result, providing substantive behavioral context beyond a bare 'clicks an element.' With no annotations present, this disclosure carries the full transparency burden; it doesn't cover failure handling, but the core behavior is clearly revealed.
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 the core action front-loaded, followed by target formats and resolution/verification behavior. Every sentence contributes useful information without repetition or filler.
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 click action, the description covers the essential invocation details: what target forms are accepted and how the engine resolves them. It also mentions verification, giving the agent a sense of outcome handling. Minor omissions like failure behavior and exact return value are acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the parameter meaning. It explains the required target parameter in detail, including visible text, element id from computer.observe, and coordinate-object format. Optional button and verify parameters are not elaborated, but their names and defaults are reasonably self-explanatory.
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 opens with the specific action 'Click a UI element,' naming both the verb and the resource. It clearly distinguishes this from siblings like double_click and right_click by the generic click action and default left button.
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 explains the target formats that can be used (visible text, element id, coordinates), giving practical context for when this tool applies. However, it offers no explicit guidance on when to prefer click over siblings such as right_click or double_click, nor any exclusion criteria.
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 disclosure burden. It reveals that the close is graceful (WM_CLOSE), that confirm must be set to true, and that modal dialogs stay visible for the agent to handle. It does not discuss potential failure modes or return values, but these are minor for this 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 one tight sentence that front-loads the action and then adds two pieces of high-value behavioral/parameter information. No word is wasted.
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, the description covers the action, the required parameter, and an important behavioral side effect. It is complete enough for an agent to invoke it correctly, though it does not specify how to obtain the 'window' identifier in context.
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 adds meaning for 'confirm' by stating it is required and explaining the modal-dialog consequence, but it does not define what 'window' expects (ID, title, handle, etc.), leaving a gap for one of the two 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 uses a specific verb ('Close'), a clear resource ('window'), and the mechanism 'gracefully (WM_CLOSE)', which distinguishes it from a forced termination. This is unique among the siblings, all of which operate at the level of observation, UI interaction, or window management without closing.
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?
It plainly says this tool is for gracefully closing a window and gives the key prerequisite 'Requires confirm=true'. It also tells the agent what to expect afterward (modal confirmation dialogs remain visible), which is actionable context, though it does not explicitly contrast with sibling alternatives such as minimize or focus.
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 must carry behavioral disclosure. It usefully states that launching is 'Subject to security.allowed_applications', which informs the agent of a likely permission gate. However, it does not describe failure behavior (e.g., error on disallowed application, whether it waits for the app to open) or return/acknowledgment 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?
A single, well-structured sentence front-loads the action and resource, gives concrete examples, and ends with the security constraint. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool with no annotations, the description covers the core invocation: what it launches and what inputs are valid. It could mention what happens when security.allowed_applications blocks the request, but the overall definition is sufficient for correct selection and most likely invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it does by enumerating accepted command forms ('chrome', 'code', a .desktop entry, or a full path'). For a single required parameter, this meaningfully clarifies what 'command' accepts, though it stops short of explaining .desktop entry syntax or path resolution.
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 names a specific verb ('Launch'), a resource type ('GUI application'), and concrete valid inputs ('chrome', 'code', a .desktop entry, or a full path'). This clearly distinguishes it from the sibling interaction/observation tools such as computer.click or computer.get_ui_tree.
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 clarifies when to use this tool: to launch GUI applications, and the accepted command forms are listed. It doesn't explicitly exclude non-GUI commands or name an alternative like a terminal-run tool, but none of the siblings handle launching, so the context is adequately clear.
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 explaining behavior. It clearly states that the tool clears a previously triggered emergency stop state, but it does not mention any side effects, such as whether normal computer interaction is restored immediately or what happens if no emergency stop is active.
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 filler. It front-loads the action and object, and every word contributes meaningful context.
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 utility tool with no output schema, the description covers the essential operation: clearing a previously triggered emergency stop. It could add a bit more context about the effect of resetting the stop, but the tool is simple enough that nothing critical is missing.
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 no parameters and schema description coverage is 100%, so there are no parameter semantics to document. The description appropriately adds nothing about parameters, and the zero-parameter baseline of 4 applies.
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 ('Clear') with a specific resource ('a previously triggered emergency stop'), making the action and scope immediately obvious. It also distinguishes this tool from the sibling 'emergency_stop' by describing the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously triggered' gives clear contextual guidance: this tool should be used when an emergency stop is already active. It does not explicitly name alternatives or exclusion cases, but for a zero-parameter reset paired with an obvious sibling, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses output truncation, credential redaction, and allowlist enforcement, which are important behavioral traits beyond what the schema shows. It does not explicitly state destructiveness or side effects, but 'run a shell command' plus confirm=true implies mutating capability.
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 dense sentence that front-loads the action and packs constraints efficiently. Every clause contributes new information, with no filler or repetition.
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 3-parameter tool with no annotations and no output schema, the description covers the critical invocation constraints: allowlist dependency, the need for confirm=true, and output behavior. It omits timeout semantics and error/exit-code format, but those are secondary for selecting and calling the tool correctly.
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 adds meaningful semantics for confirm ('requires confirm=true') and clarifies command scope via the allowlist, but it never mentions timeout_s or how it behaves. The schema provides type/default, leaving timeout semantics still ambiguous.
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 verb and resource: 'Run a shell command.' No sibling tool duplicates this capability, and the added context about the allowlist and confirmation requirement further clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage conditions: the security allowlist applies, output is truncated and credential-redacted, and confirm=true is required. It points to computer.backend_status for allowlist details, though it does not explicitly name alternative tools or when not to use this one.
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 fully carries the burden of behavioral disclosure. It transparently describes what the tool returns, including the available levels and their composition ('normal' = screenshot+OCR+accessibility, 'full' adds focused element details). It does not mention potential side effects, but the read-only nature of observing is evident from the verb and examples.
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 concise, information-dense sentences: the first states the tool's scope, the second defines the parameter levels, and the third frames its role relative to other actions. No wasted words; all content serves the agent's decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does a solid job covering what the tool does, the parameter options, and when to use it. It does not describe the return format or potential limitations (e.g., accessibility API failing), but for an observe tool the listed components give sufficient context for an agent to invoke it and understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'level', has no schema description and no enums, yet the description fully documents the three valid values and what each returns: 'minimal' (fast), 'normal' (screenshot+OCR+accessibility), and 'full' (adds focused element details). This completely compensates for the 0% schema coverage.
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 ('Observe') with a clear resource ('current computer state') and enumerates exactly what is included: screen geometry, active window, cursor, OCR'd text, and accessibility elements. It also distinguishes itself from sibling tools by explicitly calling itself the 'primary tool for understanding the screen before acting,' which sets it apart from specific helpers like screenshot or get_active_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable usage guidance by stating this is the primary tool to use before acting on the screen. It does not explicitly list when to prefer alternatives like computer.screenshot or computer.get_ui_tree, but it implies a general-purpose role that precedes-specific actions. The 'fast' minimal level also suggests a use case when speed is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It states that the effect is immediate, global across automation, checked before every action, and persistent until reset_emergency_stop. This gives the agent a clear model of the tool's side effects and lifecycle.
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 short sentences with no filler. The critical 'EMERGENCY STOP' and 'immediately halt' concepts are front-loaded, and the persistence condition is stated in the second sentence. Every word earns its place.
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 zero-parameter tool with no output schema, this description is structurally complete. It covers what the tool does, when its effect applies, how long it persists, and how to undo it. Nothing needed for correct invocation is missing.
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, and the schema shows an empty properties object. Per the rubric, the baseline for zero-parameter tools is 4, and the description appropriately does not invent parameter details. There is nothing more needed here.
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 phrase—'immediately halt all automation'—making the tool's purpose unmistakable. It also names the exact reset counterpart, reset_emergency_stop, which distinguishes it from all sibling tools. No ambiguity remains about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is a global kill switch that is 'checked before every action and attempt,' so the agent can infer when to use it: whenever automation must be stopped immediately. It also states persistence until reset, implying the normal follow-up is reset_emergency_stop. It does not explicitly discuss when not to use it, but the emergency framing makes that less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/adkdev200/Universal-Computer-Control'
If you have feedback or need assistance with the MCP directory API, please join our Discord server