What can you do with this server?

The agentic-browser-mcp server provides browser automation capabilities to MCP clients (Codex, Claude, Cursor, etc.) using Playwright and the Chrome DevTools Protocol. Session Management: Start or switch between real mode (connects to an existing logged-in Chrome, preserving cookies/sessions/2FA) or isolated mode (launches an independent profile, optionally headless or incognito). Multiple MCP clients can share a single session, and Chrome is auto-launched if not detected. Navigation: Open any URL in the browser. Page Inspection: Retrieve a snapshot of interactive elements with ARIA roles, accessible names, and stable ref IDs (e.g. [ref=e3] button "Sign in"). Defaults to viewport-only for token efficiency. Clicking & Typing: Interact with elements by ref ID or by role + accessible name. JavaScript Execution: Run arbitrary JS expressions in the page context — read the DOM, access storage, fire network requests, etc. Storage Access: Read cookies, localStorage, or sessionStorage from the current page. Console Logs: Retrieve buffered browser console logs, optionally filtered by level (error, warning, log, info). Human Intervention: Pause automation for manual steps like solving CAPTCHAs or completing logins, returning the current URL and a reason to the user. Screenshots: Capture a PNG screenshot of the current page (full page or viewport). Session Cleanup: Explicitly close the session — disconnects CDP for real mode (without killing Chrome) or terminates the browser for isolated mode. Supports both stdio and http transports for flexible integration.

How do I use agentic-browser-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agentic-browser-mcp Navigate to wikipedia.org and click the first link" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

agentic-browser-mcp

by q35888

Overview Schema Related Servers Score Discussions

JavaScript

Local

agentic-browser-mcp

English | 中文

A standalone MCP server that gives any MCP client (Codex, Claude, Grok, Cursor, …) browser automation on top of Playwright. Drive a real, already-logged-in Chrome through the Chrome DevTools Protocol — share cookies and sessions across agents. The goal: every MCP client you use drives the same browser, with the login state intact.

Features

15 tools: browser_session, browser_navigate, browser_snapshot, browser_click, browser_type, browser_select_option, browser_hover, browser_tabs, browser_handle_dialog, browser_eval, browser_storage, browser_console, browser_wait_human, browser_screenshot, browser_close
Two session modes:
- real — connectOverCDP to an existing Chrome on port 9222 (reuse your logged-in profile: cookies, sessions, 2FA)
- isolated — launchPersistentContext with an independent profile (headed/headless)
Auto-launch Chrome: if port 9222 is down, the server spawns your Chrome starter script and waits for it — no manual browser launch needed.
Element Ref targeting (Cursor-style): snapshot numbers every interactive element with a stable ref (e1, e2, …) and returns lines like - [ref=e3] button "Sign in"; click/type target by ref for precision, or fall back to role + name. It pierces open shadow roots, maps native tags to implicit ARIA roles (<a>→link, <select>→combobox, …), and filters out hidden elements via checkVisibility() + non-zero size. Default returns only in-viewport elements (mode=all for everything) — big token savings on complex pages.
Transports: stdio (default, for Codex-style spawn) and http (stateless streamable, --transport http --port 9223).

Related MCP server: mcp-browser

Requirements

Node.js ≥ 18
Playwright-compatible Chrome/Chromium installed (google-chrome-stable works)
For real mode: a Chrome instance running with --remote-debugging-port=9222 and a dedicated user-data-dir (see Start Chrome with CDP)

Path configuration (env vars)

All paths go through env vars with defaults that fall back to the Pi env layout. To deploy on a different device/path, set one or more env vars:

