open-zcode-computer-use

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct action or resource category: display/window/app listing, mouse variants, keyboard input, accessibility operations, clipboard access, and control flow. The closest pairs like key vs hold_key and type vs set_value are clearly differentiated by duration and input mechanism.
Naming Consistency4/5
Most names follow a predictable lower_snake_case verb_noun pattern such as list_windows, open_application, set_value, and read_clipboard. A few outliers like key, screenshot, and cursor_position break the pattern slightly but remain recognizable and consistent in style.
Tool Count2/5
With 30 tools, the server feels over-scoped for a single computer-use entry point. Many click variants and keyboard/pointer hold primitives could be parameterized or consolidated without losing capability, though the broad domain justifies some of the count.
Completeness4/5
The surface covers the main computer-use workflows: display selection, screenshots, app/window introspection, mouse and keyboard input, accessibility actions, and clipboard management. Notable minor gaps include no app termination or active window management, but agents can work around these via existing accessibility actions.
Average 3.4/5 across 30 of 30 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is destructive and not read-only, so the safety profile is known. The description adds no behavioral context beyond the operation itself — it does not mention side effects, how targets are resolved, what gets modified, or how the drag is executed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, which is structurally efficient. However, it is so terse that it omits meaningful detail, and the phrase 'bound target' is unexplained, limiting the value of the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, polymorphic target types, and a destructive annotation, this description is insufficient for an agent to reliably select and invoke it. It does not explain how to construct targets, how modifiers are specified, or whether state should be returned after the drag. These gaps are significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate by explaining endpoint semantics. It only conveys that from_target and to are the two ends of a drag; it does not clarify element vs coordinate usage, modifiers, app_ref, or return_state. The nested schema does most of the explanatory work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the operation ('drag') and broadly distinguishes it from simple click and hover tools, but 'bound target' is undefined jargon and the description does not clarify that targets may be elements or coordinates. It conveys the general action, but not with the precision expected for a drag tool with polymorphic endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over left_mouse_down/left_mouse_up, mouse_move, or left_click. The word 'drag' implies the use case, but no explicit when/when-not guidance or alternatives 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 already indicate destructiveHint=true and readOnlyHint=false, and the description adds no behavioral context beyond the fact that scrolling happens. It does not disclose that scroll input may trigger events, change visible content, or be affected by strategy/app_ref, and it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no padding and the verb is front-loaded. It loses some clarity due to the cryptic 'bound' adjective, but otherwise it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no output schema, and destructive annotations, this description is too thin. It omits important practical context such as what a scroll amount means, how coordinates relate to frames, and what happens after the action, leaving the agent to infer behavior from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents most parameters, but the description adds almost no semantic value beyond restating the target kind. It does not clarify 'bound element', 'page-like scroll amount', how app_ref is resolved, or the effects of strategy/return_state, so it only partially compensates for the 67% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Scroll') and a resource ('a bound element or frame coordinate'), which aligns with the target union of element or coordinate. It is distinguishable from siblings like click or drag, though the word 'bound' is ambiguous and adds some confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as left_click_drag, key, or mouse_move. There are no exclusions, prerequisites, or conditions stated; usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers only the vague qualifier 'scoped' beyond the annotations; it does not explain what the scope is, whether the pointer moves to the target first, or that this should be paired with left_mouse_up. DestructiveHint already signals mutation, but the description adds little concrete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb 'Begin'. Its brevity is a trade-off against clarity, but as a concise statement of the core action it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a required target that can be an element or coordinate, an optional app_ref, and a return_state option, the single sentence omits how the target is used, when to call the companion left_mouse_up, and what 'scoped' means operationally. The lack of an output schema increases the burden, yet the description does not address it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with target and app_ref lacking top-level descriptions. The description does not explain target, its element/coordinate forms, or app_ref, so an agent must rely on nested schema properties. The word 'scoped' provides at best an indirect hint that the target bounds the hold.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Begin') and resource ('left-button hold'), and the word 'scoped' hints that the hold is bounded, distinguishing it from one-shot clicks like left_click and releases like left_mouse_up. It does not explicitly mention the required target parameter or the pairing requirement, so it is not maximally explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as left_click, left_click_drag, or left_mouse_up. The description does not mention the expected pairing with left_mouse_up or any conditions that would make a hold preferable to a click or drag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive/read-write behavior, so there is no contradiction, but the description adds no extra behavioral context. It does not explain how 'bound' targets are resolved, what happens on failure, or what side effects a triple-click may trigger. The agent learns nothing beyond the fact that a triple click will be performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At one short sentence, the description is compact and front-loads the action and target type. There is no filler or repeated enumeration. The brevity is appropriate for the dimension, even if other dimensions lack information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema exposing parameter metadata, the description alone is not enough to select this tool confidently among several click variants. Missing usage context, target-binding semantics, and behavioral side effects mean an agent cannot fully judge when to invoke it. The schema/annotation richness does not compensate for this absence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes no parameter semantics; it only restates the target concept already represented in the schema. The schema itself covers 60% of parameters, and the description does not compensate for the undocumented 'app_ref' or otherwise clarify parameter relationships. The baseline of 3 only applies with high schema coverage, which is not the case here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Triple-click') and a target class ('a bound element or frame coordinate'), so an agent knows what the tool does at a high level. It is not a tautology. However, it does not explicitly contrast with sibling click tools, and the phrase 'bound element' is jargon that is not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance and names no alternatives. With siblings like 'double_click', 'left_click', 'right_click', and 'middle_click' available, the agent is left to infer triple-click is for three-click interactions solely from the name. No exclusions or preferred conditions 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?
The description reveals only the mechanical action and target type. It does not mention side effects such as opening links in new tabs, autoscroll behavior, or system-specific consequences, nor does it add context beyond the destructiveHint annotation already present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short, front-loaded sentence with no filler. It immediately communicates the action and the acceptable target forms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, and several closely related sibling click tools, the description is too thin. It does not explain when to prefer this click variant, what return_state can do in practice, or what behavioral effects to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a small amount of meaning by clarifying that the target can be a 'bound element' or 'frame coordinate', which maps to the schema's target variants. However, it does not explain app_ref, strategy, modifiers, or return_state; the schema provides most of the needed detail for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Middle-click') and a resource ('a bound element or frame coordinate'), which clearly communicates the core action. It is distinguishable from sibling mouse tools by the 'middle' modifier, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use middle_click versus left_click, right_click, double_click, or triple_click. The only implied usage comes from the tool's name and the literal description, so an agent is left to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry the safety profile (destructiveHint=true, readOnlyHint=false, idempotentHint=false), and the description adds no behavioral context beyond that: no mention of possible side effects like navigation, whether the action can fail or be rejected, or whether a prior get_app_state is required to obtain valid targets. The description does not contradict the annotations, but it contributes no behavioral insight of its own.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the verb ('Run') and resource ('accessibility actions') lead immediately. It is slightly terse for a tool with a two-variant target union and an optional return_state parameter, but every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutating tool with no output schema, a complex target union (element vs coordinate), and a large sibling set, one sentence is insufficient. The description does not explain how actions are discovered, what the coordinate target means for an accessibility action, what return_state returns, or what the tool's response looks like. An agent cannot fully determine invocation details from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the schema describes all three parameters with structure, defaults, and enums (action, target variants, return_state). The description adds only the framing that actions are 'advertised by an element,' which loosely connects the action parameter to the target element but does not explain where action strings come from, how to discover valid action names, or what the coordinate target variant is for. It neither strongly compensates for nor ignores the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Run one of the accessibility actions advertised by an element.' It is clearly distinguishable from the direct-input siblings (left_click, type, set_value, scroll) because it targets OS/expose-level accessibility actions rather than simulated input. It loses a point because it never explains what an 'accessibility action' is or when an element would advertise one, leaving some inference to the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus the 28 siblings. Notably, set_value and select_text overlap conceptually with accessibility actions, and the description neither names alternatives nor states conditions (e.g., 'prefer this when an element advertises an action'). The agent must guess when to choose perform_action over direct-input tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the description's job was to add behavioral context beyond that. It only adds the UTF-16 detail; it does not disclose that selecting replaces the previous selection, how coordinate targets resolve, or what side effects occur on the text element.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler and the key operation is front-loaded. It is efficient, though slightly too terse to fully support the more complex parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a non-trivial target schema, three parameters, and no output schema, this description is incomplete. It does not explain how target coordinates select a text element, what return_state values imply, or how text_range indices behave, leaving important context for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The phrase 'all or a UTF-16 range' gives useful meaning to text_range (null for all, array for a range) and adds UTF-16 encoding semantics. However, with schema description coverage at only 33%, the description does not compensate enough for the ambiguity of target (element vs coordinate) or clarify range inclusivity and bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('select') on a specific resource ('text element') with a clear scope ('all or a UTF-16 range'). This distinguishes it from sibling actions like type, click, or set_value, though it does not explicitly name any 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use select_text versus alternatives such as set_value or click, nor any mention of when not to use it. The only contextual hint is 'in a text element', which is too weak to route an agent to this tool confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the core action and adds no behavioral detail beyond the annotations. With destructiveHint=true, the mutation aspect is already disclosed, but the description does not explain effects on the target, which strategies do, or whether the value replaces or appends to existing state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler, making it easy to parse quickly. However, its brevity borders on under-specification rather than deliberate concise completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with four parameters and no output schema, the description is too sparse. It does not explain how the target is resolved, what the strategy option controls, or what return_state is for, leaving an agent with only the schema and annotations to understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the schema already documents most parameters. The description adds minimal meaning by identifying the resource as an accessibility element, which loosely ties to the target parameter, but it does not clarify strategy or return_state beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation—setting—and a specific resource: an accessibility element value. It is clear enough to distinguish from sibling tools like type or write_clipboard, though it does not explicitly differentiate itself from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as type, perform_action, or write_clipboard. There is no mention of prerequisites, target types, or conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, non-read-only operation, so the description carries a lighter burden. It adds useful context about targeting modes (bound element vs scoped-app focused element), but does not disclose behaviors such as whether existing text is overwritten, whether keyboard events are simulated, or whether strategy defaults affect invocation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 17 words with no filler. The core targeting distinction is front-loaded and easily parsed. It is concise and efficient, though it could have been slightly more structured to cover the coordinate mode without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively complex with 5 parameters, a nested target union, and multiple enum options, and there is no output schema to disambiguate behavior. The single-sentence description is insufficient on its own: it omits coordinate targeting, does not explain how target and app_ref interact, and offers no guidance on strategy or return_state. An agent would need to rely heavily on the schema and surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning by relating 'bound element' to the element target and 'focused element of a scoped app' to the app-level targeting concept. However, it does not explain coordinate targets, the 'app_ref' parameter, or the 'strategy' and 'return_state' enums beyond what the schema already provides. With only 60% schema description coverage, the description compensates only partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Type') and the resource ('text into a bound element or the focused element of a scoped app'), so an agent understands the primary function. It is distinguishable from key-press tools like 'key' and value-setting tools like 'set_value'. However, it omits the coordinate target mode present in the schema, slightly narrowing the expressed 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of alternatives, nor any mention of when not to use it. The description does not reference sibling tools such as 'key', 'set_value', or 'write_clipboard', and it fails to state preconditions like focus or accessibility requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the operability profile is covered. The description adds that the state is accessibility-first and that the screenshot is optional, which is useful context but does not reveal additional behavioral details such as return shape, scope of the captured state, or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It communicates the core action and optional capability efficiently, earning every word it uses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description needs to explain what the captured state includes or looks like, and it does not. The required app_ref parameter is also left unexplained. For an agent to call this tool correctly, it needs more context about how to identify the application and what kind of state will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with detail and include_screenshot already described in the schema. The description adds some meaning by tying 'accessibility-first application state' to the overall purpose and 'window image' to include_screenshot, but it does not clarify the required app_ref parameter, which remains undocumented and is essential for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: capture an accessibility-first application state, with an optional window image. It is clear about what the tool does, and the accessibility-first qualifier hints at a UI-tree-like state, but it does not explicitly differentiate this from sibling tools like screenshot or list_windows, which overlap on the image/state dimension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as screenshot, list_apps, or list_windows. The description tells the agent what the tool does but not when it is the right choice or when another sibling would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe read-only, idempotent, non-destructive profile. The description adds a valuable behavioral fact beyond them: the tool will not prompt the user. It also clarifies that the operation is a read, not an actual access request, which is useful given the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb, and zero filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that primarily reports permission/runtime status, neither the return shape nor the meaning of 'runtime readiness' is described, and there is no output schema to fill the gap. The annotations cover safety, but selection and invocation still require more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter `capabilities` has essentially no schema description (0% coverage), and the description never mentions it or explains how it interacts with the permission/runtime-readiness read. The agent is left to guess whether to pass capabilities and what values are valid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') plus a resource ('permission and runtime readiness'), and the qualifier 'without prompting' distinguishes it from the action implied by the name. It is not quite a 5 because 'permission' remains underspecified and no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to call this tool versus siblings like get_app_state or open_application. The phrase 'without prompting' tells the agent what the tool will not do, but not when it should be selected or what conditions make it necessary.
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 already mark this as destructive and read-write, but the description adds no behavioral context beyond the action itself. It does not mention side effects like opening a context menu, how coordinates relate to the latest raster, or anything about strategy behavior. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It states the action first and communicates the essential target forms compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A five-parameter destructive UI-action tool with no output schema and no usage guidance is under-described by one sentence. return_state behavior, strategy semantics, and coordinate resolution are not explained, making the definition incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides reasonable descriptions for target variants, strategy, modifiers, and return_state, so the description's brief mention of 'element or frame coordinate' adds little beyond what is structured. However, app_ref remains undescribed and modifier syntax is still vague, so the description doesn't fully compensate for remaining gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('right-click') and identifies both accepted target forms ('bound element or frame coordinate'), which clearly distinguishes it from sibling click tools such as left_click, double_click, and middle_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use right_click instead of left_click, double_click, middle_click, or other mouse tools. It also doesn't explain when coordinate targeting should be preferred over element targeting, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral detail beyond purpose: it doesn't say whether it returns a new cropped frame, whether the original frame is left unchanged, how the crop is applied around an element, or what the output looks like. With no output schema, these gaps matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Crop a region from an existing frame or around an element target.' Every word earns its place, there is no repetition of the tool name or title, and the primary operation is stated first. It is appropriately sized for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and only 33% schema description coverage, so the description must carry more weight. It omits critical invocation details: the meaning of the region array, whether region and target can be combined, whether frame_id is required for region-based cropping, and what a successful crop returns. An agent could call this with incomplete or wrong parameters based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description needs to compensate. It does help by indicating that 'region' and 'element target' are two alternative ways to specify the crop. However, it doesn't explain the coordinate variant of target, the meaning of the 4-integer region array, or how frame_id relates to the operation; those semantics are left to the bare schema, which lacks descriptions for region and the target union itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Crop a region') and the resources it acts on ('an existing frame' or 'an element target'). It clearly distinguishes the two input modes, and among the siblings no other tool performs cropping. However, it doesn't explicitly differentiate itself from tools like screenshot or get_app_state, and the name 'zoom' versus the verb 'crop' introduces a slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells the agent when to use the tool: whenever a region of a frame or an element-centered crop is needed. It gives no explicit guidance about when not to use it, no alternatives to prefer, and doesn't clarify whether region and target are mutually exclusive. This is enough to infer basic usage but lacks decisive routing information.
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 already flag the operation as destructive and non-read-only, so the safety profile is known. The description adds no further behavioral context, such as the possibility of triggering application actions or requesting an observed state afterward. It is behaviorally neutral and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with the action verb first and no filler. It is easy to scan and every word contributes to the core meaning. The terseness costs behavioral detail, but that is a completeness issue, not a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, a union target type, and mutation semantics, the description alone is thin, but the input schema provides detailed field descriptions and annotations cover the destructive nature. What is still missing is high-level guidance on when a double-click is the correct interaction and what observable effect to expect. Overall it is minimally viable rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage around 60% and detailed inline descriptions for target, strategy, modifiers, and return_state, the schema does most of the work. The description's 'bound element or frame coordinate' aligns with the target union but adds no new meaning beyond the schema. Baseline 3 is appropriate because the description neither compensates for app_ref nor repeats unnecessary schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb+object 'Double-click a bound element or frame coordinate' names a specific action and the two supported target kinds, and it distinguishes this tool from single/triple/right-click siblings. 'Bound element' is slightly jargon-y but understandable in context of the target schema. This goes well beyond a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use double_click instead of left_click, triple_click, or other click variants, and no mention of prerequisites or context. The description only states what the tool does, not when to prefer it. This is absence of guidance, not misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the action is not read-only and is destructive, so the description does not need to restate that. The description adds the 30-second limit, which is useful behavioral context. However, it does not disclose what happens at the end of the duration (e.g., automatic release, failure), or why the action is considered destructive, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of one clear, front-loaded sentence with no filler. Every part contributes meaning: the action, the target, and the duration limit. It is an exemplary model of concise tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters and no output schema, and the description covers only the core action and duration cap. It does not explain when to choose this over the sibling 'key' tool, the role of 'app_ref', or the behavior surrounding the 30-second limit (e.g., whether it auto-releases or errors). Given the simple action, the description is workable but leaves several decision-relevant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents most parameters well. The description adds the 'up to 30 seconds' constraint, which clarifies the duration parameter's limit, but it does not add meaning to 'text', 'strategy', or 'return_state' beyond what the schema provides. This is consistent with the baseline 3 for high schema coverage with minor added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('hold') and resource ('key or chord'), and adds the key constraint 'up to 30 seconds.' This makes the core action clear. It does not explicitly distinguish the tool from the sibling 'key' tool, so it loses a point for failing to differentiate from an ambiguously named 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'key', 'type', or 'set_value.' The phrase 'up to 30 seconds' implies use for sustained key presses, but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description does not contradict the annotations and adds the target scoping ('bound element or frame coordinate'), but it does not explain side effects or what happens to the UI state after the click.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. Every word contributes: it states the action and the two valid target kinds, making it easy to scan and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema and annotations, the description is adequate but thin. It does not help an agent distinguish when a simple left click is preferred over related sibling tools, and it leaves 'return_state' and strategy selection to the schema alone. Overall it is serviceable but not fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description summarizes the two target variants ('bound element or frame coordinate') which helps clarify the 'target' parameter. However, it adds nothing about 'strategy', 'modifiers', 'return_state', or 'app_ref', and with 60% schema coverage the description only partially compensates for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Click') and clearly scopes the resource to 'a bound element or frame coordinate.' This distinguishes it from sibling mouse actions like 'left_click_drag', 'double_click', and 'right_click', though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus siblings like 'double_click', 'right_click', or 'left_mouse_down'. The intended use for a single left click is only implied by the tool name and description, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, non-destructive, and idempotent, so the bar for the description is lower. The description adds that the listing is scoped to an application, but it does not disclose behavioral details such as whether the returned list is sorted, whether hidden windows are included, or what happens when the app has no windows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no wasted words. It gets the core behavior across immediately and is easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations, the description is minimally viable. However, there is no output schema, so the description should say more about the expected return shape or contents of the window listing, and it does not. The missing app_ref semantics also leave the overall calling context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single required parameter app_ref is completely undocumented in the schema. The description only mentions 'application', implying app_ref identifies an application, but it does not specify whether this is a name, ID, path, or process handle, leaving the agent without sufficient parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'List windows', and scopes it to 'an application', making the tool's purpose clear. It is also distinguishable from sibling tools like list_apps, which lists applications rather than windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, such as whether to use it after open_application or how it relates to get_app_state. The only contextual hint is the app requirement, which is not enough to guide an agent through tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call as destructive and non-idempotent. The description adds useful behavioral context by saying it latches a session kill switch and releases held input, indicating a persistent, state-changing effect. It does not contradict annotations, though it could be more explicit about irreversibility or effects on the active session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no filler; each clause conveys a distinct behavior. The wording is economical but slightly obscure ('latch,' 'kill switch'), which prevents a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent control stop with no output schema, the description covers the core effect but omits surrounding context such as prerequisites, what happens afterward, and how the optional reason should be used. This is adequate for a simple command but leaves gaps for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description was responsible for explaining the optional `reason` parameter, but it never mentions it. The parameter's name and minimal schema text make it partially self-explanatory, but no guidance is given about when or how to provide a reason.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (latch a session kill switch) and a secondary effect (release held input), clearly distinguishing this from sibling input/action tools. However, the 'latch the kill switch' wording is metaphorical rather than plain functional language, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to end a control session and release all held input, which distinguishes it from individual release tools like hold_key or left_mouse_up. However, it does not explicitly state when to call it, what conditions require it, or which alternatives might be preferable; the guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnly=false, so the description does not need to restate the safety profile. It adds the scoped-application targeting behavior, but it does not disclose potential side effects such as triggering application shortcuts or whether the target app must be focused.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the action verb and target are front-loaded. Every word adds meaning, making it appropriately concise for the tool's basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no output schema and many sibling input tools, the description is adequate but thin. It establishes the high-level action and target while relying on the schema for parameter details, but it lacks routing guidance and app_ref semantics, so an agent may need additional information to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover text, strategy, and return_state, with a basic description for repeat, while app_ref has no schema description. The description's 'scoped application' hints at the role of app_ref but does not specify its format, and no other parameters are elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb ('Send'), names the object ('a key or chord'), and specifies the target ('a scoped application'), so the core function is clear. It does not explicitly contrast with sibling tools like type or hold_key, but the scoped-application qualifier helps distinguish it from global input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to a scoped application' implies this is for app-targeted input, which is a useful usage signal. However, there is no explicit guidance on when to prefer key over type, hold_key, or perform_action, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the action as destructive and non-read-only, lowering the burden. The description adds the notion of a 'scoped' hold but does not disclose edge cases (e.g., behavior if no hold is active) or side effects. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no redundancy. The core action is front-loaded ('Release...'), and the qualifier 'scoped' adds necessary differentiation without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers the only parameter. However, the description omits usage context (when to call, what observing with 'compact' or 'full' means in practice) and no output schema exists, so an agent relies on inferences for surrounding behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter return_state is fully documented in the schema with an enum and description, so the description does not need to add detail. It does not mention the parameter, but schema coverage is 100%, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Release') on a clearly identified resource ('the scoped left-button hold'). This distinguishes it from sibling tools like left_mouse_down or left_click, though the meaning of 'scoped' is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool. The name and 'release' imply it should be used after a hold was established (e.g., via left_mouse_down), but the description does not name the counterpart or discuss alternatives, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds scoping context ('currently running') that distinguishes it from installed applications, but it does not disclose output format, whether background apps are included, or any permission nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short, front-loaded sentence: 'List currently running applications.' There is no filler, and every word contributes to the tool's meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with no output schema, the description is nearly sufficient. An agent can invoke it correctly without further parameters or side-effect concerns, though it would benefit from a note about what the returned list contains (e.g., names, IDs) or how it compares to list_windows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100% (vacuously), so there is no parameter ambiguity for the description to resolve. With no parameters, the baseline is 4, and the description does not introduce any conflicting or missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('currently running applications'), making the tool's purpose unambiguous. It is naturally distinct from siblings like list_windows (windows) and get_app_state (state of an app), so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no guidance on when to choose it over alternatives such as list_windows or get_app_state. There are no explicit usage conditions, prerequisites, or exclusions, so the agent must infer appropriate usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Behavioral context is added beyond annotations by clarifying that the pointer is synthetic and the user's physical cursor stays put. Annotations already indicate a non-read, destructive-ish action, and the description complements that by explaining the key side-effect boundary without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes meaning, and the most important behavioral distinction—synthetic pointer vs. physical cursor—is stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers the coordinate object variants and return_state, while annotations cover the mutation/safety profile. The description adds the crucial physical-cursor behavior. However, app_ref semantics are left unexplained and there is no output schema, so an agent still has some gaps when invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the coordinate variants, app_ref, or return_state. The schema does describe coordinate and return_state, but coverage is only 33% and app_ref remains undocumented. Since schema coverage is low, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Move'), a specific resource ('synthesized pointer'), and the key distinction that the physical cursor is unaffected. This clearly separates it from sibling tools like cursor_position or left_click_drag 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool is appropriate: when pointer movement should not disturb the user's physical cursor. However, it gives no explicit guidance about alternatives, such as using left_click_drag for drag operations or cursor_position for reading the current pointer location.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that this is not read-only and is marked destructive. The description adds the useful context that the tool's effect is scoped to screenshots. It does not disclose persistence or side effects beyond that, but for a simple one-parameter selector this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It says exactly what the tool does and nothing more.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one fully documented parameter, no output schema, and annotations covering safety, the description is nearly complete. It could optionally reference list_displays for discovering valid indices or clarify whether the selection persists, but these are not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the 'index' parameter is already described as a zero-based display index. The description adds no additional parameter-level detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Select') on a specific resource (the display used by screenshot), making the tool's purpose unambiguous. It naturally distinguishes this from sibling tools like list_displays and screenshot, since it describes a configuration action rather than enumeration or capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use this tool to choose which display screenshots will target. However, the description does not explicitly mention using list_displays to get valid indices, does not state whether the setting persists, and gives no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the agent knows this is a destructive operation. The description adds that the clipboard content is replaced and that the replacement is plain text, which implies loss of any rich formatting. This is useful context but not deeply rich behavioral detail beyond what destructiveHint already signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler words. The core action 'Replace' is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with destructive annotations and no output schema, the description covers the essential behavior adequately. It could mention the counterpart read_clipboard or permission implications, but those are secondary for such a simple clipboard write.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'text' parameter already described as 'Clipboard text.' The description's 'plain text' phrasing slightly reinforces that text is a plain string but adds little new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Replace'), the target resource ('system clipboard'), and the format of the new content ('plain text'). This clearly distinguishes it from the sibling read_clipboard and from text-entry tools like type or set_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—whenever the agent needs to set the system clipboard—but it does not explicitly state this or contrast with alternatives like read_clipboard. No exclusions or conditional guidance 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?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the description carries less burden. It adds the valuable behavioral detail that focus is not taken unless activate=true, and hints at both resolution and launching. However, it doesn't explain what 'resolve' means operationally, nor does it disclose the specific side effects of launching (e.g., creating new processes or potentially affecting existing app state).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence with no filler. The most decision-relevant behavioral fact (focus is not taken unless activate is true) is front-loaded, making it immediately usable for an agent evaluating the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the detailed schema and annotations, covers the main selection and invocation requirements. The primary gaps are the ambiguous 'Resolve or launch' phrase and the absence of any return-value indication, especially since no output schema exists. These are moderate but do not prevent correct usage in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% and the nested app properties are well described in the schema. The description adds meaning for the 'activate' parameter by clarifying focus behavior, but it does not compensate for the undocumented 'app' property or elaborate on how to choose among bundle_id, name, or pid variants. The schema does most of the parameter-semantic heavy lifting, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb combination ('Resolve or launch') and clearly identifies the resource ('an application'), while adding a key distinguishing behavior ('without taking foreground focus unless activate is true'). This makes it immediately distinct from query-oriented siblings like list_apps and get_app_state without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when an application needs to be resolved or launched, with the important caveat about focus behavior. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough that an agent can determine appropriateness from the sibling names and this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It does add the context that the capture target is the 'selected display', implying dependence on an external selection state. However, it does not disclose what the screenshot produces (e.g., file path, clipboard) or any other side effects, which would add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, six-word sentence with no unnecessary words. It is front-loaded with the action and target, making it maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with safety annotations, the description is nearly complete: it states the action and object. The only notable omission is the return format or output behavior, but with no output schema and an obvious name, this is a minor gap. Overall, an agent can confidently invoke this tool based on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The phrase 'selected display' clarifies that the tool operates on a pre-selected display rather than taking a parameter, which adds meaning beyond the empty schema. No parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Capture', and a specific resource, 'the selected display', making the tool's function immediately clear. No sibling tool handles screenshots, so it stands apart without needing explicit differentiation. It is a genuine statement of function, not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the action and target, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites like prior display selection. There are no direct screenshot siblings, so alternatives are not needed, but the lack of any explicit when-to-use guidance leaves it to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds the 'physical' scoping but does not disclose output format, coordinate system details, or behavior on multi-display setups. This is a minor gap since the operation is trivial and side-effect-free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the essential action and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool, the description is complete enough for an agent to select and invoke it correctly. The expected result—the physical cursor position—is clearly implied, and no additional prerequisites or edge cases are needed for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain beyond the schema, which already has 100% coverage. Per the rubric, a zero-parameter tool receives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Read the physical cursor position.' It clearly distinguishes the tool from siblings like mouse_move, which changes position rather than reading it, and 'physical' clarifies that it reports global coordinates rather than app-relative ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—whenever the agent needs the current cursor position—but it does not explicitly state when not to use it or name alternatives. Given the tool's zero-parameter simplicity and read-only nature, the implicit guidance is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful 'plain text' limitation, but it does not mention behavior when the clipboard holds non-text data or is empty. With annotations carrying most of the behavioral burden, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded, grammatically complete sentence with no filler. Every word adds meaning, and it fully states the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation with annotations covering safety, the description is fully sufficient. There is no output schema, but for a simple clipboard-text read the description explains the behavior adequately; nothing an agent needs to decide whether to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter burden for the description to carry. With schema coverage at 100% and no params to document, the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('read') and resource ('system clipboard'), and further narrows the scope to 'plain text'. This clearly distinguishes it from write_clipboard and other sibling tools without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever an agent needs the current clipboard text. However, it does not explicitly mention when not to use it or point to write_clipboard as the alternative for setting clipboard content, leaving that distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the useful detail that coordinate spaces are included in the result, but does not explain the format or whether the display order or identifiers are stable across calls. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It states the action and the key output in eight words, which is ideal for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, idempotent, zero-parameter list operation, the description gives enough context. It identifies the domain (displays) and the meaningful output (coordinate spaces). Without an output schema, a bit more detail about the exact shape of the output could help, but the risk of incorrect invocation is very low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not a concern. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description adds no misleading parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('List') and resource ('attached displays'), and specifies what is returned: their coordinate spaces. It is easy to distinguish from sibling tools like list_windows and list_apps because it explicitly targets displays.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's zero-parameter nature makes usage straightforward, and the description implies it should be used when an agent needs to know available displays and coordinate systems. It does not explicitly name alternatives or exclusions, but the clarity of the resource makes misuse unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the key behavioral limit (maximum 30 seconds) and confirms the tool blocks for the given duration. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's function and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple sleep tool with one parameter, complete annotations, and no output schema, the description covers the essential information. A minor gap is the behavior for invalid or out-of-range durations, but such detail is largely unnecessary for this straightforward action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing the base parameter description ('Duration in seconds'). The tool description adds meaningful semantic value by specifying the upper bound ('up to 30 seconds'), which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pause') and states the resource/action ('up to 30 seconds'), clearly distinguishing this from sibling tools like clicks, typing, and scrolling. There is 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when the agent needs to pause execution. Since no sibling tool offers similar waiting functionality, explicit exclusions or alternatives are unnecessary. The 'up to 30 seconds' qualifier also gives a concrete usage boundary.
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:

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

Score Badge

Copy to your README.md:

[![open-zcode-computer-use MCP server](https://glama.ai/mcp/servers/hqhq1025/open-zcode-computer-use/badges/score.svg)](https://glama.ai/mcp/servers/hqhq1025/open-zcode-computer-use)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hqhq1025/open-zcode-computer-use'

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