What can you do with this server?

This server lets you control a real Chromium-based browser (Edge, Chrome, Brave, etc.) on Windows using native OS-level input — no CDP, browser extensions, DOM manipulation, or JavaScript injection required. Core Tools * browser_observe: Launch a new browser or attach to an existing one, optionally navigate to a URL, and capture a native screenshot of the browser window or file dialog. * browser_act: Execute a single native input action using a valid observation token from a prior browser_observe call. Supported actions include: * Mouse: click (left/right/middle/double), modifier click (e.g. Ctrl+Click), context click, move, drag, scroll * Keyboard: type text (optionally slowly or with Enter submit), press a key, press key combos (e.g. Ctrl+C), hold/release individual keys * File dialogs: provide a file path to fill a native file upload dialog * browser_status: Retrieve current state — transport type, native driver status, browser process info, window handle (HWND), monitor, DPI, focus state, and observation token validity. * browser_stop: Release any held mouse buttons or keys, and optionally close the managed browser window. Key Characteristics * Windows-only; supports Chromium-based browsers (Edge, Chrome, Brave, Chromium, Vivaldi, Opera, Yandex) * Uses hardware-level input via the node-interception driver * Available over stdio or HTTP (SSE/Streamable HTTP) transports * Includes a Ctrl+F12 force-stop hotkey as a safety watchdog

Which integrations are available for this server?

Allows controlling a real Chromium browser (Brave) via native Windows input and accessibility, enabling mouse and keyboard actions, page observation, and status monitoring. Allows controlling a real Chromium browser (Opera) via native Windows input and accessibility, enabling mouse and keyboard actions, page observation, and status monitoring. Allows controlling a real Chromium browser (Vivaldi) via native Windows input and accessibility, enabling mouse and keyboard actions, page observation, and status monitoring.

How do I use browser-use-native-windows?

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., "@browser-use-native-windows Open browser and go to weather.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.

de en es ja ko ru zh

browser-use-native-windows

by mlnima

Overview Schema Related Servers Score Discussions

TypeScript

Local

browser-use-native-windows

Windows-only MCP server for controlling a real Chromium browser with native screenshots, Windows accessibility, and Windows mouse/keyboard input.

It does not use CDP, Chrome DevTools, Playwright, Puppeteer, browser extensions, DOM selectors, DOM snapshots, or page JavaScript evaluation.

Every observation re-detects the browser window, monitor, physical resolution, monitor scaling, and window position. Window and monitor geometry is verified again before native mouse input; resize or scaling changes invalidate the observation so the client must observe the new screenshot before acting.

Requirements

Windows
Node.js 20+
Chromium-based browser: Edge, Chrome, Brave, Chromium, Vivaldi, Opera, Yandex

Related MCP server: hermes-computer-use

Install

From source:

npm install
npm run build

Optional global install from this package root:

npm install -g .

Configuration

The MCP reads system environment variables first. If a .env file exists next to this README, it is loaded as a fallback. The MCP starts normally when .env is missing.

Create .env from .env.example when you want fixed HTTP or browser settings:

BROWSER_USE_NATIVE_WINDOWS_SSE_HOST= "0.0.0.0"
BROWSER_USE_NATIVE_WINDOWS_SSE_PORT= "7331"
BROWSER_USE_NATIVE_WINDOWS_SSE_AUTH= "change.me"
BROWSER_USE_NATIVE_WINDOWS_BROWSER_EXECUTABLE_PATH= "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
BROWSER_USE_NATIVE_WINDOWS_BROWSER_USER_DATA_DIR= "C:\Users\YOUR_USER\AppData\Local\Microsoft\Edge\User Data"
BROWSER_USE_NATIVE_WINDOWS_PAGE_LOAD_TIMEOUT_MS= "10000"

Change BROWSER_USE_NATIVE_WINDOWS_SSE_AUTH before exposing HTTP outside your machine.

Run

Stdio transport:

npm run start:stdio

Streamable HTTP at /mcp:

npm run start:mcp

Legacy HTTP+SSE at /sse with POST messages at /messages:

npm run start:sse

Both network transports:

npm run start:all

Global install:

browser-use-native-windows
browser-use-native-windows --transport mcp
browser-use-native-windows --transport sse
browser-use-native-windows --transport all