Env var	Default	Purpose
`AGENT_BROWSER_DIR`	`~/.pi/agent`	Root dir; other paths derive from this
`AGENT_BROWSER_CHROME_STARTER`	`<AGENT_BROWSER_DIR>/start-agent-chrome.sh`	Chrome launch script
`AGENT_BROWSER_CDP_PROFILE`	`<AGENT_BROWSER_DIR>/chrome-cdp-profile`	CDP-mode profile dir
`AGENT_BROWSER_ISOLATED_PROFILE`	`<AGENT_BROWSER_DIR>/bw-mcp-profile`	Isolated-mode profile dir
`AGENT_BROWSER_LOG_FILE`	`os.tmpdir()/agentic-browser-mcp-chrome.log`	Chrome startup log
`AGENT_BROWSER_CDP_PORT`	`9222`	Chrome DevTools Protocol port
`AGENT_BROWSER_ISOLATED_CHANNEL`	unset	`chrome` makes isolated mode use the system Chrome instead of Playwright's bundled chromium. Caution on macOS: a headless system Chrome registers as "Chrome is running" and blocks your daily Chrome from launching via the Dock (fixed by default)

Override examples:

# Change only the root (others follow)
AGENT_BROWSER_DIR=/data/my-agent node index.mjs

# Fine-grained control
AGENT_BROWSER_CHROME_STARTER=/opt/chrome/launch.sh \
AGENT_BROWSER_CDP_PROFILE=/opt/chrome/profiles/logged-in \
node index.mjs

All paths in error messages and tool descriptions are dynamic — no hardcoded ~/.pi/agent.

Install

git clone https://github.com/q35888/agentic-browser-mcp.git
cd agentic-browser-mcp
npm install
npx playwright install chromium   # only needed for isolated mode (~95MB); skip if you only use real mode

Configure your MCP client

Codex (`~/.codex/config.toml`)

[mcp_servers.agentic-browser]
type = "stdio"
command = "/usr/bin/node"
args = [ "/path/to/agentic-browser-mcp/index.mjs" ]

Any MCP client (stdio)

Spawn node /path/to/agentic-browser-mcp/index.mjs over stdio — standard MCP initialize → tools/list → tools/call.

HTTP mode (long-running single instance)

node index.mjs --transport http --port 9223
# POST MCP requests to http://127.0.0.1:9223/mcp

Start Chrome with CDP (for `real` mode)

Chrome 150+ requires a non-default user-data-dir for remote debugging. Example starter script:

#!/usr/bin/env bash
# ⚠️ Profile path is controlled by AGENT_BROWSER_CDP_PROFILE (default: $HOME/.pi/agent/chrome-cdp-profile).
# No logins? Run sync-profile.sh once to copy them from your daily Chrome.
# Check if a profile has a site's login:
#    strings <profile>/Default/Cookies | grep -i <domain>   # hits = cookies present
PROFILE="$HOME/.agentic-browser-chrome-profile"
mkdir -p "$PROFILE"
# Fill in graphics session env if spawning from a non-graphical context
export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}"
export WAYLAND_DISPLAY="${WAYLAND_DISPLAY:-wayland-0}"
exec google-chrome-stable \
  --remote-debugging-port=9222 \
  --user-data-dir="$PROFILE" \
  --ozone-platform=wayland \
  "$@"

--ozone-platform=wayland is important when Chrome is spawned from a background process: otherwise Chrome's platform heuristic picks X11 and fails with Missing X server / Authorization required. Adjust for your display server (X11 users: drop the flag and ensure DISPLAY/XAUTHORITY are set).

If you don't start Chrome manually, the server auto-launches: first tries the AGENT_BROWSER_CHROME_STARTER script (default $HOME/.pi/agent/start-agent-chrome.sh); if absent, falls back to a builtin direct spawn (cross-platform chrome lookup, zero external deps). To customize, set AGENT_BROWSER_CHROME_STARTER to your own script.

Chrome 136+ silently ignores --remote-debugging-port on the default profile (security hardening against infostealers), so the dedicated Chrome must use a separate user-data-dir and starts with no logins. To make it carry all the logins from your daily Chrome (Gmail, GitHub, internal SaaS, …), run the sync script:

# With the dedicated Chrome stopped (and daily Chrome idle or closed):
./scripts/sync-profile.sh

