Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@codex-cua-mcp open Notepad and type 'Hello World'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
π¬ LINUX DO Discussion
Wraps Codex's Computer Use capability as an MCP server, enabling AI agents to control Windows desktop applications.
List and control Windows desktop applications
Capture screenshots and accessibility trees
Click, type, press keys, scroll, drag, and more
Launch apps and activate windows
Ready to use - exe bundled, no extra setup needed
Related MCP server: WinPilot Computer Use MCP
Hand the install doc to your AI agent β send this prompt:
Please clone the repository https://github.com/RS-Nocsi/codex-cua-mcp locally, read its INSTALL.md, and install this MCP server into your own MCP configuration by following it.Your agent (Claude Code, Cursor, Windsurf, Cline, OpenCode, Gemini CLI, etc.) will clone the repo, check prerequisites, build the project, and register the server itself. Fully restart the agent afterwards.
Prefer manual setup? Follow INSTALL.md yourself.
AI Agent (Claude Code, Cursor, etc.)
β MCP protocol (stdio)
MCP Server (codex-cua-mcp)
β JSON-RPC (stdin/stdout)
codex-computer-use.exe
β Windows APIs
Desktop ApplicationsThe MCP server communicates with codex-computer-use.exe via JSON-RPC over stdin/stdout. The exe uses Windows APIs (SendInput, UI Automation, Windows.Graphics.Capture) to interact with desktop applications.
The desktop overlay shows which agent is controlling the computer (e.g. "Claude Code is using your computer"). Please set the CUA_AGENT_NAME environment variable to your own display name in the registration β see INSTALL.md Step 4. Each agent has its own runtime config under config-runtime/; multiple agents can install this MCP simultaneously without conflict.
π Want to understand the design in depth? Read the Architecture Deep Dive.
Tool | Description |
| List all controllable windows |
| List installed apps |
| Rehydrate a window object |
| Launch an application |
| Bring window to foreground |
| Screenshot + accessibility tree |
| Click |
| Type text |
| Press key |
| Scroll |
| Drag |
| Set input field value |
| Secondary action (right-click menu, etc.) |
The core capability comes from codex-computer-use.exe. Actual results depend on the AI agent and model used β no usability guarantee.
Windows 10/11
Node.js 18+
MIT
Bring a window to the foreground
| Name | Required | Description | Default |
|---|---|---|---|
| window | Yes | Window object from list_windows or get_window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, required window states, or error handling. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, and it is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple activation tool, the description covers the basic function, but it fails to specify behavior when the window is not found, minimized, or requires permissions, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond specifying that the window object should come from list_windows or get_window (which is already in the schema's description).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'bring' and resource 'window', and the action 'foreground' is distinct from sibling tools like list_windows or get_window which retrieve information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no discussion of prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click at coordinates or on an element in a window
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X coordinate | |
| y | No | Y coordinate | |
| window | Yes | Window object | |
| click_count | No | Number of clicks (default: 1) | |
| mouse_button | No | Mouse button (default: left) | |
| screenshotId | No | Screenshot id for coordinate reference | |
| element_index | No | Element index from accessibility tree |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral implications (e.g., whether the window is activated, what happens if the element is not found, or coordinate system). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence, but it lacks structure (e.g., no separate sections for usage). It is front-loaded but could be expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is incomplete. It omits return value, error conditions, and coordinate system details. For 7 parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'click' and the resource 'at coordinates or on an element in a window'. It distinguishes from siblings like drag and perform_secondary_action, though it could be more specific about what constitutes an element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or siblings. Does not specify when to use coordinates versus element index, or prerequisites like window activation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drag from one coordinate to another in a window
| Name | Required | Description | Default |
|---|---|---|---|
| to_x | Yes | End X | |
| to_y | Yes | End Y | |
| from_x | Yes | Start X | |
| from_y | Yes | Start Y | |
| window | Yes | Window object | |
| screenshotId | No | Screenshot id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It only states the basic action, omitting details about behavior (e.g., mouse button used, duration, whether drag is completed). Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of minimal length, which is concise but arguably too brief. It front-loads the action but sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 6 parameters including a nested object, the description is severely incomplete. It fails to explain return values, side effects, or how coordinates relate to the window context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 6 parameters (100% coverage). The description adds 'from one coordinate to another', which offers a high-level overview but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Drag from one coordinate to another in a window' clearly identifies the action (drag) and the resource (a window, with start and end coordinates). It distinguishes the tool from siblings like click or scroll, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description lacks context about appropriate scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rehydrate a window object by id (useful after losing window binding)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Window id | |
| app | No | App identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'rehydrate' without clarifying whether it is read-only, what happens if the id is invalid, or any side effects. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, with no filler. It immediately states the core action and context, making it extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should provide hints about return values. It does not. For a tool that 'rehydrates' an object, agents need to know what properties are returned. The description is insufficient for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing 'Window id' and 'App identifier'. The description adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Rehydrate a window object by id'. The verb 'rehydrate' is specific and the phrase 'useful after losing window binding' adds context, distinguishing it from sibling tools like get_window_state or activate_window. However, 'rehydrate' may be slightly jargon-y, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a specific use case ('after losing window binding') but does not explicitly state when not to use this tool or compare it to alternatives like get_window_state. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture screenshot and/or accessibility tree of a window. Call this before input actions.
| Name | Required | Description | Default |
|---|---|---|---|
| window | Yes | Window object | |
| include_text | No | Capture accessibility tree (default: false) | |
| include_screenshot | No | Capture screenshot (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adequately states the tool captures screenshot/accessibility tree, a read-only operation, but does not disclose any potential side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the purpose and usage hint. Every word is necessary, and no information is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and parameters are well-documented in the schema, the description does not explain what the output contains (e.g., screenshot data format, accessibility tree structure). Given no output schema, this leaves a gap in completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters. The description adds no additional parameter semantics beyond the schema, leading to a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it captures screenshot and/or accessibility tree of a window. It uses specific verbs and resources, and distinguishes from siblings which are action-oriented tools (e.g., click, type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this before input actions,' providing clear context for when to use the tool. It does not state when not to use or mention alternative tools, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch an application
| Name | Required | Description | Default |
|---|---|---|---|
| app | Yes | App id from list_apps, or exe path like "notepad.exe" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. 'Launch an application' is minimal; it does not explain effects (e.g., new window, error if app not found), permissions, or side effects like existing instances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but overly terse. It sacrifices necessary detail for brevity, resulting in a phrase that is minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and simple tool, but the description fails to explain return values or outcomes. It is incomplete even for a single-parameter tool; should mention behavior like launching a process or opening a window.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter has description). The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Launch an application' indicates a verb and resource, but is vague. It does not specify whether it starts a new process, opens a window, or what 'launch' entails. Among siblings like activate_window and list_apps, it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The parameter description hints at prerequisites (app id from list_apps) but the tool description itself provides no context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List installed apps with their open windows
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it is vague. It does not clarify if it returns only running apps, all installed apps, or apps with windows. No mention of permissions, performance, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the key action and resource. Every word is meaningful, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is minimally adequate but lacks details on return format or edge cases. It could be improved with more specific behavior, but it covers the core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by clarifying the output scope (apps and their windows), which is not explicitly stated in the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (list) and the resources (installed apps with their open windows). This clearly distinguishes it from sibling tools like 'launch_app' and 'list_windows'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_windows'. An agent would need to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open windows that can be controlled
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as return format, side effects, or whether the listing is synchronous. Minimal info beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous words. Content is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what information is returned (e.g., window IDs, titles). It only says 'list windows', leaving agents to guess the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no extra meaning, but the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'list' with resource 'open windows that can be controlled', clearly indicating the tool's function. It distinguishes from siblings like get_window (single window) and activate_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_window or list_apps. No context about prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a secondary action on an element (e.g., right-click menu, expand)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action name (e.g., "Raise", "Expand", "Collapse") | |
| window | Yes | Window object | |
| element_index | Yes | Element index from accessibility tree |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not mention side effects, prerequisites (e.g., element focus), or whether the action is state-changing. The description is too brief to reveal important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose. It is front-loaded and to the point, but could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested object, no output schema), the description is incomplete. It does not explain what constitutes a 'secondary action' comprehensively, list possible actions, or clarify the return value (if any). The user is left guessing about supported actions and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all parameters. The description adds value by providing example action strings ('Raise', 'Expand', etc.), but does not elaborate on the window object structure or element_index beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('perform a secondary action') and provides examples ('e.g., right-click menu, expand'), making it distinct from sibling tools like click, drag, and scroll. However, the term 'secondary action' is somewhat vague and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The sibling list suggests other interaction tools, but the description does not specify conditions or exclusions for using perform_secondary_action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a keyboard key or chord (e.g., 'Return', 'Control_L+a')
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key name (e.g., 'Return', 'Tab', 'Control_L+a') | |
| window | Yes | Window object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose what happens if the window is not focused, whether the key press is synchronous, or whether invalid keys cause errors. Behavioral traits are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the action and includes examples. No wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and no annotations, the description is adequate but leaves gaps: no explanation of return behavior, error handling, or prerequisites (e.g., window must be active). Could be more complete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both 'key' and 'window' described), so baseline is 3. The description adds an example for the key parameter but does not clarify the window structure or how to specify a chord (e.g., 'Control_L+a' format). Not much value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (press a keyboard key or chord) with concrete examples ('Return', 'Control_L+a'). The verb 'press' and resource 'keyboard key/chord' are specific. However, it does not explicitly distinguish from sibling tools like 'type_text' or 'click', though the difference is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'type_text' for text, 'click' for mouse actions). The description assumes the agent knows context, but does not provide when-not-to-use or mention prerequisites like window focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll at coordinates in a window
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate | |
| y | Yes | Y coordinate | |
| window | Yes | Window object | |
| scrollX | Yes | Horizontal scroll delta | |
| scrollY | Yes | Vertical scroll delta | |
| screenshotId | No | Screenshot id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as side effects, permissions, or error handling. The single sentence adds little beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the expense of important details. While concise, it omits critical information needed for proper tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters including a nested object, no output schema, and no annotation, the description is severely incomplete. It fails to explain coordinate units, behavior at boundaries, or how the window parameter is used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the description does not need to add extra semantics. However, it does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the verb 'scroll' and the target 'at coordinates in a window', distinguishing it from sibling tools like click, drag, and press_key. However, it could be more specific about the scroll behavior (e.g., delta or absolute position).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites. The description lacks context about suitable scenarios or cooldowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the value of an editable element
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Value to set | |
| window | Yes | Window object | |
| element_index | Yes | Element index from accessibility tree |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It does not state whether setting a value clears existing content, triggers events, or what happens if the element is not editable. Safety implications (e.g., overwriting critical data) are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise but lacks structure. It does not front-load critical context, and every word is generic. Length is appropriate, but content density is low.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (including a nested object), no output schema, and no annotations, the description is incomplete. An agent cannot determine how to construct the 'window' object, what 'element_index' represents, or the expected return. Siblings like type_text have more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no meaning beyond the schema: it does not explain the 'window' object structure or how 'element_index' relates to the accessibility tree, nor does it specify accepted value types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the value of an editable element' clearly states the verb (set) and resource (value of editable element), distinguishing it from siblings like click or type_text. However, it lacks specificity on what constitutes an 'editable element' (e.g., text field, dropdown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 type_text or click. It does not mention prerequisites (e.g., window must be active, element must be focused) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into the current focus of a window
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type | |
| window | Yes | Window object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as requirements (window must be focused), support for special characters, typing speed, or error handling. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, very concise. However, lacks structure (no bullet points or paragraphs). Could be considered under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 2 parameters (one nested) and no output schema. Description fails to mention prerequisite actions (e.g., window activation via activate_window) or return behavior. Insufficient for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond parameter names and schema descriptions (e.g., 'text' and 'window object'). No explanation of window id or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'type text' and the resource 'current focus of a window'. It distinguishes from siblings like press_key by focusing on text input, but could be more explicit about simulating keyboard typing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., press_key for shortcuts, click for mouse). No exclusions or when-not-to-use criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0activate_windowclickdragget_windowget_window_statelaunch_applist_appslist_windowsperform_secondary_actionpress_keyscrollset_valuetype_textScored across 13 tools
Each tool has a clearly distinct purpose: window management, input actions, app launching, and element manipulation. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores (e.g., activate_window, get_window_state). No mixing of styles or irregular naming.
13 tools cover a well-scoped set of GUI automation operations (window control, input, app management), neither too few nor excessive for the domain.
The tool surface covers core actions (launch, list, navigate, input, state capture). Minor gaps like explicit screenshot-only or element waiting could exist but the set is largely complete for typical workflows.
Eyes and hands on real Windows PCs β observe, click, type via Glasswarp API.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Turns a phone into a camera+Bluetooth remote so AI assistants can see and control any PC.
Run and manage H Company's Computer-Use Agents from any MCP client.
