ClawdCursor

Overview Schema Source Related Servers Discussions Admin

window

Destructive

Control desktop apps and displays at OS level: list apps, focus, monitor bounds, and screen size. Open apps/files/URLs and focus, arrange, resize, minimize, maximize, restore, or close GUI items.

Instructions

Windows, apps and displays at the OS level: find, open, focus and arrange windows. For what is INSIDE a window use accessibility; for a web page's DOM use browser. Read-only: list (every visible window: title, process, pid, screen bounds), active (the focused window), list_displays (monitors with bounds and DPI), screen_size. Arrange — target with processName, processId or title (substring); none given = the foreground window: focus (bring to front, keeps it maximized), maximize, minimize, restore, resize (x, y, width, height in screen px — the units list and accessibility report; space:"image" for screenshot pixels; omitted fields are kept). close asks the app to close, like its ✕: the app may prompt to save and unsaved work can be lost, so it needs the user's confirmation (safety gate). Open: open_app (name; launches or focuses, and says when no window has appeared yet), open_file (path, in its default app — an .exe/.app is executed), open_url (url, in the default browser), navigate (url, in clawdcursor's own browser for DOM work — same as browser navigate), switch_tab (index 1–9, or direction next/previous; a keyboard shortcut in the focused browser). Returns text: the window list, or one line saying what happened; a failure says why (no matching window, refused by the safety gate).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "window"
  }
}

Input Schema

Name	Required	Description
`x`	No	New X (top-left origin, logical px)
`y`	No	New Y (top-left origin, logical px)
`url`	No	https:// or http:// URL
`name`	No	Application name (e.g. "notepad", "calc", "mspaint", "Outlook", "Chrome")
`path`	No	Absolute filesystem path
`index`	No	Jump to tab N (1-based, 1-9). If omitted, direction must be provided.
`space`	No
`title`	No	Window title substring to match
`width`	No	New width in logical px
`action`	Yes	Which sub-action to perform. See this tool's description for the enum of valid values. Required: open_app: name; open_file: path; open_url/navigate: url.
`expect`	No	Optional post-conditions to verify after this action (same assertion types as the verify tool: window_title_contains, app_running, element_exists, element_value_contains, clipboard_contains, file_exists, file_contains, ocr_contains, file_changed_since_start). If any FAIL the action returns a DEVIATION and you must adapt. State an OUTCOME you can observe (a window title, a rendered element/chip, a status) — NOT the raw text you typed.
`height`	No	New height in logical px
`direction`	No	Cycle "next" or "previous". Ignored when `index` is given.
`processId`	No	Process ID to focus
`processName`	No	Process name to focus (e.g. "notepad", "msedge")

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.5.24Oct 27, 2026

changedInput schema / properties / action / description

Previous value: -"Which sub-action to perform. See this tool's description for the enum of valid values."New value: +"Which sub-action to perform. See this tool's description for the enum of valid values. Required: open_app: name; open_file: path; open_url/navigate: url."

addedInput schema / properties / expect

Added value: +{
+  "description": "Optional post-conditions to verify after this action (same assertion types as the verify tool: window_title_contains, app_running, element_exists, element_value_contains, clipboard_contains, file_exists, file_contains, ocr_contains, file_changed_since_start). If any FAIL the action returns a DEVIATION and you must adapt. State an OUTCOME you can observe (a window title, a rendered element/chip, a status) — NOT the raw text you typed.",
+  "items": {
+    "properties": {
+      "type": {
+        "enum": [
+          "window_title_contains",
+          "app_running",
+          "element_exists",
+          "element_value_contains",
+          "clipboard_contains",
+          "file_exists",
+          "file_contains",
+          "ocr_contains",
+          "file_changed_since_start"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedv1.5.16Oct 18, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: close behaves like the ✕ and can lose unsaved work, gated on user confirmation; focus keeps the window maximized; switch_tab is a keyboard shortcut sent to the focused browser; open_app reports when no window appeared yet; failures explain why (no match, refused by safety gate). This is consistent with destructiveHint/openWorldHint and adds the specifics an agent needs.

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?

Front-loaded with purpose and sibling routing, then grouped read-only / arrange / open actions. It is dense and runs long per action, but nearly every clause carries operational detail; a small amount of tightening (e.g. the nested parentheticals in `resize`) would help.

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 15-action dispatcher with no output schema, it explains the return text ('the window list, or one line saying what happened') and failure modes. The only gap is the `expect` post-condition parameter, which is left entirely to the schema; otherwise complete.

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 93%, so the schema carries most parameter docs, but the description adds material semantics the schema does not: target resolution by processName, processId or title substring with foreground as the default when none is given, resize units in screen px vs space:'image' for screenshot pixels, and that omitted resize fields are kept. The schema's `space` description is empty, which the description fills.

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?

States a specific verb set and resource: OS-level windows, apps and displays, with find/open/focus/arrange. It explicitly draws the boundary against siblings: 'For what is INSIDE a window use `accessibility`; for a web page's DOM use `browser`.' An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names alternatives and the conditions that select them (accessibility for window content, browser for DOM, navigate vs open_url, clawdcursor's own browser). Per-action guidance is explicit, including when close requires user confirmation and that open_file executes .exe/.app.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server