It copies Cookies / Login Data / Web Data / Local State from your default profile into the dedicated one — on Linux, the GNOME keyring key is shared per-user, so encrypted cookies decrypt transparently. Re-run it whenever you log in to a new site in your daily Chrome. See docs/agent-guide.md, section "Reuse your daily logins", for details.

Tools

Tool	Description
`browser_session`	Start/switch a session (`real` / `isolated`, `headless`, `incognito`). No args = ensure default `real`.
`browser_navigate`	Opens a URL. Passing `profile` explicitly only reconnects CDP when profile differs from current session (passing the default `"real"` no longer triggers a needless reconnect).
`browser_snapshot`	Lists interactive elements with `ref` ids. Default `mode=viewport` (only in-viewport, saves tokens); `mode=all` returns all. `refreshActivePage` runs before every tool call — newly opened tabs (`<a target="_blank"`> / `window.open()`) are automatically followed.
`browser_click`	Click by `ref` (preferred, e.g. `e3`) or `role` (+`name`). `ref` is validated (`^e\d+$`) and checked for exactly one match (0=stale, >1=duplicate → re-snapshot).
`browser_type`	Fill an input by `ref` (preferred) or `role` (+`name`). Same ref validation as `click`.
`browser_select_option`	Pick a `<select>` option by `ref` (preferred) or `role` (+`name`); `values` is a string/array, or `{label}`/`{value}`/`{index}`. No JS needed.
`browser_hover`	Hover an element by `ref` (preferred) or `role` (+`name`) to trigger hover menus/tooltips.
`browser_tabs`	Manage tabs: `list` / `switch` (by `index`) / `close` / `new` (optional `url`). An explicit `switch` sticks until a new tab opens.
`browser_handle_dialog`	Handle JS dialogs (alert/confirm/prompt). Call before the triggering action with `accept`/`dismiss`/`promptText`; `reset` restores default.
`browser_eval`	Run a JS expression in the page (read DOM/storage/fire requests).
`browser_storage`	Read `cookies` / `localStorage` / `sessionStorage`.
`browser_console`	Reads buffered console logs (optional `level` filter). Listener is bound on `context.on("page")`, so console logs from newly opened tabs are also collected.
`browser_wait_human`	For CAPTCHAs/manual steps — returns a prompt; the calling agent pauses and waits for the user.
`browser_screenshot`	Save a PNG to disk.
`browser_close`	Close the current session (`real` only disconnects CDP, never kills your Chrome).

Element targeting (ref)

Every browser_snapshot injects a script that scans the page for interactive elements (links, buttons, inputs, [role]s, [contenteditable], [tabindex], …) and pierces open shadow roots. Each surviving element gets a short ref id (e1, e2, …) via a data-agent-ref attribute. The returned text looks like:

- [ref=e1] link "Docs"
- [ref=e2] searchbox "Search"
- [ref=e3] button "Sign in"

Visibility & viewport filtering

An element is included only if it passes both checks:

