agent-browser
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_HEALTH_URL | No | URL used for session health checks. | |
| AGENT_BROWSER_OUT | No | Output directory for exported files and health check logs. | out |
| AGENT_CHROME_ARGS | No | Extra Chrome flags. In Docker, Chrome needs AGENT_CHROME_ARGS=--no-sandbox. | |
| AGENT_BROWSER_PORT | No | Port for the Chrome DevTools Protocol (CDP) connection. | 9333 |
| AGENT_BROWSER_PROFILE | No | Path to the Chrome profile used by the agent. | profiles/agent |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| browser_statusA | Is the agent Chrome running, headless or not, and which Google accounts are signed in. |
| browser_startB | Start the long-lived agent Chrome (headless by default) on the agent profile. |
| browser_stopA | Gracefully close the agent Chrome so rotated cookies are written to the profile. |
| login_beginA | Open the Google sign-in page for a human. The agent must never type credentials. With a display: a visible Chrome window. Without one (CLI server): headless, signed in through
|
| login_finishB | Verify the sign-in worked, then restart the agent Chrome headless on the same profile. |
| navigateB | Open a URL in the agent tab. Returns the final URL, title and the start of the page text. |
| page_snapshotB | Visible text plus numbered interactive elements of the agent tab, for click/type_text refs. |
| clickC | Click an element by page_snapshot ref or Playwright selector (css=, text=, role=...). |
| type_textB | Fill a field by ref or selector; submit=True presses Enter. Never use it for passwords. |
| press_keyB | Press a key in the agent tab, e.g. Enter, Escape, PageDown, Control+A. |
| screenshotC | PNG screenshot of the agent tab. |
| evaluateC | Run a JavaScript expression or function in the agent tab; returns the result as JSON. |
| looker_exportA | Export every row of each datasource behind a Looker Studio report to CSV. Only datasources used on the opened page are seen; for multi-page reports call it per page URL. |
| health_checkB | Load a page that needs the Google session and report whether it still works. For a Looker Studio URL it waits for the report's data call. Appends to /session_health.jsonl. |
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 14 tools
Each tool has a distinct role: lifecycle (browser_start/stop/status), auth (login_begin/login_finish/health_check), and page interaction (navigate, page_snapshot, click, type_text, press_key, evaluate, screenshot). Minor overlap exists — health_check essentially performs a navigate plus session validation, browser_status overlaps somewhat with health_check's session reporting, and login_finish restarts Chrome much like browser_start — but descriptions make the intended use of each clear. looker_export is clearly scoped apart from generic page tools.
All names are snake_case, but verb/noun ordering is mixed: verb-first (navigate, click, evaluate, screenshot) alongside noun-first compounds (page_snapshot, looker_export, browser_start, login_begin, health_check). Related families are internally consistent (browser_*, login_*), yet 'page_snapshot' vs 'screenshot' shows inconsistent vocabulary for adjacent concepts. Readable overall, but not a single predictable pattern.
14 tools is well within a sensible range for a browser-automation server and each one covers a genuine capability: lifecycle, auth handoff, navigation, inspection, four interaction primitives, plus one domain-specific export helper. Nothing appears redundant enough to remove.
The core browsing loop (start → navigate → snapshot → click/type/press → screenshot/evaluate → stop) plus human Google sign-in is covered end to end. Gaps are minor: no tab listing/switching or back/forward history, no explicit wait-for-element or hover/select helpers, and no download/upload handling — though press_key and evaluate provide workarounds.