WebdriverIO MCP: browser and mobile app automation
webdriverio-mcp
The official MCP from the WebdriverIO team drives Chrome, Firefox, Edge, Safari, Electron, iOS and Android through one tool set
- 44 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- The agent drives a real browser and can attach to an already open Chrome with all its logins, cookies and open tabs
- Extra tool groups provide reading and writing cookies, network mocks and extension installs
- Running scenarios on cloud providers sends them test environment data and spends paid minutes
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add mcp/webdriverio-mcpDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- The agent drives a real browser and can attach to an already open Chrome with all its logins, cookies and open tabs
- Extra tool groups provide reading and writing cookies, network mocks and extension installs
- Running scenarios on cloud providers sends them test environment data and spends paid minutes
This is third-party code. Review the repository files before installing.
What it does
The @wdio/mcp server starts browser, Electron or mobile app sessions through Appium and gives the agent tools for navigation, clicks, input, scrolling, page snapshots and the accessibility tree. Mobile apps get gestures, webview context switching, rotation and geolocation. Extra tool groups are enabled with enable_tools: mocks, cookies, device emulation, extensions and attaching to an already running Chrome. Every call is recorded in the session history, and the wdio://session/current/code resource returns a ready WebdriverIO script. The trace: true option saves a Playwright-compatible trace. Tests can run on BrowserStack, Sauce Labs, LambdaTest, TestingBot and Digital.ai cloud devices.
Who it is for. QA engineers and developers who write WebdriverIO tests and want working scenario code out of a conversation with an agent
Good fit when
- You want to walk a scenario in a browser and get a ready WebdriverIO test from the session record
- An iOS or Android app has to be checked through Appium without writing selectors by hand
- An Electron app has to be tested together with its windows and menus
- You need to attach to an already open Chrome with the right login and run a scenario there
- Tests must run on BrowserStack or Sauce Labs cloud devices
Not a fit when
- The project is tested with Playwright or Cypress: the server returns WebdriverIO code
- You need several parallel sessions with no names: by default there is one and a new one closes the previous
- There is no Appium, emulator or Xcode for mobile tests: mobile sessions do not start without them
- You need large-scale data collection from third-party sites: the server is made for testing
Example request
Open the staging login page in Chrome, sign in as the test user and export the code of this scenario in WebdriverIO.MCP
- Transport
- stdio
- Authentication
- not required
Environment variables
WDIO_MCP_NETWORK_LOGS- Chromium network log capture mode: none, failures or all
Limitations
A session is either a browser or a mobile app; to switch, the current one is closed. Mobile automation needs a running Appium server, and iOS also needs macOS with Xcode and the UDID of a real device. Long scenarios use up agent message limits quickly. The server knows nothing about your test project: the agent supplies paths to specs and config itself. To keep several sessions side by side, give each a name and the onExisting option set to keep.
How to disable. Run claude mcp remove wdio-mcp. Close active sessions with close_session so no browsers or emulators stay open.
FAQ
How does the server differ from Playwright MCP?
It runs on WebdriverIO and Appium, so it also drives Safari, Electron and native mobile apps, and outputs WebdriverIO code.
Can it attach to my logged-in browser?
Yes. launch_chrome starts Chrome with a debugging port, and start_session with attach: true connects to it.
Does it work with real phones?
Yes, through Appium. A real iPhone needs the device UDID, and Android works with emulators and connected devices.
Which cloud providers are supported?
BrowserStack, Sauce Labs, LambdaTest, TestingBot and Digital.ai Testing.
Where are recorded scenarios stored?
In the server session history, served by the wdio://sessions and wdio://session/current/steps resources. With trace: true the trace lands in the .trace folder.
Discussion
No questions or reviews yet.
Related
MCP serversBrowserStack MCP Server: testing on real devices
BrowserStack MCP Server
The official BrowserStack MCP server: real devices, automated tests and test cases driven by an agent from your editor
kogiQA MCP gives an agent a browser that finds page elements without selectors, for debugging web apps and writing e2e tests
An MCP server from Mozilla: an agent drives Firefox through WebDriver BiDi, reads the console and network, takes page snapshots and profiles loading
A community Playwright MCP server: browser automation, screenshots, device emulation and test code generation
MCP Accessibility Scanner runs axe checks, exercises keyboard focus and saves accessibility reports for web pages
Microsoft MCP servers for test automation: control of Windows, macOS and mobile UIs and generation of BDD code.
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| WebdriverIO MCP: browser and mobile app automation (this card) | yes | not required | 44 | |
| Playwright MCP | yes | not required | 39,570 | works with browsers only and outputs Playwright code, while this one adds Appium, Electron and WebdriverIO code |
| Appium MCP | yes | not required | 517 | a narrow Appium server, while this has one tool set for web, Electron and mobile sessions |
README in short
The README is large: setup for a dozen clients, cloud providers, tools by group, examples for web, Electron and mobile apps, selectors, app state preservation, session recording and tracing. Appium requirements and common errors have their own sections.