Visible — el.checkVisibility({ checkOpacity, checkVisibilityCSS, contentVisibilityAuto }) (falling back to computed visibility !== 'hidden' on old browsers) and a non-zero bounding rect. This filters display:none, visibility:hidden, opacity:0, 0×0, and parent-hidden elements — the old offsetParent check missed these (e.g. DuckDuckGo's hidden <input type=radio opacity:0 rect=0×0> that broke fill).
In viewport (default mode=viewport) — rect intersects the viewport. Pass mode=all to include off-screen elements too. On a complex page this cuts the snapshot from ~150 elements to ~10, saving ~90% tokens.

Role mapping

Native tags are mapped to their implicit ARIA role so the output matches what Playwright's getByRole() expects for the fallback path: <a href>→link, <button>/<summary>→button, <textarea>/text <input>→textbox, <input type=search>→searchbox, checkbox/radio, <select>→combobox. Explicit role= attributes always win.

Using refs

click   { ref: "e3" }                         # precise — the exact element snapshotted
click   { role: "button", name: "Sign in" }   # fallback when you have no ref
type    { ref: "e2", text: "playwright" }

ref is validated against ^e\d+$ and the locator is checked for exactly one match: 0 → "stale ref, re-snapshot"; >1 → "duplicate ref, re-snapshot" (a snapshot-internal error).

Refs are ephemeral. Each snapshot renumbers elements from scratch (clearing old data-agent-ref attrs, including inside shadow roots), so a ref is only valid until the next snapshot. If the page changes (navigation, dynamic content), re-run snapshot before acting. Output is truncated on whole-line boundaries with a …[共 N 项，返回 M 项] summary.

Notes

📌 Multi-tab behavior — Every tool call runs refreshActivePage(s) first. By default it follows the last-created tab, so:

✅ click <a target="_blank">, window.open(), browser_navigate opening a new tab → subsequent operations auto-follow the new tab
✅ browser_tabs (list/switch/close/new) for explicit control — an explicit switch sticks (pinned) until a new tab appears, then auto-follow resumes
❌ Manual tab switching in Chrome UI is NOT tracked (Playwright CDP exposes no stable "focused tab" API)
❌ browser_tabs close refuses the last tab (would force a session rebuild) — use browser_close to end the session

📖 Helping a user set up this MCP? Read docs/agent-guide.md — environment discovery, install, per-client config (Codex/Claude Desktop/Cursor), Chrome setup, verification, and common pitfalls.

🆚 How does this compare to the official @playwright/mcp? See docs/vs-playwright-mcp.md — same Playwright underneath, different trade-offs (login-state reuse, token-efficient snapshots, auto-launched Chrome, Chinese-first tool descriptions).

browser_wait_human: this server has no GUI/TUI. It returns a text prompt; the client agent is expected to surface it and wait for the user to reply.
Session sharing: multiple MCP clients connecting to the same server share one Playwright session (and thus one Chrome). Tool calls are serialized to prevent races.
Resource cleanup: on stdin EOF, transport close, or SIGINT/SIGTERM, the server disposes the session (with a 3s timeout fallback) — isolated browsers won't be orphaned.

Troubleshooting

ECONNREFUSED 127.0.0.1:9222 / Chrome not running — In real mode the server probes 9222 via node:http.get /json/version (agent:false explicitly bypasses http_proxy/https_proxy, avoiding false "port closed" when your proxy would intercept the localhost probe). Probing TCP alone is not enough — Chrome startup order is TCP first → then DevTools HTTP → then /json/version responds; checking only TCP causes a race (TCP up but connectOverCDP immediately throws). So it waits for /json/version 200. If closed, it calls spawnStarter(): tries the AGENT_BROWSER_CHROME_STARTER script first (if it exists); otherwise builtin-direct-spawns chrome — cross-platform executable lookup (Linux /usr/bin/google-chrome-stable etc, Windows Program Files, macOS /Applications/Google Chrome.app), using detached:true + --remote-debugging-port=${CDP_PORT} + --user-data-dir=${CDP_PROFILE}. Polls for up to 20s. If auto-start still fails, launch Chrome manually.
Daily Chrome won't open from the Dock (macOS) — older versions launched headless isolated sessions with the system Chrome (channel:'chrome'); macOS Launch Services tracks apps by bundle, so the invisible instance registered as "Google Chrome (running)" and Dock clicks merely activated it (no window ever appears). Fixed: isolated mode now defaults to Playwright's bundled chromium (separate bundle id, no clash). AGENT_BROWSER_ISOLATED_CHANNEL=chrome switches back — use with care in headless macOS scenarios.
Browser context management is not supported (connectOverCDP fails) — two causes with the same symptom: 1) Chrome launched with --no-sandbox (the builtin spawn used to force it on all non-Windows platforms — fixed: now auto-added on Linux only, AGENT_BROWSER_NO_SANDBOX=1 forces it); 2) windowless zombie Chrome — after the user closes every window the Chrome process stays alive (common on macOS); /json/version still returns 200 but /json/list is empty. The server now self-heals: on connect failure it PUT /json/new to open one tab and retries; if that fails too, restart Chrome manually.
fill: Timeout … element is not visible — You likely clicked/typed a hidden element (e.g. a 0×0/opacity:0 decorative control). Re-run snapshot; the visibility filter should now exclude it. If a genuinely visible element still fails, its ref may be stale — re-snapshot.
ref=eN 未命中 (stale ref) — The page changed since the last snapshot (navigation, dynamic content, element removed/re-rendered). Re-run snapshot and use the new ref.
ref=eN 命中 N 个 (duplicate ref) — A snapshot-internal error (refs should be unique). Re-snapshot; if it persists, file an issue.
Snapshot too noisy / too many elements — You're probably on mode=all. The default is mode=viewport (in-viewport only). Scroll then re-snapshot, or stay on the default.
Does browser_close() kill my real Chrome? — No. Under connectOverCDP, browser.close() only drops the CDP connection; the real Chrome process and its tabs survive (verified). It's safe to call.
CSS is not defined — (Fixed in newer versions.) The Node-side tool handler must not use browser globals like CSS/document; only code inside page.evaluate() runs in the browser.

