pony-browser-mcp
# Pony Browser MCP
Pony Browser MCP connects an MCP client to the user's existing Chrome profile
through a loopback-only WebSocket. It adds dedicated agent windows, named task
groups, workspace cleanup, and explicit human review prompts to the upstream
Browser MCP implementation.
The project has two local components:
1. The Chrome Web Store extension, installed once per Chrome profile and then
updated by Chrome.
2. The MCP server, launched on demand by Codex or another MCP client through
`stdio`.
The server intentionally listens only on `127.0.0.1`. It is not a shared remote
browser service and does not expose browser control on the LAN.
## Codex setup
After a release is published:
```bash
npm install --global https://github.com/pssrh/pony-browser-mcp/releases/download/v1.0.1/pony-browser-mcp-1.0.1.tgz
codex mcp add pony-browser -- pony-browser-mcp
```
For shared Windows, macOS, or Linux machines, install the signed extension
through the managed-policy scripts in [enterprise/](enterprise/). Chrome then
checks the GitHub Pages update manifest and upgrades the extension without a
Chrome Web Store listing. Developers can still load `extension/` unpacked for
local testing.
## Build and verify
```bash
npm ci
npm test
npm run build:cws
```
The Web Store ZIP and npm tarball are written to `dist/` with SHA-256 files.
## Privacy
The extension has no analytics or vendor backend. Browser data requested by an
MCP client travels over localhost to that client. The client may then send the
data to its configured model provider under the client's own privacy policy.
See the full [privacy policy](store/site/privacy.html).
## Attribution
This project is a fork of [Browser MCP by Agent360](https://github.com/Agent360dk/browser-mcp),
used under the MIT License. See [NOTICE.md](NOTICE.md) and [LICENSE](LICENSE).
TDQS
Scored across 45 tools
Most tools target clearly distinct actions or resource types, and the descriptions heavily cross-reference when to prefer one alternative over another (e.g., browser_set_date vs browser_fill, browser_drop_file vs browser_upload_file). The main ambiguity risk comes from the cluster of click variants and form-input tools, but the descriptions do enough to disambiguate them.
The browser_ prefix and snake_case style are consistent, and most names follow a verb_noun pattern. A few exceptions like browser_screenshot, browser_console_logs, browser_clipboard_stats, and browser_about deviate from the verb-first convention, creating minor inconsistency.
45 tools is well above the 25+ threshold for 'too many' and will create real selection overhead for agents. While browser automation is a broad domain, the surface could likely be consolidated or split into focused servers.
The toolset is remarkably comprehensive, covering navigation, interaction, forms, files, dialogs, tabs/windows, frames, network, storage, clipboard, and user-in-the-loop flows. Minor gaps exist—such as explicit back/forward/reload navigation and delete-cookie/clear-storage operations—but most workflows can still be completed through workarounds.