dsh-cua
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| tool_list_windowsA | List all visible top-level windows with title, hwnd, PID, position and size, sorted largest first. Read-only — safe while the user works. |
| tool_find_windowA | Find a window by title substring and return its hwnd and geometry. Read-only. |
| tool_capture_windowA | Capture a window screenshot and SAVE IT TO A FILE. Provide hwnd or title substring. Crops to the window's CLIENT area by default, so image pixel (0,0) is the same point click_at calls (0,0) — no frame offset to guess. Returns bounds = the screen rect (x,y,width,height) the image maps to, plus |
| tool_send_keysA | Send keyboard shortcut to a window. Example: keys=['ctrl','s']. For Alt+key menu navigation, include 'alt' as first key (or set use_alt_key). MUTATING: serialized across agent sessions via the admission gate, and global hotkeys additionally YIELD TO THE USER — recent mouse/keyboard activity makes them wait, then refuse with reason user-active instead of interrupting; switch to element actions or retry later. Also refuses when the window is not the foreground window, because injected keys would go to the wrong window. |
| tool_click_atA | Click at client-area coordinates within a window. Coordinates relative to window content area (0,0 = top-left). Tries the ELEMENT path first (resolve the point via UI Automation and invoke that element) because it needs no focus and does not care about z-order; falls back to a raw cursor click, which does. The result's |
| tool_element_actionA | Perform an action on a UI element by the |
| tool_type_textA | Type a text string into a window character-by-character (window-targeted PostMessage, not global keystrokes). The text control inside the window is resolved automatically — a top-level window does not forward WM_CHAR to its child edit, so passing a window handle alone used to post into nothing — and the control's text is read back so |
| tool_get_window_rectC | Get detailed position and size info for a window: absolute position, dimensions, and client area size. Read-only. |
| tool_element_at_pointA | Identify the UI element at a PHYSICAL screen point via Windows UI Automation. Returns its name, role, rect, and which actions it supports, plus an opaque |
| tool_read_elementA | Re-read a UI element by the |
| tool_skyshotA | Read a window's UI as a compact TEXT tree instead of a screenshot — far cheaper than an image, and it names elements a hit-test cannot reach (e.g. an input inside a Chromium page, which element_at_point reports only as the enclosing 'document'). Each line is '{index} {indent}{role} {name}{Value: ...}{(state)}'. Every shot after the first is a DIFF against the previous one: unchanged lines are omitted, ' |
| tool_element_action_atA | Act on the element that line |
| tool_find_elementsA | Find UI elements by role and/or name substring and return refs that can be acted on with element_action. This is how you reach an element that cannot be hit-tested — the point of naming it is that you no longer need a pixel. |
| tool_coexistence_statusA | Report the coexistence policy in force: whether the admission gate is enabled, the quiet/max-wait/mutex-timeout tunables, the pre-injection final-check window, named-mutex health, and how long ago the last physical input happened. Read-only — call it when an action was refused with user-active or arbiter-busy and you want the numbers behind the refusal. |
| tool_clipboard_readA | Read the current clipboard text. Read-only. Non-text clipboard content reports empty text rather than failing. |
| tool_clipboard_writeA | Replace the clipboard contents with text. MUTATING (soft): serialized across agent sessions — and it DESTROYS whatever the user last copied, so do not use it casually; announce it when you do. |
| tool_open_applicationA | Open a file, folder, or URI with the shell's default handler — like double-clicking it in Explorer: an .exe path, a document, or a URL. MUTATING (soft): serialized across agent sessions; the launched app may take focus. |
| tool_list_displaysA | List monitors: index (1-based), primary flag, device name, and the monitor plus work-area rectangles in physical pixels. Read-only. |
| tool_cursor_positionA | Current cursor position plus the screen size, both physical pixels. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Several tools overlap in purpose: element_action (by ref) vs element_action_at (by skyshot index) perform virtually the same UI Automation action through different handles, and click_at, type_text, and element_action(set_value) can all deliver input to a control. The very detailed descriptions do help tell them apart (ref vs index, soft vs physical input), so an agent can navigate it, but the boundaries are not clean.
Every name is prefixed with tool_ and uses snake_case, giving a predictable surface. Most follow verb_noun (type_text, capture_window, list_windows), though a cluster of element/clipboard tools is noun-first (element_action, element_at_point, clipboard_read), a minor deviation rather than a real inconsistency.
19 tools is on the heavy side but splits cleanly across a broad domain (windows, elements, input, displays, clipboard, app launch, coexistence). Each entry maps to a distinct capability, so the count is justified despite being near the upper comfortable range.
Coverage of the desktop-automation lifecycle is strong: window/element discovery, tree-based and coordinate-based acting, keyboard, text typing, screenshots, clipboard, displays, and app launching are all present. Gaps are minor (no drag-and-drop, explicit scroll-wheel, or window move/resize/close), which agents can largely work around.