Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
browser_startA

Opens a new browser session and returns its sessionId. The session (cookies, storage, page state) stays alive across tool calls until closed or idle-timed-out, so you can interact with the same page over many turns.

browser_listA

Lists open browser sessions with their current URL, age, and idle time.

browser_closeA

Closes a browser session and frees its resources.

browser_navigateA

Navigates the session to a URL and returns the new page state plus a fresh snapshot with element refs. Relative URLs resolve against the session baseUrl.

browser_clickA

Clicks an element. Address the element by ref (from the latest browser_snapshot), or by css, or by role+name. Reports any navigation, console errors, or network activity the click triggered.

browser_typeA

Types text into an input or textarea. Address the element by ref (from the latest browser_snapshot), or by css, or by role+name.

browser_press_keyB

Presses a key, optionally focused on an element. Key names follow Playwright ("Enter", "Escape", "ArrowDown", "Control+a").

browser_hoverA

Hovers an element, e.g. to reveal a menu or tooltip. Address the element by ref (from the latest browser_snapshot), or by css, or by role+name.

browser_select_optionA

Selects one or more options in a . Address the element by ref (from the latest browser_snapshot), or by css, or by role+name.

browser_scrollA

Scrolls an element into view, or scrolls the page by a pixel delta when no element is given.

browser_wait_forA

Waits for text to appear, text to disappear, or a selector to become visible. Use after actions that trigger async updates.

browser_go_backB

Navigates back in history and returns the new page state with fresh refs.

browser_handle_dialogA

Answers an alert/confirm/prompt. A dialog blocks the page until it is answered, so an unanswered one is dismissed automatically rather than stalling the action that opened it. Call this BEFORE the action that triggers a dialog to arm the answer — that is the only way to accept one or supply prompt() text. Called while a dialog is open, it answers that dialog immediately.

browser_snapshotA

Returns the accessibility tree of the page as compact YAML, with a [ref=eN] handle on every element. This is the primary way to see the page — use these refs to click and type. Far cheaper than HTML or screenshots. Scope it with ref/css/role, cap it with depth, or page through it with offset when a page is large.

browser_queryA

Finds elements by role+name, visible text, or CSS, and returns a compact line per match including its ref and visible/enabled state. Use this instead of a full snapshot when you already know what you are looking for.

browser_read_textA

Returns the rendered text of the page or of one element subtree — the readable content without markup. Use it to verify copy, read results, or check an error message.

browser_screenshotA

Captures a JPEG of the page or an element. Use this only for genuinely visual questions (layout, styling, rendering); browser_snapshot and browser_read_text are faster and cheaper for finding and verifying content.

browser_consoleA

Returns buffered console messages and uncaught page errors (with stacks). Check this whenever the page misbehaves — it usually names the failure directly.

browser_networkA

Lists network requests the session has made, with status, size, and duration. Each line carries an #id for browser_request_detail. Filter by URL substring or by failure status.

browser_request_detailA

Inspects one request from browser_network: headers, timing breakdown, request body, or response body. Small text responses are cached, so they stay readable after navigation.

browser_evaluateA

Runs JavaScript in the page and returns the JSON-serialized result. Accepts a bare expression ("document.title") or a function ("el => el.value"). When an element is targeted, it is bound to el. Use it to read state the accessibility tree does not expose.

browser_inspect_elementA

DevTools-style inspection of one element: tag, attributes, box model, form state, and computed styles. Use it to diagnose layout and visibility problems.

run_taskA

Delegates a multi-step UI task to a fast built-in browser agent, which drives the session itself and reports back. Use it for goal-shaped work ("log in as demo@example.com and check the dashboard loads", "walk the checkout flow and report anything broken") rather than driving each click yourself.

Returns a structured report: a success flag, a summary, and findings — each with a severity, what is wrong, where, and the evidence observed. Findings come from two places: what the agent noticed, and what the harness itself recorded (console errors, failed requests, dialogs), so problems are reported even when the agent does not mention them or runs out of steps. The session is left on whatever page the agent ended on, so you can inspect it further with the browser_* tools.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 23 tools

Disambiguation5/5

Every tool has a clearly distinct purpose: session management, navigation, interaction primitives, inspection methods, network/console diagnostics, and a delegation agent. Even overlapping ones like snapshot/query/read_text/inspect_element are well-differentiated by their descriptions (full tree vs. targeted search vs. text extraction vs. devtools-style detail).

Naming Consistency5/5

All browser_* tools follow a consistent verb_noun pattern (e.g., browser_click, browser_type, browser_network), and run_task follows the same convention. No mixed styles or unpredictable naming.

Tool Count4/5

23 tools is on the heavier side, but each tool addresses a distinct need for comprehensive browser automation—session, navigation, interaction, waiting, dialogs, inspection, diagnostics, and delegation. It is slightly above the ideal range but justified by the scope of the domain.

Completeness5/5

The tool surface covers the full lifecycle of UI testing: session management, navigation, interaction, asynchronous waits, dialog handling, multiple inspection modes, console/network diagnostics, JavaScript evaluation, and a delegated agent for high-level tasks. No obvious dead ends or missing critical operations.

Maintenance

ActivityMaintained
ResponsivenessNo issues