Skip to main content
Glama
zhaolibins001-svg

Smart Browser MCP

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BROWSER_PATHNo浏览器可执行文件路径自动探测 Chrome / Edge
BROWSER_CDP_PORTNoChrome DevTools Protocol 调试端口9222
BROWSER_USER_DATA_DIRNo浏览器用户数据目录(保留登录态)D:\Projects\AIchrome-profile

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_openC

Open website

browser_textB

Get page text

browser_snapshotB

Get page structure (title/url/button texts/inputs)

browser_analyze_pageA

Analyze current page and return structured information: title, url, text, inputs, buttons, links, menus and recent console errors. Use this instead of screenshot when you only need to understand the page.

browser_extract_site_mapA

Extract the navigation menu / link structure of the current system. Returns text/href pairs useful for building a site map or feature map.

browser_elementsA

List visible clickable elements and inputs. Each gets a short ref (e1, e2...) usable in browser_click/browser_fill/browser_select/browser_hover — prefer ref over raw selector or text to avoid ambiguity.

browser_mark_screenshotA

Screenshot the viewport with numbered boxes drawn over interactive elements (Set-of-Mark). Returns the image plus number/ref -> selector mapping. Then use browser_click with the ref (e.g. e3).

browser_observeA

Layered observation — use the cheapest level that suffices. level 0: lightweight status (url/title/error count/captcha flag, ~50 tokens). level 1: interactive elements with refs (same as browser_elements). level 2: annotated screenshot (same as browser_mark_screenshot).

browser_clickA

Click element. Prefer 'ref' (from browser_elements/browser_mark_screenshot), then 'selector', then 'text'. Returns what changed after the click.

browser_fillB

Fill input. Prefer 'ref' (from browser_elements), then 'selector', then 'placeholder'.

browser_pressA

Press a keyboard key, e.g. Enter, Escape, Tab, ArrowDown, Control+a. Useful for submitting forms or closing dialogs.

browser_scrollB

Scroll the page to load lazy content.

browser_selectA

Select an option in a dropdown by value or visible label.

browser_hoverC

Hover over an element to trigger hover menus.

browser_tabsA

List all browser tabs (index, title, url, active).

browser_switch_tabA

Switch to a tab by index (from browser_tabs).

browser_new_tabB

Open a new tab, optionally with a URL.

browser_wait_humanA

Wait for the user to manually solve a CAPTCHA / human-verification widget in the browser. Polls until the widget disappears or timeout (default 120s). Always tell the user you are waiting before calling this.

browser_screenshotC

Save viewport screenshot in current project (JPEG, 10s timeout, with fallback)

browser_set_viewportB

Set browser viewport size. Recommended: 1440x900.

browser_errorsB

Get browser errors

browser_clear_errorsA

Clear collected browser errors

browser_auto_testC

Run browser test steps and save screenshots/errors. click/fill steps accept ref (from browser_observe), selector, or text/placeholder. For repeated flows prefer browser_flow_record/browser_flow_run.

browser_flow_recordA

Record browser actions into a named reusable flow. mode=start begins recording (open/click/fill/press/scroll are captured with selectors); mode=stop saves the flow to disk for later replay with browser_flow_run.

browser_flow_runA

Replay a recorded flow by name (from browser_flow_record).

browser_flow_listA

List recorded flows.

browser_rememberA

Save current refs under a semantic page name for later reuse. Refs are resolved to durable selectors (+ backups) before saving, so they survive page reloads. Example: {name: "loginPage", refs: {username: "e1", password: "e2", submit: "e3"}}. Recall later with browser_recall.

browser_recallB

Load a saved page element map (from browser_remember) and register fresh refs for it, skipping re-observation. Returns key -> new ref mapping plus any elements whose selector no longer exists on the page.

browser_memory_listB

List saved page element memories.

browser_forgetB

Delete a saved page element memory.

api_set_envA

Set base URL and/or default headers used by all subsequent api_request / api_assert / api_test_suite calls. Merges with existing env unless replace=true. Typical use: set baseUrl once at the start of a session, e.g. {baseUrl: "https://localhost:5001"}.

api_loginA

Call a login endpoint, extract a token from the JSON response via tokenPath (dot path, e.g. "data.token"), and store it into defaultHeaders for all subsequent api_request/api_assert calls. Fails loudly if the token path is not found.

api_requestA

Send a single HTTP request to a web API (relative URLs resolve against the baseUrl set by api_set_env) and return status, headers and body. Use this for one-off exploration; use api_assert when you also want pass/fail checks.

api_assertA

Send a request and assert on it: expectStatus (exact status code), expectFields (dot-path -> expected value, e.g. {"data.total": 10}), expectBodyContains (substring match on raw response text). Returns a clear pass/fail report; failures are also recorded and retrievable via api_errors.

api_test_suiteA

Run a list of API test cases (same shape as api_assert's inputs) in sequence and return an aggregated pass/fail report. Pass save=true with a name to persist the case list to disk for later replay via api_suite_run.

api_suite_runA

Replay a previously saved API test suite by name (from api_test_suite with save=true).

api_suite_listA

List saved API test suites.

api_errorsC

List recent API errors (network failures, HTTP 4xx/5xx, failed assertions).

api_clear_errorsA

Clear the recorded API error list.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 39 tools

Disambiguation4/5

Most tools have clearly distinct purposes, but there is some overlap among browser_snapshot, browser_analyze_page, browser_observe, browser_elements, and browser_mark_screenshot. The descriptions clarify when to use each, so an agent can disambiguate, but the boundaries are not perfectly crisp.

Naming Consistency5/5

All tools follow a consistent pattern of either 'browser_' or 'api_' prefix followed by snake_case action or noun (e.g., browser_click, api_assert). The naming is uniform and predictable across the entire set, making it easy to infer functionality.

Tool Count2/5

With 39 tools, the server is significantly over the typical 3-15 range. Even considering the broad scope of covering both browser automation and API testing, the count feels excessive and likely introduces redundancy (e.g., multiple observation and snapshot tools). This may overwhelm agents and complicate tool selection.

Completeness5/5

The toolset covers browser automation comprehensively: navigation, interaction, observation, screenshots, tabs, flows, memory, error handling, and human verification. API testing is also thorough, with request, assertion, suite management, and error tracking. There are no obvious critical gaps for the stated dual purpose.

Maintenance

ActivityNo data
ResponsivenessNo issues