License

MIT

Available Tools

11 tools

browser_clickA

点击页面元素,用 snapshot 里的 role(+name) 定位。

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	元素的可访问名称(accessible name)
`role`	Yes	元素 role,见 snapshot 输出(如 link/button/textbox)

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It explains the locator mechanism but does not disclose behaviors like waiting, page transitions, or click outcomes. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with action and method. No wasted words. Ideal for fast agent parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema. Description explains input but not what happens after click (e.g., page change, return value). For a simple click, this may be sufficient, but some agents might need more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage, and the description adds context that role comes from snapshot output and name is accessible name. This adds value beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('click page element') and how to locate it using role and name from a snapshot. This distinguishes it from sibling tools like browser_type (typing) and browser_navigate (navigation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by referencing snapshot output for role and name. It doesn't explicitly state when not to use or alternatives, but the guidance is clear for this simple action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_closeA

显式关闭当前浏览器会话,释放资源(real 断开 CDP 连接,不关真实 Chrome;isolated 关闭浏览器进程)。下次工具调用会自动重建。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently describes two modes of closing (real vs isolated) and their effects (CDP disconnection, process closure), and notes automatic reconnection. This is sufficient for a close action, though some details about error cases or resource implications could enhance transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences that front-load the primary action. Every sentence is necessary and informative, with no wasted words. The structure efficiently conveys the core functionality and key nuances.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and lacks annotations, the description provides sufficient context by explaining the different closing behaviors and the automatic session rebuilding. It covers the main aspects but could be slightly more complete by mentioning any potential side effects on data or state. Overall, it is well-suited for the tool's simple nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and the schema description coverage is 100%. The description does not need to add parameter semantics, and it provides context about the closing behavior that is valuable beyond the schema. Baseline for 0 parameters is 4, and the description meets this standard.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool closes the current browser session and releases resources, distinguishing between 'real' (disconnects CDP but doesn't close real Chrome) and 'isolated' (closes browser process) cases. This is a specific verb+resource pair that effectively separates it from sibling tools like browser_navigate or browser_click.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that the next tool call will automatically rebuild the session, providing implicit guidance on when to use the tool (when done with the session). However, it does not explicitly state when not to use it or mention alternative tools for related actions, lacking clear usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_consoleA

读取累积的 console 日志(F12 Console)。可选 level 过滤。会话启动起开始记录。

ParametersJSON Schema

Name	Required	Description	Default
`level`	No

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states logs are accumulated since session start and supports optional level filtering, but lacks details on side effects, size limits, or whether logs are cleared after reading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences efficiently convey the tool's purpose and key feature (optional level filter) without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one optional parameter and no required fields, the description covers the essential: it reads logs from session start with optional filter. Missing output format or persistence details, but adequate for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'level' is defined in schema with enum values; description adds that filtering is optional, which adds context. However, it does not explain the meaning of each level value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool reads accumulated console logs from browser's F12 Console, with optional level filtering and recording from session start. It is distinct from sibling tools like browser_screenshot or browser_eval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving console logs, but provides no explicit guidance on when to use it versus alternatives (e.g., browser_eval for executing JS), nor any when-not scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_evalA

