Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@opencode-browser-control Navigate to https://www.wikipedia.org and take a snapshot"
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.
Playwright-powered browser automation MCP server for OpenCode.
Controls Chrome/Edge with ARIA accessibility snapshots and numbered element refs — no CSS selectors, no guessing.
npm install -g playwright-core
npx playwright install chromiumAdd to ~/.config/opencode/opencode.json:
{
"mcp": {
"browser-control": {
"type": "local",
"command": ["npx", "-y", "opencode-browser-control"],
"enabled": true
}
}
}The browser, browser_snapshot, browser_click, and browser_type tools will be available.
Related MCP server: Pilot
browser(action, ...) — Multiplexed ToolAction | Description | Key Params |
| Launch browser |
|
| Close browser | — |
| Open URL |
|
| ARIA snapshot with element refs |
|
| Click element by ref |
|
| Type into input by ref |
|
| Execute JavaScript |
|
| Full-page screenshot |
|
| List all tabs | — |
| Close a tab |
|
| Navigate history | — |
Tool | Description |
| Get ARIA snapshot with |
| Click element by snapshot ref |
| Type into element by snapshot ref |
1. browser(action="navigate", url="https://example.com")
2. browser_snapshot() → returns e1: button "Login", e2: textbox "Email", ...
3. browser_type(ref="e2", text="user@example.com")
4. browser_click(ref="e1")
5. browser_snapshot() → verify resultAuto-detects in priority order:
OS | Priority |
Windows | Edge → Chrome |
macOS | Chrome → Edge |
Linux | Chrome → Edge → Chromium |
Falls back to Playwright's bundled Chromium if no system browser is found.
A persistent profile is stored at ~/.opencode/browser-profile/{browser}/. Login state, cookies, and local storage persist across sessions. The profile is isolated from your normal browser — it won't interfere with your daily browsing.
OpenCode ──MCP(stdio)──▶ index.mjs ──Playwright──▶ Edge/ChromeSingle-file Node.js MCP server. No HTTP middle layer, no browser extensions, no CDP port configuration. Playwright manages the browser lifecycle automatically.
Problem | Solution |
"playwright-core not found" |
|
Browser doesn't launch | Install Chromium: |
SPA navigation breaks refs | Re-run |
Elements not clickable | The snapshot only finds visible elements. Use |
MIT
浏览器控制主工具。通过 action 参数选择操作。首次使用自动启动浏览器。
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 要执行的操作 | |
| url | No | [navigate] 目标 URL | |
| ref | No | [click/type] ARIA 快照中的元素引用，如 e42 | |
| text | No | [type] 要输入的文本 | |
| code | No | [evaluate] 要执行的 JS 代码 | |
| page_id | No | 目标页面 ID，不指定则用当前活跃页面 | |
| headed | No | [start] 是否显示浏览器窗口，默认 true | |
| submit | No | [type] 输入后是否按回车提交 | |
| wait | No | 操作后等待毫秒数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only one behavioral trait disclosed: 'automatically starts browser on first use'. With no annotations, description should provide more behavioral details (e.g., lifecycle, side effects of actions like stop) but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (two sentences) and front-loaded with the main purpose. It is appropriately sized for the level of detail but could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and 12 actions, the description is insufficient. It does not explain return values, list all actions, or provide usage examples. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the schema. Description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's the main browser control tool and that actions are selected via 'action' parameter. However, it does not differentiate from sibling tools like browser_click, which could cause confusion about when to use this tool versus those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description lacks any context about prerequisites, when to choose specific actions, or how to decide between this main tool and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过 ARIA 快照引用（如 e42）点击页面元素。需先调用 browser_snapshot 获取引用。
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | ARIA 快照中的元素引用，如 e42 | |
| page_id | No | 目标页面 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the prerequisite but does not disclose behavioral traits such as success/failure outcomes, navigation waits, or error handling. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the primary action, and the second provides the prerequisite. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 parameters, no output schema), the description is adequate for basic usage. It covers the prerequisite and action. However, lacks details on what happens after the click (e.g., page navigation, errors), which could be important for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage). The description adds no additional meaning beyond the schema, such as explaining the format of the ref or page_id. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks a page element using an ARIA snapshot reference (e.g., e42). It distinguishes from sibling tools like browser_snapshot (for obtaining snapshots) and browser_type (typing), making the specific action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite: 'Must call browser_snapshot first to obtain the reference.' This guides when to use the tool. However, it does not mention when not to use it or provide alternatives, which slightly reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取页面 ARIA 可访问性快照，返回带编号引用（e1, e2...）的交互元素列表。使用 browser_click(ref) 点击这些元素。
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | No | 目标页面 ID，不指定则用当前页面 |
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 explains that the tool returns a list of interactive elements with references, implying a read operation. However, it does not disclose if any state changes occur, authentication needs, or potential side effects. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the main purpose. Every sentence provides value: the first defines the action and output, the second explains how to interact with the output. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description compensates by describing the return format (list with references). It also links to the next step (using browser_click). It covers the essential aspects for usage. However, it could mention error conditions or requirements (e.g., page must be loaded).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'page_id', with a description. The tool description adds the default behavior ('if not specified, use the current page'), which provides extra context beyond the schema. This justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an ARIA accessibility snapshot and returns interactive elements with numbered references. This distinguishes it from siblings like browser_click (clicking) and browser_type (typing). However, it could more explicitly contrast with other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint: after getting the snapshot, use browser_click(ref) to click elements. But it does not specify when to use this tool versus alternatives, nor does it mention scenarios where it should not be used. The guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过 ARIA 快照引用在输入框中输入文本。需先调用 browser_snapshot 获取引用。
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | ARIA 快照中的输入框引用，如 e42 | |
| text | Yes | 要输入的文本 | |
| submit | No | 输入后是否按回车提交 | |
| page_id | No | 目标页面 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses typing behavior and dependency on snapshot, but lacks details on side effects, permissions, or error conditions. Adequate minimally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and prerequisite. With 4 parameters (2 required) and no output schema, description is fairly complete. Could mention submission behavior, but schema covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema; it repeats the same info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (type text), resource (input box), and method (via ARIA snapshot reference). Distinguishes from sibling tools: browser_snapshot is prerequisite, browser_click is clicking, browser is generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite: must call browser_snapshot first to get the reference. Provides clear usage context, though no alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0browserbrowser_clickbrowser_snapshotbrowser_typeEach tool has a clearly distinct purpose: browser for general control, snapshot for getting ARIA references, click for clicking elements, and type for typing text. No overlap in functionality.
All tools use the 'browser_' prefix, providing a consistent pattern. The main tool is simply 'browser', which deviates slightly from the verb_noun pattern but is still clear and predictable.
With 4 tools covering core browser control (navigation, snapshot, click, type), the count is well-scoped and appropriate for the domain.
The tool set covers essential browser interactions, but lacks explicit support for scrolling, keyboard actions, or file handling. Minor gaps that can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
E2LLM gives your AI eyes and hands in a real browser: structured perception (SiFR) plus action.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/FileXego/opencode-browser-control'
If you have feedback or need assistance with the MCP directory API, please join our Discord server