/computer-use

name: computer-use
description: Inspect and operate native Windows, macOS, or Linux applications through Poracode's desktop-control tools. Use for visual workflows that require real windows; prefer Browser for web pages and a purpose-built connector or API when one can complete the task directly.

Computer Use

Use Poracode's `computer_use` MCP for tasks that require interacting with desktop applications or native windows. Do not use it for a web page when Browser or Chrome is the intended surface, or for a semantic operation that a safer purpose-built connector can perform.

Tree conventions, `delivery.verified`, refusals, and platform recovery live in the `computer_use` MCP instructions. Do not re-derive them here.

Workflow

1. Pick the exact window with `list_apps` or `list_windows`. Call `computer_use.api` only for capability or permission status. If the app is not running, `list_apps` with `query` then `launch_app`. 2. Inspect with `get_window_state` (`include_text:true`; `include_screenshot:false` unless you need pixels or coordinates). Prefer `invoke_element` or `set_element_value` over coordinates. 3. Call `computer_use.enable` immediately before the first control action and keep it enabled across uninterrupted related steps. 4. Act, then verify from the window. Prefer `observe:"text"`; use `"screenshot"` or `"both"` for visual checks. Reuse `observation.state`. Continue only after a successful `delivery`; follow a `refused` hint. 5. Use `perform` only for a deterministic background element/value/key/text sequence against one window, with one final observation. After a partial failure, inspect before continuing; do not replay the batch. 6. Use `mode:"foreground"` and `activate_window` only when the user asked for a takeover, and tell them immediately before taking over the real pointer and keyboard. A refusal is never the licence: a `background_unavailable` refusal means follow the hint to `find_elements` plus `invoke_element` or `set_element_value`. If no background route can do the job, stop and tell the user what you need instead of taking their desktop. 7. Call `computer_use.disable` before asking the user for input, waiting on an external event, or finishing.

Boundaries

• Background actions leave the user's foreground window, pointer, and keyboard alone. Foreground actions take over the desktop.
• Locked desktops, secure prompts, operating-system permission dialogs, passwords, and authentication surfaces require the user.
• Do not type or expose secrets unless the user supplied them for that exact purpose.
• Confirm before destructive changes or external communication unless the user already authorized the exact action.

Output

Report the application and window used, the verified final state, and any step requiring user interaction. Do not claim completion from input dispatch alone.