Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
D1_API_KEYNoBearer API key when `D1_PROVIDER=api`
D1_MONITORNoMSS monitor index for desktop screen capture1
D1_PROVIDERNoDecision provider: `ollama`, `local` (Transformers), or `api`local
D1_MODEL_NAMENoModel identifier for Ollama (`d1:3b`) or Hugging Face / API (`LiquidAI/d1-3B`)d1:3b
D1_REAL_MOUSENoAlways move the real physical OS mouse cursor during visible browser actions (`false` to disable, `always` to force even in headless)true
D1_API_BASE_URLNoBase URL for `/v1/systemone` when `D1_PROVIDER=api`
D1_IMAGE_MAX_SIDENoMax image dimension sent to D1 (`0` disables downscaling)768
D1_MOUSE_DURATIONNoDefault duration (in seconds) of the human-like minimum-jerk pointer trajectory0.04
D1_BROWSER_CDP_URLNoOptional CDP endpoint (e.g. `http://localhost:9222`) to attach to an existing browser
D1_OLLAMA_BASE_URLNoOllama server base URLhttp://localhost:11434
D1_TIMEOUT_SECONDSNoProvider HTTP timeout in seconds60
D1_BROWSER_HEADLESSNo`false` for visible browser window, `true` for headlessfalse
D1_BROWSER_PAGE_URLNoExact tab URL to select when CDP exposes multiple tabs
D1_BROWSER_STRATEGYNo`hybrid` (fast DOM + D1 fallback) or `vision` (always D1)hybrid
D1_DESKTOP_STRATEGYNo`hybrid` (native OS accessibility + D1 fallback) or `vision`hybrid
D1_OLLAMA_KEEP_ALIVENoKeeps the model warm in memory between tool calls10m
D1_CONFIDENCE_THRESHOLDNoMinimum confidence required to authorize a click0.65

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
browser_openA

Open a URL; returns title, readiness, input labels and a short page preview. Returns popup details when one is present: inspect/resolve it with handle_popup using the user's requested choice. If ready is true, skip wait_until_ready. Use the returned field label in smart_type; a preview may reveal an interstitial instead of the requested page.

smart_clickB

Click a uniquely named visible DOM target immediately; otherwise use D1 vision. Duplicate names are ambiguous. Reports method and UI change.

smart_typeA

Fill a visible editable input, replacing old text; verify its exact value before optional Enter. Quote its accessible label from browser_open for a fast precise match. Check status and typed_verified before claiming success.

scroll_until_visibleA

Scroll in steps until visual P(visible) reaches 0.80. Browser scroll is scoped to an active popup if present; prefer browser_scroll for deterministic scrolling without inference.

visual_assertB

Evaluate up to 64 visual questions in one model call. answer=null means uncertain, not confirmation. Prefer DOM field labels and typed_verified for typing; avoid repeated visual assertions for an already verified action.

wait_until_readyA

Wait for DOM readiness in hybrid mode, or visually in vision mode. Skip this call when browser_open returned ready=true. Readiness does not confirm task success or rule out a captcha.

handle_popupA

Inspect a popup or explicitly accept/reject/dismiss it. Never assumes consent. Handles consent iframes and scrolls terms to unlock disabled buttons. Use the user's requested choice; reject never falls back to accept. popup_closed confirms closure; action_sent means do not repeat blindly.

browser_scrollB

Scroll without visual inference. auto scrolls an active popup or its terms panel; otherwise the page. Returns moved and at_end. Use container=popup to prevent scrolling the underlying page.

mouse_moveA

Move without clicking. desktop moves the real OS pointer using global screen pixels; browser moves the tab's mouse using viewport pixels and syncs the real OS pointer on visible browsers. Prefer smart_move when only a target description is known.

mouse_clickA

Click the real desktop pointer, optionally moving to global screen coordinates first. Browser mode requires x/y in the controlled tab viewport and moves the real OS pointer first. Use smart_click for semantic targets and handle_popup for an explicit consent choice.

smart_moveA

Locate a described target and move/hover without clicking. Desktop mode uses a unique accessible control or D1 vision and the real OS pointer; browser mode uses DOM or D1 and moves both the tab mouse and the real OS pointer. Low confidence or a stale target prevents movement.

mouse_dragB

Move the pointer to (start_x, start_y), hold the mouse button, drag smoothly to (end_x, end_y), and release. Ideal for Paint tools, sliders, selections, and drag-and-drop.

desktop_inspectA

Read-only platform requirements, accessible controls, and detected drawing canvas of the foreground app. Use exact labels in smart_click/type for the fast path; unavailable accessibility falls back to D1 vision.

draw_pathA

Draw on a canvas by dragging the left mouse button. Accepts a single polyline [[x,y],...] or multiple strokes [[[x,y],...],...] (lifts the brush between strokes). Auto-detects the Paint/browser canvas sheet if canvas_bounds is omitted.

draw_shapeB

Draw a shape (line, rectangle, ellipse, circle, triangle, diamond, star, arrow, heart, house, spiral, wave) by dragging the mouse on the sheet. Auto-detects canvas_bounds and centers the shape on the canvas if coordinates are omitted.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 15 tools

Disambiguation3/5

Several tool families intentionally overlap: smart_click vs mouse_click, smart_move vs mouse_move, browser_scroll vs scroll_until_visible, and mouse_drag vs draw_path vs draw_shape. The descriptions do provide explicit tie-breakers (semantic target vs raw coordinates, deterministic vs visual inference), but the agent must reason about more than one or two confusable pairs before choosing.

Naming Consistency4/5

All names are snake_case and mostly verb_noun or prefix_noun (browser_open, mouse_drag, handle_popup, draw_shape). Minor deviation is the 'smart_' adjective prefix family (smart_click/smart_type/smart_move) and the outlier scroll_until_visible, but the pattern remains readable and predictable.

Tool Count4/5

15 tools is within a healthy range for a browser+desktop automation agent, and each tool maps to a real primitive (open, click, type, scroll, wait, popup, draw). A few could be consolidated (dual smart_/mouse_ pointer pairs, three drag/draw tools), making it slightly heavy but not bloated.

Completeness3/5

Core browse-and-manipulate loop is covered, but notable gaps exist: no general key-press/shortcut tool, no back/forward/tab navigation, no page text/content extraction beyond a short preview, and no desktop-app typing (smart_type is scoped to visible editable browser inputs). These omissions will force agents into workarounds on non-trivial tasks.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues