shotbox
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_sessionA | Start a sealed session: a display of its own (X11 under Xvfb, or Wayland under a headless sway), its own D-Bus and accessibility bus, and a scratch home. Nothing in it reaches the desktop of the person you're working for, and nothing of theirs reaches it. Start one, spawn a program in it, then look with accessible_tree (cheap, text) before screenshot (pixels). It lasts until stop_session, or until this server stops. |
| stop_sessionA | Stop a session: every program in it ends, unsaved work and all, and its scratch directory goes. With usage, it says their peak memory and CPU time. |
| spawnA | Start one of the programs the person allowed this server to run, by its name, in a session; nothing else can run. Then wait_for its window before looking at it. If it doesn't come up, program_output says why. |
| program_outputB | Whether a spawned program is still running, and the end of what it printed: for a window that never came up, or a crash. |
| accessible_treeA | What a screen reader would find: every visible node, a line each, indented, with its role, name, description and the states a screen reader says (focusable, focused, checked...). The cheapest way to see what's on screen and what can be clicked by name. A node with an empty name ("") is one a screen reader can say nothing for. Use screenshot for how it looks. |
| screenshotA | A picture of the screen, or of one window, RETURNED AS AN IMAGE for you to look at: the only way to see colors, layout and what's drawn. Pictures cost far more than the accessible tree; take the window rather than the screen, and crop when you need a part. vision checks nothing is told apart by color alone; burst, as one image in rows of four, is for motion, an animation or a transition. |
| recordA | Record a clip of the screen, or of one window, and save it as an .mp4: in the session's scratch directory, gone when the session stops, or at path. The answer is the saved path, how long the clip is, and up to 8 frames from it RETURNED AS ONE IMAGE in rows of four, with the times they show: you can't play the clip, but a person or another tool can. A clip stops at 100 MB. sound also says what it heard, as the sound tool does. until_line ends it at an event instead; the answer gives the line. For a few moments of motion, screenshot's burst is cheaper. |
| clickA | Click a node by its name, or a point by x and y, on the screen or inside a window. By name is the one to use: it waits up to timeout seconds for the node, raises its window and clicks its middle. When two nodes match it lists them, with where they are; when none does, the nearest names. A click gives a window the keyboard, which nothing else does on X11. hold and state, by x and y, hold the button as press_keys holds keys. |
| scrollA | Turn the mouse wheel over a node by its name, found as click finds it, or at a point by x and y. For what's past a list's, a page's or a window's edge; then wait_for stable and look again. |
| press_keysA | Press keys in turn, each a chord: Tab, Return, Escape, ctrl+s, alt+shift+Tab, F6. They go to whatever has the keyboard; click a window first if nothing does. hold presses them all together and keeps them down that long (walking while running); state down leaves them down, across calls, until a call with state up (move or click while a key is held). |
| gamepadA | Work a virtual gamepad, in a session started with gamepads: press buttons together, tapped, held for hold seconds, or with state down left down until a call with state up; push a stick to x, y; pull a trigger to value; or neutral, letting go of everything. A stick or trigger stays where it's put, unless hold says for how long. Programs in the session see a real Xbox 360 controller, and none of the machine's. |
| type_textA | Type text into whatever has the keyboard focus, a key at a time. ASCII only: a character with no key fails the call, once what's before it is typed. |
| wait_forA | Wait, instead of sleeping, for: a window (value: its title, exactly or a regex, or app=RE), stable (the screen, or the window, unchanged for value seconds, 0.5, up to 60: after a click, for the repaint), an announcement (value: a regex in what was announced to a screen reader; each announcement is waited for once), focus (value: the name of the node with the keyboard focus, as click takes one), match (value: a PNG, by its path from the allow file's directory, that the screen, or the window, cropped to crop, should look like), change (from how it looked when the wait started), or line (value: a regex found in a line of file, written after the wait starts, or with from_start, anywhere in it: for a program that logs its events, rather than a sleep; a file not there yet is waited for, and one rotated or rewritten is read from the top). match and change say how long they took; line answers with the line. Fails after timeout seconds, saying so. |
| lintA | Nodes a screen reader has no name to say for: controls, images (not inside a named control) and anything else that takes the focus. A line each: the node, as accessible_tree has it, then what's wrong. |
| contrastA | Contrast measured on the screen, in each node's bounds: text, buttons and links against their background, images, and with edges, a button's or field's edge against what's round it; large text needs 3. A line each, the node as accessible_tree has it with its bounds, then the colors; then what wasn't measured, which doesn't fail (too small, or GTK 4's, whose positions are wrong), and why. Switches, sliders, check boxes and what's disabled are left out, and so is what's scrolled out of view. |
| tab_walkB | Press a key until the keyboard focus comes back round, and say where it went each time: the Tab order. It ends in a cycle (fine), a trap (a press that leaves the focus where it was), or after most presses. A text view that takes Tab is left with ctrl+Tab, shift+Tab, Escape or F6, Tab not pressed there; the controls Tab never reached are said. Leaves the focus where it ends. |
| announcementsB | Everything programs have announced to a screen reader in the session, a line each, "polite: Saved": GTK's announcements, a browser's live regions. |
| soundA | Record what plays in a session started with audio: action start, then do what makes the sound, then action stop, which says what it heard: its length, peak and RMS (dBFS), samples clipped, and each gap of exact silence between the first sound and the last, as a program that falls behind leaves; then what's wrong, if anything (gaps, clipping, silence). Sounds meant to be apart, two beeps say, need a gap longer than the silence between them. |
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 18 tools
Most tools have distinct purposes (session lifecycle vs. input vs. inspection vs. audio/gamepad). However, accessible_tree, lint, contrast, and tab_walk all inspect UI but overlap in outputting node information, and screenshot/record/sound overlap in capturing media. Descriptions help but boundaries are not always crisp.
Mixed conventions: snake_case verbs like type_text, start_session, wait_for, press_keys, tab_walk, accessible_tree sit alongside bare nouns like spawn, screenshot, announcements, sound, gamepad, click, scroll, lint, contrast, record. Readable but not a predictable pattern.
18 tools is borderline heavy for a UI-automation server and several specialized tools (gamepad, sound, record, contrast, lint, tab_walk) dilute the core surface. Each earns some place, but the count feels overgrown relative to essential capabilities.
Strong lifecycle coverage: session start/stop, program spawn/output, inspection (tree, screenshot, announcements), input (click, scroll, keys), and specialized capture/audit tools. Missing explicit window management (resize, move, close) and clipboard operations, but agents can work around most gaps.