在页面执行 JS 表达式(=F12 控制台输入,如 document.title / JSON.stringify({...}) / 1+1 / location.href),返回结果。传表达式,不是箭头函数。可读 DOM/storage/发请求。

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	要执行的 JS 表达式/语句

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full disclosure burden. It transparently notes that the tool can read DOM, storage, and send requests, which hints at side effects. However, it does not explicitly state that evaluation can modify page state or cause side effects beyond those mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with examples and a key caveat. Every phrase adds value, no wasted words, and critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool does and its capabilities, but lacks details on the return format (type, serialization) and error handling. Given no output schema, this omission reduces completeness for an arbitrary-JS-execution tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a brief parameter description. The tool description adds meaningful context: examples of valid expressions, warning against arrow functions, and scope (read DOM/storage/requests), which goes beyond the schema's 'JS expression/statement'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool executes JS expressions on the page and returns the result, with specific examples (e.g., document.title, 1+1). It distinguishes from arrow functions and lists capabilities (read DOM/storage/send requests), differentiating it from sibling tools like browser_click or browser_navigate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates use for evaluating JS, but lacks explicit guidance on when to use this tool versus alternatives (e.g., browser_snapshot for page state). It warns against arrow functions but does not specify when not to use it or provide context for preferred scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_navigateC

打开 URL。可顺便切会话(未指定 profile 则用当前/默认 real)。

ParametersJSON Schema

Name	Required	Description
`url`	Yes	要打开的 URL
`profile`	No
`headless`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses session switching and default profile, but does not mention behavior like page load waiting, timeouts, errors, or return values. Critical for a navigation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no redundant words. However, could be more structured with bullet points or separate sentences for clearer front-loading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. Missing details on return values, error handling, and navigation behavior make it incomplete for reliable agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 33% (only url described). The description adds meaning for 'profile' by explaining default behavior, but 'headless' is not addressed. Adds some value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool opens a URL and can switch sessions. It distinguishes from siblings (e.g., browser_click, browser_type) by the action of navigation, but could be more explicit about what 'navigate' entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs. alternatives. The mention of session switching gives a hint, but there is no when-not or comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_screenshotB

截图存为文件(配角:非多模态模型不解读,主要给人看)。默认存 ~/.pi/agent/bw-shots/。

ParametersJSON Schema

Name	Required	Description	Default
`fullPage`	No	是否整页截图

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It mentions the default save path but does not disclose whether the tool is read-only, destructive, or any side effects (e.g., overwriting files, affecting browser state). This is insufficient for a file-saving operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loading the core function. The parenthetical adds context but is somewhat redundant for an AI agent. No unnecessary words, but could be more streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, no output schema), the description covers the primary function and default location. However, it lacks details on the output format, error cases, or behavior with/without the fullPage parameter, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters (only one boolean), and the schema description already explains the parameter's meaning. The tool description adds no extra semantic value beyond the schema, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool takes a screenshot and saves it as a file, with a default path. It distinguishes itself by noting it is for human viewing, not for multimodal models. However, it does not explicitly specify whether it captures the current viewport or the entire page (though the parameter hints at full page).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for human consumption, not for AI interpretation, which provides some guidance. However, it does not explicitly state when to use this tool over siblings like browser_snapshot or browser_eval, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_sessionA

切换/启动浏览器会话。profile: real(连专用 profile Chrome,已登录态) | isolated(独立 profile);headless 仅 isolated 生效;incognito 临时无痕。不传参数=确保默认 real 会话。

ParametersJSON Schema

