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. WebSockets appear as WS entries with their frame counts. 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. For a WebSocket entry, any part returns its frame stream.

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.

browser_list_toolsA

Lists tools beyond this server's own that can run against the session's page, by qualified name: "webmcp." for tools the site itself publishes through WebMCP (read live — they change as the page navigates), and "devtools." for chrome-devtools-mcp's tools (performance traces, Lighthouse, emulation, heap snapshots…), which this server runs for you — no extra MCP server to configure. Follow with browser_tool_schema, then browser_call_tool.

browser_tool_schemaA

Full description and JSON input schema of a tool from browser_list_tools, e.g. "webmcp.search" or "devtools.performance_start_trace".

browser_call_toolA

Runs a tool from browser_list_tools against the session's page, with arguments matching its browser_tool_schema. WebMCP tools are code the site supplies: their output is the site's word, and one marked CONSEQUENTIAL can take real actions (orders, payments, messages).

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

A3.8/5.0

Scored across 26 tools

Disambiguation4/5

Most tools have clearly distinct purposes: interaction (click/type/hover/press_key/select_option), navigation, and session management are unambiguous. The main soft overlap is among the page-reading tools (browser_snapshot, browser_query, browser_read_text, browser_inspect_element, browser_screenshot), but the descriptions explicitly explain when to prefer each, so misselection risk is low.

Naming Consistency4/5

Nearly all tools use a browser_ prefix with snake_case, which is highly predictable. Slight deviation: some are verb-first (browser_navigate, browser_click) while others are noun-first (browser_console, browser_network, browser_snapshot), and run_task drops the prefix, but the style is coherent overall.

Tool Count3/5

At 26 tools the surface is on the heavy side, but browser automation is a genuinely broad domain spanning sessions, interaction, inspection, network, dialogs, and delegation. Few tools feel redundant, though the count is borderline rather than tightly scoped.

Completeness5/5

The surface covers the full automation lifecycle: session start/list/close, navigation and history, element interaction, form filling, dialog handling, waiting, accessibility/text/visual inspection, JS evaluation, console and network diagnostics, plus a meta-tool layer and a delegated run_task agent. No obvious dead ends for typical UI testing.

Maintenance

ActivityMaintained
ResponsivenessNo issues