Provides tools to check whether Arc Browser is running with a visible window and to navigate it to an absolute HTTP or HTTPS URL.
Click on "Deploy 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., "@arc-browser-mcp Is Arc open? If so, go to https://example.com"
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.
A local stdio MCP server that lets OpenCode navigate the Arc Browser already running on Windows from WSL2. It targets Arc directly, even when another browser is the Windows default.
Tools: arc_browser_status checks for an open Arc window. arc_navigate opens an absolute HTTP(S) URL in Arc.
Windows 10 or 11 with the packaged Arc Browser installed for the signed-in user
WSL2 with Windows interop enabled
Node.js 20 or newer and npm
OpenCode V2
Arc open with a visible window when the tools are called
This project does not use CDP, an extension, browser debugging ports, hosted APIs, or third-party browser services. It is not an npm-published package. Install it from this repository.
Related MCP server: Integrated Browser MCP
git clone https://github.com/xpajonx/arc-browser-mcp.git
cd arc-browser-mcp
npm ci
npm run build
npm test
npm run eval
git config core.hooksPath .githooksOpenCode reads the project-local opencode.json when you start it from this checkout. Confirm the MCP server is connected:
opencode mcp listTo make the server available in every OpenCode project instead, register the absolute path from the checkout root:
opencode mcp add arc-browser --global -- node "$(pwd)/dist/src/index.js"
opencode mcp listThe global command writes to your OpenCode user config. The project-local config does not change global settings.
Open Arc in Windows and keep a window visible.
In OpenCode, call arc_browser_status. It should return available: true.
Call arc_navigate with a URL, for example https://example.com.
The tool reports the hostname and action: "navigated". Windows may use the current tab or open another tab. The tool does not promise tab placement or confirm page rendering.
See the step-by-step user guide for setup details and troubleshooting. See architecture notes for design and verification details.
Only absolute HTTP and HTTPS URLs are accepted.
URLs with credentials, control characters, or more than 2,048 characters are rejected.
The MCP server does not read tab URLs, titles, page contents, cookies, browser history, or profile files.
Navigation uses your existing Arc profile. The destination receives requests and cookies as it would during normal browsing.
The structured audit line records only the hostname, action, result, and timestamp. It omits the URL path and query.
A navigation can change the active browser page. Review the destination before calling the tool.
npm test # TypeScript build and local gate tests
npm run eval # Offline URL-safety evalThe live smoke test makes Arc load a temporary local page and can change its current tab. Run it only when that is acceptable:
npm run test:liveThe live test starts an HTTP server on loopback, calls the MCP tool, and passes only if Arc requests that local page. It makes no external network request. CI runs only the offline gate and eval.
MIT. See LICENSE.
Check whether a visible Windows Arc Browser window is available. Does not read tab titles, URLs, or page contents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| available | Yes | |
| visibleWindows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: it targets a visible Windows window and explicitly excludes reading page content, which clarifies what the operation will and will not do.
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 with no filler. The core purpose is front-loaded)Skip leading sentence; the exclusion of content reading is a valuable clarifying detail.
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 no-parameter, read-only status check with an output schema and strong annotations, the description is complete. It tells the agent exactly what is checked and what is not inspected.
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 tool has zero parameters and the schema is empty, so there is nothing for the description to add. The baseline of 4 for no-parameter tools 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?
Clearly states a specific verb ('Check') and resource ('visible Windows Arc Browser window'), and explicitly delimits scope by saying it does not read tab titles, URLs, or page contents. This makes its purpose distinct from the sibling arc_navigate.
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 makes the usage context obvious: call this to verify Arc Browser availability without inspecting content. It does not explicitly name arc_navigate as an alternative or state 'use before navigating,' but the status-vs-navigation distinction is clear enough.
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.
v0.1.0arc_browser_statusarc_navigateScored across 2 tools
The two tools have clearly distinct purposes: one checks browser availability, and the other performs navigation. There is no overlap or ambiguity between them.
Both tools use the arc_ prefix and snake_case style. arc_navigate is an action verb while arc_browser_status is noun-style, so the pattern is mostly consistent but not perfectly uniform.
Two tools is minimal and only covers availability checking plus navigation. For a browser-related MCP this feels slightly thin, though the narrow scope keeps it from being unreasonable.
The core status-then-navigate workflow is present, but the server lacks any way to read tabs, URLs, or page content. This leaves notable gaps for agent workflows that need to inspect browser state.
Check whether a URL can be opened. No browser is launched.
Check whether a URL can be opened. No browser is launched.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Real Chrome for agents: start a browser, read pages as numbered markdown, click, type, hand off.