browser-use-relay-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BROWSER_RELAY_URL | Yes | The WebSocket relay URL copied from the browser extension (e.g. ws://127.0.0.1:32145). Can also be provided via the --relay-url command-line flag. | |
| BROWSER_RELAY_ACTION_TIMEOUT_MS | No | Default action timeout in milliseconds. | 60000 |
| BROWSER_RELAY_CONNECT_TIMEOUT_MS | No | WebSocket connection timeout in milliseconds. | 10000 |
| BROWSER_RELAY_ACTION_DELAY_MAX_MS | No | Optional maximum interval between browser actions in milliseconds. | |
| BROWSER_RELAY_ACTION_DELAY_MIN_MS | No | Optional minimum interval between browser actions in milliseconds. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| browser_capabilitiesA | List browser relay actions and runtime availability. The default returns action names, categories, and compact runtime state. Pass only the intended action names or categories for focused metadata; request full detail only when the entire reference is required. |
| browser_snapshotA | Return bounded page state and a sparse, revisioned element catalog without changing the website DOM. Omitted visible/enabled mean true; omitted editable/readonly mean false. Use getBoundingBox when coordinates are needed. |
| browser_queryB | Run a catalog-defined read query. Some browser observations may activate a tab or attach debugger instrumentation. |
| browser_actionC | Execute one revision-aware human browser action through automatic DOM, browser-input, or native routing. |
| browser_batchC | Execute an ordered sequence against one selected browser, stopping on failure by default. |
| browser_eventsB | Read recent relay, navigation, DOM revision, request, download, error, and lifecycle events. |
| browser_upload_filesA | Transfer files or directory contents to the selected browser device, then set the targeted file input. |
| browser_download_fileA | Copy a completed download or other explicitly supplied browser-device file to the MCP client machine with per-chunk integrity checks. |
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 8 tools
Each tool targets a distinct aspect of browser interaction: snapshot for state, capabilities for metadata, query for read operations, action for single operations, batch for sequences, events for history, and upload/download for file transfer. No two tools have overlapping purposes.
All tools share a consistent 'browser_' prefix and use snake_case, but the second part mixes nouns (snapshot, capabilities, action, batch, events) and verbs (query, upload, download). The pattern is predictable enough to be unambiguous, though not as uniform as a strict verb_noun convention.
With 8 tools, the set is well-scoped for browser automation. Each tool covers a necessary function without redundancy, and the count is within the ideal range for a domain-specific server.
The surface covers core browser operations: state observation (snapshot), queries, actions, batch execution, event monitoring, and file transfer. Minor gaps exist such as explicit tab management or waiting, but these are likely handled through browser_action and batch sequences, making the coverage adequate.