220 browser automation tools for Chrome, Edge, and Firefox via CDP + BiDi. 100% Python.
WaveXisMCP MCP server exists for a simple reason — assistants are far more useful when they can act on WaveXisMCP directly instead of describing what you should do. 220 browser automation tools for Chrome, Edge, and Firefox via CDP + BiDi. 100% Python.
Once WaveXisMCP is connected, these are the calls the assistant has available:
Multi — action YAML** — chain navigate → click → fill → screenshot in a single tool callTool — A single browser operation (screenshot, eval, click, etc.) exposed as an MCP tool that any LLM client can callSession — A persistent browser instance. Open a session, chain multiple tool calls, close when done. Avoids the overhead of launching a browser per actionBrowser — Google Chrome, Microsoft Edge, or any Chromium/Chrome-based browsernavigate — https://example.comscreenshot — full_page: trueeval — document.titleclick — "#login"type — selector: "#username"wavexis — //session/{id}/url — current page URLcdpwave — low-level async Python library for the Chrome DevTools Protocol. Direct WebSocket to Chrome/Edge. No driver binary neededbidiwave — low-level async Python library for the WebDriver BiDi protocol (W3C standard). Works with Firefox, Chrome, and EdgeBeing a remote server, there is no local install. You register the endpoint with your client, authorise it once, and the tools appear.
Plenty of browser automation servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. WaveXisMCP's toolset — Multi, Tool, Session and 11 more — is a fair guide to whether it matches your workflow. It is maintained by MathiasPaulenko; worth a glance at recent repository activity before you build anything load-bearing on it.
We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.
| Tool | What it does |
|---|---|
| Multi | action YAML** — chain navigate → click → fill → screenshot in a single tool call |
| Tool | A single browser operation (screenshot, eval, click, etc.) exposed as an MCP tool that any LLM client can call. |
| Session | A persistent browser instance. Open a session, chain multiple tool calls, close when done. Avoids the overhead of launching a browser per action. |
| Browser | Google Chrome, Microsoft Edge, or any Chromium/Chrome-based browser |
| navigate | https://example.com |
| screenshot | full_page: true |
| eval | document.title |
| click | "#login" |
| type | selector: "#username" |
| wavexis | //session/{id}/url — current page URL |
| cdpwave | low-level async Python library for the Chrome DevTools Protocol. Direct WebSocket to Chrome/Edge. No driver binary needed. |
| bidiwave | low-level async Python library for the WebDriver BiDi protocol (W3C standard). Works with Firefox, Chrome, and Edge. |
| WaveXisMCP | MCP server wrapping wavexis. Exposes each backend method as an MCP tool with Pydantic v2 input validation, JSON responses, and capability tier filtering. |
| Tier | Flag |
{
"mcpServers": {
"wavexis": {
"command": "uvx",
"args": ["wavexis-mcp", "--caps", "all"]
}
}
}Configuration as documented by the project. Restart the client after saving.
Microsoft's official browser automation server — drive a real browser through the accessibility tree, no screenshots needed.
Industrial-strength web extraction — render, scrape, crawl and search entire sites into clean markdown.
The original Chromium automation reference server — simple, screenshot-driven browser control.
Give your coding agent the full DevTools toolbox: traces, network, console, heap snapshots and Lighthouse.
Puppeteer-powered browser control that drives pages from the accessibility tree instead of pixels.
Cloud browsers for AI agents — automation sessions that run in Browserbase's fleet, not on your machine.