Pulse
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PULSE_CDP_PORT | No | Default local Chromium CDP port for browser tools. The default port is 9222. | |
| PULSE_STATE_DIR | No | Choose another directory for Pulse state/data. Defaults to ~/dev/pulse-data when ~/dev exists; otherwise $XDG_STATE_HOME/pulse, or ~/.local/state/pulse. | |
| PULSE_COMPUTER_USE_BIN | No | Specific computer-use-linux binary for the desktop adapter. The desktop adapter otherwise needs computer-use-linux mcp on 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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pulse_map_record_screenC | Record a screen observation with normalized anchors and return its grid. |
| pulse_map_record_transitionC | Record a transition. Only verified transitions are used by route planning. |
| pulse_map_getB | Read a stored screen map, optionally including one screen's full grid. |
| pulse_map_routeC | Find the shortest verified route from a mapped screen to a screen or anchor label. |
| pulse_routine_saveC | Save a successfully verified routine as a reviewable candidate; this does not execute it. |
| pulse_routine_listB | List saved routine candidates, optionally filtered by application. |
| pulse_routine_getB | Read a saved routine candidate by id. |
| pulse_browser_observeB | Observe the active local Chromium page, map visible DOM controls into the spatial grid and store the screen. |
| pulse_browser_targetsA | List the page tabs one CDP port serves and report which one a call would choose. Pass target_url on other browser calls to pin the page under test when a port holds more than one tab. |
| pulse_browser_clickB | Click a mapped browser control only if the current screen still matches the expected map state. Write and irreversible controls require explicit authorization. |
| pulse_browser_fillA | Type a value into one mapped browser field. The value applies to this call only, is never stored or returned, and never submits the form. Requires authorized_effects:["write"]. Password, file, hidden, checkbox, radio, disabled and read-only fields are refused. Set keep_focus when a fill is followed by pulse_browser_key, because a fill drops focus by default to keep the value out of the map. |
| pulse_browser_scrollC | Scroll the current browser viewport by a bounded pixel delta and map the resulting screen. The scroll acts only on the viewport of the expected mapped screen. |
| pulse_browser_keyB | Send one allowlisted key, enter or escape, to the focused element on the expected screen. Enter submits the form that holds the focused field. Requires authorized_effects:["write"]. |
| pulse_browser_replayB | Execute a previously verified route in one browser call. Each step checks its expected screen and stops on divergence. A completed route returns the final screen_id, title, viewport, anchor_count, anchors and screenshot_sha256, so no confirmation observe is needed. Write and irreversible effects require explicit authorization. |
| pulse_desktop_observeC | Capture the active Linux desktop through computer-use-linux, map accessibility controls to a normalized screen grid, and use OCR for anchors when accessibility bounds are missing. |
| pulse_desktop_clickA | Click an anchored desktop control only when the live desktop still matches the expected mapped screen. Write effects require explicit authorization. |
| pulse_desktop_replayB | Execute a verified desktop route in one call. Each step checks the expected mapped screen and stops on divergence. Write effects require explicit authorization. |
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 17 tools
The four domain prefixes (map, browser, desktop, routine) plus action suffixes make most tools clearly separable: browser_click vs desktop_click vs map_get vs map_route are all obviously different operations. The main soft spots are pulse_browser_observe vs pulse_map_record_screen (both capture a screen into the grid, differing mainly in source and side effects) and pulse_browser_replay vs pulse_map_route, which an agent could confuse as plan-vs-execute.
Every tool follows a pulse_<domain>_<action> pattern with a stable set of domain prefixes, which makes grouping predictable. The only deviation is argument ordering inside the name (map_get/record_screen are noun-then-verb while browser_observe/desktop_click are verb-only), but this is minor and readable.
17 tools is slightly above the comfortable range but justified by the four distinct sub-surfaces (mapping, browser, desktop, routines), each of which earns two to seven tools. Nothing appears gratuitous, though the map and routine groups are thin enough that some consolidation might be possible.
The browser surface is rich (observe, targets, click, fill, key, scroll, replay) but the desktop surface only offers observe/click/replay with no direct fill, key, or scroll primitive, and map/routine groups lack listing of screens and any delete/update for saved routines or transitions. These gaps force agents to work around missing operations or rely entirely on replay for desktop input.