The default network host is 0.0.0.0, so /mcp and /sse accept connections through localhost and this computer's LAN address. Bearer authentication is required on every network endpoint.

MCP Client

Stdio:

{
  "mcpServers": {
    "browser-use-native-windows": {
      "transport": "stdio",
      "command": "node",
      "args": ["<package-root>\\dist\\index.js"],
      "cwd": "<package-root>"
    }
  }
}

Codex Streamable HTTP:

[mcp_servers.browser_use_native_windows]
url = "http://<host>:7331/mcp"
http_headers = { "Authorization" = "Bearer change.me" }

SSE compatibility:

{
  "mcpServers": {
    "browser-use-native-windows": {
      "transport": "sse",
      "url": "http://<host>:7331/sse",
      "headers": {
        "Authorization": "Bearer change.me"
      }
    }
  }
}

Tools

browser_observe: launch or adopt the browser and return a native observation.
browser_act: run one mouse or keyboard action against a fresh observation token.
browser_status: return transport, driver, browser, window, focus, monitor, DPI, and observation state.
browser_stop: release held input state and optionally close the tracked browser.

Force Stop

Default global hotkey:

Control+F12

The watchdog releases held keys and mouse buttons, then stops the MCP process.

Available Tools

4 tools

browser_actAct In BrowserB

Run one native mouse or keyboard action against a matching fresh browser_observe token.

ParametersJSON Schema

Name	Required	Description	Default
`observationToken`	Yes
`action`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only says 'run one native mouse or keyboard action' without disclosing side effects, token lifecycle, reversibility, or required permissions. This is insufficient for a tool performing potentially destructive actions.

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 a single sentence, highly concise and front-loaded with the core purpose. However, it omits important details that would improve usability, slightly reducing its effectiveness.

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 complexity of the action parameter (13 variants) and no output schema, the description is severely lacking. It does not explain how to construct actions, the meaning of 'fresh' token, or what the tool returns, making it incomplete for practical use.

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

Parameters1/5

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

The schema description coverage is 0%, and the description adds no explanation of the observationToken or action parameters. It does not elaborate on the complex action structure, leaving agents to infer meaning solely from the schema, which is inadequate for effective selection and invocation.

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 'Run one native mouse or keyboard action against a matching fresh browser_observe token,' which specifies the verb (run), resource (action against browser), and distinguishes from sibling tools like browser_observe (observation) and browser_stop (stop).

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 usage context by mentioning 'matching fresh browser_observe token,' indicating dependence on the browser_observe tool. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, leaving room for ambiguity.

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

browser_observeObserve BrowserC

Launch or adopt a Windows browser, optionally handle a target URL through native UI, and return a browser-window or browser-owned file-dialog observation.

ParametersJSON Schema

Name	Required	Description	Default
`targetUrl`	No
`inlineImage`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It mentions launch/adopt and URL handling but lacks details on side effects (e.g., whether it opens a new window, modifies browser state), auth requirements, or blocking behavior. The phrase 'native UI' is vague.

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 a single sentence that conveys multiple aspects (launch/adopt, optional URL, return type). It is reasonably concise, though slightly long. No redundancy.

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 absence of an output schema, the description should clarify the return format. It only says 'return a browser-window or browser-owned file-dialog observation,' which is too vague. Parameter explanations are missing, leaving the agent with insufficient context.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only hints at 'targetUrl' ('optionally handle a target URL') but does not name or explain either parameter, and 'inlineImage' is entirely absent. This adds minimal value over the raw 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?

The description clearly states the verb ('launch or adopt'), resource ('Windows browser'), and the outcome ('return a browser-window or browser-owned file-dialog observation'). It distinguishes from sibling tools like browser_act and browser_stop by focusing on observation.

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?

The description provides no guidance on when to use this tool vs alternatives (siblings are browser_act, browser_status, browser_stop). There is no mention of prerequisites, limitations, or when not to use it.

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

browser_statusBrowser StatusB

Return MCP transport, native input driver, browser process, HWND, monitor, DPI, focus, and observation state.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/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 correctly indicates a read operation ('Return'), but does not disclose error scenarios (e.g., when the browser is not running), rate limits, or side effects. Adequate but not fully transparent.

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. Every word adds value, no redundancy, and it is appropriately sized for the tool's simplicity.

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 absence of output schema and annotations, the description is brief. While it enumerates the items returned, it offers no explanation of their meaning or format. For a status-checking tool, more context (e.g., types or example output) would improve completeness.

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 tool has zero parameters, so the schema coverage is 100%. Per scoring guidelines, baseline for 0 params is 4. The description does not need to add parameter information beyond the 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?

