hypruse
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HYPRUSE_MAX_IMAGE_BYTES | No | Maximum image size in bytes (e.g., 1048576 for 1 MB). Screenshots will degrade resolution to fit. | 1048576 |
| HYPRUSE_SCREENSHOT_MODE | No | Screenshot output mode: 'path' (default) writes PNG file and returns path, 'image' returns inline image data. | path |
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 |
|---|---|
| desktopA | Semantic desktop snapshot: monitors, workspaces, windows (address,
class, title, |
| screenshotA | Capture the focused monitor, a window ( |
| zoomA | Native-resolution re-capture around a point: the precision step of
the coarse-to-fine loop. Screenshot first, estimate the target's global
x,y, zoom there, re-estimate on the zoomed image (scale ~1.0, so
global = geometry[:2] + image_pixel), then click. |
| uiA | Read a window's accessibility tree (AT-SPI) and return its elements
with GLOBAL click points, so you can target a control by NAME with no
screenshot and no pixel guessing. |
| marksA | Set-of-Marks capture: a screenshot of the window WITH its accessible
controls drawn as numbered red marks, plus a JSON legend mapping each
number to the control's role, name, current value, and exact global
click point. One glance replaces the estimate-zoom-estimate loop for
every control the accessibility tree knows: read the number off the
image and call |
| bindsA | The user's own Hyprland keybinds: combo, action, arg, and a
description when the config provides one. This is how the desktop's
owner drives it: to perform one of these workflows, call |
| wait_forA | Block until a desktop event happens (real compositor events, not
polling). event: 'window_open' | 'window_close' | 'workspace' |
'title_change' | 'layer_open' | 'layer_close' (layer-shell surfaces:
launchers, notification popups; match on the namespace, e.g. 'wofi') |
'urgent' (a window demands attention) | 'screencast' (screen sharing
started/stopped). match: optional case-insensitive substring filter
over the event's fields (class/title/workspace name/address/namespace).
timeout_s 1-60, default 10. Returns the event payload, or a timeout
note; a filtered wait whose condition ALREADY holds (the window is
already gone, the workspace already active, the layer already mapped)
returns instantly with |
| pointerA | Mouse in global coordinates. action='move' (x,y) | 'click' (optional
x,y first; button left/right/middle; double=true) | 'drag' (x,y →
to_x,to_y holding button) | 'scroll' (scroll_dy notches, positive =
content down; optional x,y first). |
| keyboardA | Keyboard to the focused app. action='type' (text, unicode-safe) |
'key' (keys combo: 'ctrl+shift+t', 'esc', 'F5'; aliases
enter/esc/tab/backspace/pgup/pgdn/arrows, else XKB keysyms). Pass
|
| click_uiA | Click a control by its accessible NAME, or by a |
| hyprA | Window/workspace ops over IPC (instant, no vision).
action='workspace' (workspace: number/name/'special:name') |
'focus_window' (target: address) | 'move_window' (target + workspace,
silent) | 'close_window' (target) | 'fullscreen' (target?) |
'toggle_floating' (target?). |
| launchA | Run |
| use_bindA | Run one of the user's own Hyprland keybinds by its combo (from the
|
| sequenceA | Run an ordered list of actions in ONE call, so a click/type/enter
micro-sequence costs one round-trip instead of several. Each step is
{"op": "pointer"|"keyboard"|"click_ui"|"hypr"|"wait_for", ...that tool's
args}, e.g. [{"op":"pointer","action":"click","x":800,"y":60},
{"op":"keyboard","action":"type","text":"hello","window":"0x.."},
{"op":"keyboard","action":"key","keys":"enter"}]. With stop_on_change
(default) the run stops, best-effort, when it notices a STRUCTURAL
change between steps that the step did not intend: a window opening
(e.g. a dialog), closing, or moving, a switch to an unexpected
workspace, or a seat-taking layer surface (a launcher or on-screen
keyboard) appearing, so later steps do not act on stale state.
Notification popups and bars are not treated as changes. It does NOT catch
a bare focus change, so to type into a specific window reliably give
that keyboard step a window= address (it focuses first). Bounded to 20
steps and ~30s total. |
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 14 tools
Each tool serves a clearly distinct function: desktop provides semantic state, screenshot/zoom capture visual data, marks/ui expose accessibility info, keyboard/pointer/click_ui handle input, hypr/launch/use_bind execute actions, wait_for listens for events, and sequence orchestrates multi-step workflows. No two tools have overlapping purposes that could cause misselection; even similar tools like marks and ui differ in output format and use case.
All names are lowercase and descriptive, with compound names consistently using underscores (wait_for, click_ui, use_bind). However, the set mixes nouns (desktop, marks, pointer, screenshot) with verbs (launch, wait_for, click_ui), so there's no strict verb_noun pattern, but the inconsistency is minor and doesn't hinder understanding.
14 tools is well-scoped for a desktop automation server, covering state inspection, input, action execution, event waiting, and sequencing. Each tool is necessary and non-redundant, and the count is within the ideal 3-15 range.
The tool surface is comprehensive for desktop automation: it provides state discovery (desktop, ui, binds), input (keyboard, pointer, click_ui), action execution (hypr, launch, use_bind), observation (screenshot, zoom, marks), event handling (wait_for), and multi-step orchestration (sequence). No obvious gaps exist for typical workflows; even edge cases like authentication dialogs are addressed via allow_auth flags.