VisionCLI
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": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lookA | Take a screenshot of what the user is looking at and return it as an image. By default captures the window under the mouse pointer (or, if that is the terminal, the front-most other window). Use target "screen" for the whole display the mouse is on. Optionally pick a window by app name/title or window id, or a display number. |
| list_windowsA | List on-screen app windows (front-most first) with ids, app names and titles. Use before |
| select_regionA | Show the native crosshair so the user can drag a rectangle around the exact part of the screen they mean (press Space to pick a window instead, Esc to cancel). Blocks until they finish. Tell the user to make the selection. |
| clipboard_imageB | Return the image currently on the user's clipboard (e.g. a screenshot taken with Cmd+Ctrl+Shift+4). |
| device_screenshotA | Full-resolution screenshot of the booted iOS Simulator (platform ios) or a connected Android device/emulator (platform android), without window chrome. Use it to explain or debug app UI, then find the view in code. |
| db_schemaA | Tables, columns and foreign keys of the project's database (connection read from the project's .env: Laravel DB_* or DATABASE_URL; MySQL, Postgres, SQLite). Pass a table to narrow it. Read-only. |
| db_queryA | Run one SELECT/SHOW/DESCRIBE/EXPLAIN/WITH query against the project's database inside a read-only transaction. Results are capped at 50 rows; use LIMIT. |
| browser_tabsA | Open tabs in the front-most Brave/Chrome (ids like t1.3 = window 1, tab 3), marking the active one. |
| browser_openA | Open a URL in Chrome/Brave. Always use this (never ⌘L/⌘T + typing) to go to a page: it switches to a tab already showing it, otherwise reuses your own working tab, and only opens one new tab the first time. new_tab: false loads it in the user's current tab. |
| browser_switch_tabB | Bring a tab (id from browser_tabs) to the front. |
| browser_navigateC | Navigate the active tab. |
| browser_readA | Title, URL, selected text and readable text of the active tab (capped). Faster and more exact than a screenshot. |
| browser_elementsA | Visible links, buttons, fields, dropdowns (with options) and toggles (with on/off state) on the active page, with ids (e1, e2, …) for browser_click / browser_type / browser_select. |
| browser_clickB | Click an element by id from browser_elements (or by its visible text). |
| browser_typeB | Set the value of a form field (id from browser_elements), optionally submitting the form. |
| browser_selectA | Pick an option in a dropdown (native or custom combobox/menu) by its visible text. Use this instead of browser_click for dropdowns. Toggles/switches/checkboxes: use browser_click (browser_elements shows their on/off state). |
| browser_hoverA | Hover over an element (id from browser_elements) to show what appears on hover: menus, captions, tooltips. Then call browser_elements to see and click what appeared. |
| browser_dragA | Drag an element onto another (ids from browser_elements, which lists draggables, or visible text): sorting lists, boards, upload drop zones, sliders built from divs. Returns the target's text afterwards. |
| browser_fillA | Fill several fields of a form in one call (ids from browser_elements): text fields get the text, dropdowns (native, custom or searchable) pick the option by its text, checkboxes/radios/switches are set on (true) or off (false). Much faster than one call per field. Each field reports its result; submit with browser_click afterwards. |
| browser_scrollC | Scroll the active page. |
| browser_taskA | Hand a multi-step task on the web page in front of the user's Chrome/Brave to VisionCLI's Jev agent: fill in a form, search this site and open a result, set filters, pick options, add to a cart. It clicks, types and selects in a few seconds (about 0.4 s a step). Put every value to type in the goal: it only types text that's in the goal. Returns each step and where it ended; check the result with browser_read if needed. Open the right page first (browser_open). |
| ui_elementsA | List the buttons, fields, menus, links, tabs and text of the front app's focused window (or a named app) via Accessibility, each with an id and its center in screen points. Use the id with click/type_text: it's far more reliable than pixel guessing. |
| clickA | Click on the screen: by |
| type_textA | Type text with the keyboard into the focused field, or into |
| press_keysA | Press a key or shortcut (not for browser navigation: use browser_open/browser_navigate), e.g. "enter", "cmd+s", "cmd+shift+p", "tab", "esc", "down". Several separated by spaces run in order: "cmd+a delete". |
| scrollB | Scroll at x/y (default: where the mouse is). dy negative = down, positive = up (lines); dx for sideways. |
| dragB | Drag with the left mouse button from (x1,y1) to (x2,y2): move files, select text, resize, reorder. |
| open_appA | Open an app, or bring it to the front if it's running, e.g. "Xcode", "Slack", "Simulator", "Android Studio", "Figma". |
| open_urlB | Open a link or file URL with its default app (browser, Figma, Slack deep links, vscode://, etc.). |
| announceA | Show a short update in VisionCLI's bubble and say it out loud, e.g. when background work you promised to report on has finished ("The v0.7.6 release is live."). One or two short spoken sentences, plain text, no markdown. |
| start_voiceA | Launch the voice overlay for this project: the user holds Option (Option+Command with a screenshot), asks a question out loud, and the answer appears in a bubble above their mouse pointer. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| see | Capture what you're looking at and ask about it |
| point | Drag a box around something on screen and ask about it |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 31 tools
Descriptions do distinguish the browser_* family (web pages) from the unprefixed desktop tools, which helps, but there are many near-duplicate pairs: browser_click/click, browser_type/type_text, browser_scroll/scroll, browser_drag/drag, and browser_elements/ui_elements. browser_task also overlaps nearly every other browser tool, so an agent must read carefully to avoid misselection.
All names use snake_case, but conventions are mixed: browser_* tools are consistent, while desktop tools swap between noun-only (look), verb (click, scroll, drag), and verb_noun (type_text, press_keys, open_app, open_url). The browser_ prefix scoping is a plus, yet the unprefixed half isn't predictable.
31 tools exceeds the comfortable 15-tool band and sits in the 'heavy' range, but the server genuinely spans browser automation, native app control, database inspection, and device screenshots, so most tools earn their place. A few (e.g. the browser_task meta-tool plus individual browser actions) feel redundant rather than strictly necessary.
The surface covers a broad lifecycle: page discovery, click/type/select/drag/scroll, tab and navigation control, plus desktop input and app launching, with db read and device screenshots. Gaps are minor (db is read-only, no explicit browser_close/tab management beyond switch), and agents can work around them.