Description uses the specific verb 'Return' and lists the exact resources/states (MCP transport, native input driver, etc.). It clearly indicates the tool retrieves status information. Though it does not explicitly differentiate from siblings like browser_act or browser_observe, the name and description make the purpose clear.

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 versus alternatives (e.g., browser_observe for observations, browser_act for actions). The description implies it's for checking status, but lacks context or examples of appropriate usage.

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

browser_stopStop Browser ControlA

Release held native input state and optionally close the tracked browser only when the user task asks for it.

ParametersJSON Schema

Name	Required	Description	Default
`closeBrowser`	No

TDQS

A4.2/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 burden. It discloses releasing native input state and optional browser closing, but lacks details on the state after stopping (e.g., resumability, side effects).

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 that front-loads the primary action and includes the usage condition. No 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 tool with one optional parameter and no output schema, the description covers the core functionality and usage context adequately. Minor gaps exist (e.g., what happens to browser state if not closed), but overall it is complete.

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%, but the description adds meaning by linking 'optionally close' to the closeBrowser boolean parameter. It clarifies the parameter's role beyond the schema's bare boolean type.

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 'Release held native input state' and 'optionally close the tracked browser', specifying the verb and resource. It distinguishes from siblings like browser_act, browser_observe, and browser_status by focusing on stopping/releasing.

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 explicitly says 'only when the user task asks for it', providing a clear condition for when to use the tool. While it doesn't list alternatives, the context of sibling tools implies different purposes.

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.

4 tool updatesv0.1.0Jun 23, 2026
- First observedbrowser_act
- First observedbrowser_observe
- First observedbrowser_status
- First observedbrowser_stop

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct role: browser_observe for launching/adopting and getting observation, browser_act for performing actions, browser_status for checking state, and browser_stop for cleanup. No overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent 'browser_' prefix followed by a single verb (observe, act, status, stop), all lowercase, with no mixing of conventions.

Tool Count5/5

Four tools is exactly right for this domain: observe, act, status, and stop cover the essential lifecycle without unnecessary extras. Not too few, not too many.

Completeness5/5

The tool set covers the full lifecycle of native browser interaction: initialization (browser_observe), action (browser_act), monitoring (browser_status), and termination (browser_stop). No obvious gaps.

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

JxBrowser MCP Server A
io.github.TeamDev-IP
MCP server to assist with JxBrowser development.
Developer Tools Browser Automation
22
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
UI Verify A
io.github.igrlk
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
9118
Tap
io.github.LeonTing1010
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Browser Automation Web Scraping
217

Related MCP Servers

computer-use-windows
OS Automation App Automation
wimi321
A
license
Not graded
quality
D
maintenance
A standalone MCP server for Windows desktop control, enabling screenshots, mouse and keyboard input, app launch, window/display management, and clipboard access via natural language.
Updated 5 months ago (2026-04-01 11:17 UTC)
1
MIT
hermes-computer-use
Browser Automation Shell Access Web Scraping
Noah3521
A
license
Not graded
quality
C
maintenance
Pixel-level browser automation MCP server that drives a real Chrome browser using screenshots as vision input and OS-level mouse/keyboard as output, evading anti-bot detection.
Updated 5 months ago (2026-04-20 14:50 UTC)
3
MIT
windows-computer-use-mcp
Einosensokami
A
license
Not graded
quality
C
maintenance
A local, dependency-free MCP server that gives AI agents controlled access to the active Windows desktop, enabling automated interaction with applications through screenshots, clicks, typing, and window management.
Updated a month ago (2026-07-22 13:25 UTC)
87
MIT
pc-control-agent
OS Automation Autonomous Agents
anbu-20012005
F
license
Not graded
quality
C
maintenance
This MCP server enables an AI agent to control a Windows PC through human-like interactions such as screen capture, OCR, mouse, keyboard, and navigation, without using shortcut APIs.
Updated a month ago (2026-08-05 06:50 UTC)
-

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/mlnima/browser-use-native-windows'

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