Name	Required	Description	Default
`profile`	No
`headless`	No
`incognito`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that headless only works with isolated, incognito is temporary, and default is real session. However, it does not cover side effects, permissions, or session lifecycle.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences) and front-loaded with the main purpose. Each sentence adds meaningful detail without redundancy. However, the dense Chinese phrasing may be slightly harder to parse programmatically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and the complexity of session management, the description is moderately complete. It covers core parameters and default behavior, but misses return values, error handling, and session persistence details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions in schema), so the description must compensate. It explains the meaning of profile (real vs isolated), headless (only valid with isolated), and incognito (temporary). This adds significant value beyond the raw schema enums.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: switching/starting a browser session with different profile types. It distinguishes from sibling action tools (click, navigate, etc.). However, it could be more explicit about the difference between 'switch' and 'start'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use each profile type (real vs isolated) and conditions like headless only for isolated. But it lacks explicit instructions on when not to use this tool or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_snapshotA

返回页面 ARIA 无障碍树(YAML 文本,带 role+name)。据此调 click/type 时提供 role+name。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. States it returns YAML text but does not disclose potential errors, performance considerations, or limitations (e.g., tree availability on all pages). Moderate transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no extraneous information. Purpose is front-loaded. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no parameters, description covers essential aspects: return type and usage guidance. Missing error handling or edge cases, but sufficient for standard use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so baseline is 4. Description adds value by explaining return format and purpose, which is sufficient for zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns the ARIA accessibility tree in YAML format with role and name attributes. Explicitly links to usage with click/type tools, distinguishing it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage before click/type actions by stating 'use this to provide role+name'. Lacks explicit when-not-to-use or alternatives, but context from sibling tools makes it clear this is the only tree retrieval tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_storageB

读取存储(F12 Application)。type: cookies|localStorage|sessionStorage。

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	读 cookies 时限定 URL
`type`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must fully disclose behavior. It states 'read storage' but lacks details on side effects, permissions, or data scope (e.g., current page only?). This is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short sentences, no redundant information, and the key information (action and type) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description fails to explain return values, error cases, or behavior for each storage type. For a simple read tool, more context is needed for safe usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%; the description lists the enum values for 'type' (cookies, localStorage, sessionStorage) which adds clarity. However, the optional 'url' parameter is not explained in the description (only in schema), and no additional semantics beyond enumeration are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('读取存储' meaning 'read storage') and specifies the resource type via an enum (cookies, localStorage, sessionStorage). It uniquely identifies the tool among sibling browser action tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The sibling tools are all different actions, so no direct competition, but the description provides no context for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_typeC

在输入框(role 通常 textbox)输入文本,用 role+name 定位。

ParametersJSON Schema

Name	Required	Description
`name`	No	输入框的可访问名称
`role`	Yes	元素 role(通常 textbox/searchbox/combobox)
`text`	Yes	要输入的文本

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavior. It does not mention if typing clears existing text, triggers events, or waits for element readiness. Minimal beyond the bare action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Front-loaded with the key action. Could be slightly expanded without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple type action with 3 parameters and no output schema, the description covers the basics but lacks details on prerequisites (e.g., page loaded) or edge cases (e.g., disabled input). Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides; it merely restates that location is by role+name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'type' and the resource 'input box', with a specific location strategy (role+name). It distinguishes from sibling tools like browser_click and browser_eval, but could be more explicit about the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., browser_click for non-text inputs, browser_eval for custom scripts). Missing preconditions or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_wait_humanA

遇到验证码/登录等需人工操作时调用。MCP server 无 GUI,本工具返回当前页面 URL 和需要人工操作的说明;调用方(Codex 等)应在终端暂停,提示用户去浏览器手动操作,完成后回复继续。

ParametersJSON Schema

Name	Required	Description	Default
`reason`	Yes	需要人工做什么(如:过验证码)

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description fully explains behavior: returns current URL and instructions, caller must pause and wait. Could mention timeout but not essential for a simple human-wait tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise (two short sentences), front-loaded with the trigger condition. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (one param, no output schema), the description is complete: trigger, behavior, and caller response are all covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema provides 100% coverage for the single 'reason' parameter with a clear description. The tool description adds context about why the parameter is needed but no additional semantic detail beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool is for waiting on human operation when encountering CAPTCHA/login. It distinguishes itself from sibling browser automation tools (e.g., click, navigate) by ceding control to the user.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to call (when human operation required) and what the caller should do (pause terminal, prompt user, wait for reply). Does not explicitly state when not to use, but context makes it clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.1.0Jul 15, 2026
- First observedbrowser_click
- First observedbrowser_close
- First observedbrowser_console
- First observedbrowser_eval
- First observedbrowser_navigate
- First observedbrowser_screenshot
- First observedbrowser_session
- First observedbrowser_snapshot
- First observedbrowser_storage
- First observedbrowser_type
- First observedbrowser_wait_human

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action or data source (click, type, navigate, eval, etc.), with no overlapping purposes. Descriptions clearly differentiate between similar actions like clicking vs. typing and reading console vs. storage.

Naming Consistency4/5

All tools use the 'browser_' prefix and snake_case, with most following a verb pattern (click, type, navigate). The tool 'browser_session' uses a noun instead of a verb, which is a minor inconsistency but still predictable.

Tool Count5/5

With 11 tools, the set covers all core browser automation tasks without unnecessary redundancy. The count is well-scoped for a comprehensive yet focused server.

Completeness4/5

The tool set covers primary browser interactions: navigation, clicking, typing, reading console/storage/eval, screenshots, session management, and manual intervention. Missing features like back/forward navigation or alert handling are minor gaps but do not severely hinder typical workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

browser-mcp
io.github.Shreyas-Profile
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
Browser Automation Web Scraping
2
Tap
io.github.LeonTing1010
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Browser Automation Web Scraping
217
Aginx Browser A
net.aginx
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Browser Automation Agent Orchestration
23114
WebRun Browser Automation A
ai.webrun
Run multi-step tasks in a real Chrome browser: persistent environments, live view, human takeover.
Browser Automation Web Scraping
211

Related MCP Servers

Playwright MCP
Browser Automation Agent Orchestration
misanthropic-ai
F
license
B
quality
D
maintenance
Playwright wrapper for MCP that enables LLM-powered clients to control a browser for automation tasks.
Updated a year ago (2025-03-13 05:35 UTC)
10
1
-
mcp-browser
Browser Automation Web Scraping
souhailmerroun-recyclebin
F
license
Not graded
quality
D
maintenance
Exposes Playwright browser automation as MCP tools, enabling AI assistants to control a real browser tab-by-tab for form filling, navigation, and more, while preserving the user's active session.
Updated 3 months ago (2026-06-03 22:05 UTC)
-
monkeysee
Browser Automation Web Scraping
juliocesar
A
license
Not graded
quality
B
maintenance
Enables MCP clients to drive a real, logged-in Chrome browser for web automation tasks like navigation, clicking, typing, and screenshotting.
Updated 2 months ago (2026-07-01 21:24 UTC)
10
1
MIT
mcp-browser-automation
Browser Automation Web Scraping
ritesh-jain
F
license
B
quality
B
maintenance
An MCP server for generic browser automation using Playwright. Enables MCP clients to navigate pages, inspect elements, execute JavaScript, capture screenshots, and monitor console logs and network traffic via a headless Chromium instance.
Updated 2 months ago (2026-06-24 18:28 UTC)
7
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/q35888/agentic-browser-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

agentic-browser-mcp

Features

Requirements

Path configuration (env vars)

Install

Configure your MCP client

Codex (~/.codex/config.toml)

Any MCP client (stdio)

HTTP mode (long-running single instance)

Start Chrome with CDP (for real mode)

Reusing your daily browser's login state

Tools

Element targeting (ref)

Visibility & viewport filtering

Role mapping

Using refs

Notes

Troubleshooting

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Codex (`~/.codex/config.toml`)

Start Chrome with CDP (for `real` mode)