Mcp MCP Server

WebDriverIO MCP Server

A Model Context Protocol (MCP) server that enables AI assistants to interact with web browsers, local Electron applications, and mobile applications using WebdriverIO. Automate Chrome, Firefox, Edge, Safari, Electron, iOS, and Android through a unified interface.

Installation

Add the following configuration to your MCP client settings:

Standard config (works in most clients):

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@wdio/mcp@latest"
      ]
    }
  }
}

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS), %APPDATA%\Claude\claude_desktop_config.json (Windows), or ~/.config/Claude/claude_desktop_config.json (Linux):

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@wdio/mcp@latest"
      ]
    }
  }
}

claude mcp add wdio-mcp -- npx -y @wdio/mcp@latest

Add to your VS Code settings.json or cline_mcp_settings.json file:

{
  "mcpServers": {
    "wdio-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@wdio/mcp@latest"
      ]
    }
  }
}

Go to Cursor Settings → MCP → Add new MCP Server, or create .cursor/mcp.json:

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@wdio/mcp@latest"
      ]
    }
  }
}

Use the Codex CLI:

codex mcp add wdio-mcp npx "@wdio/mcp@latest"

Or edit ~/.codex/config.toml:

[mcp_servers.wdio-mcp]
command = "npx"
args = ["@wdio/mcp@latest"]

Go to Advanced settings → Extensions → Add custom extension, or run:

goose configure

Or edit ~/.config/goose/config.yaml:

extensions:
  wdio-mcp:
    name: WebDriverIO MCP
    cmd: npx
    args: [ -y, "@wdio/mcp@latest" ]
    enabled: true
    type: stdio

Edit ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@wdio/mcp@latest"
      ]
    }
  }
}

Edit Zed settings (~/.config/zed/settings.json):

{
  "context_servers": {
    "wdio-mcp": {
      "source": "custom",
      "command": "npx",
      "args": [
        "-y",
        "@wdio/mcp@latest"
      ]
    }
  }
}

code --add-mcp '{"name":"wdio-mcp","command":"npx","args":["-y","@wdio/mcp@latest"]}'

---

⚠️ Restart Required: After adding the configuration, fully restart your MCP client to apply the changes.

Option 2: Global Installation

If you prefer to install globally:

npm install -g @wdio/mcp

Then use wdio-mcp as the command:

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "wdio-mcp"
    }
  }
}

📖 Need help? Follow the MCP install guide.

HTTP Transport (for non-subprocess clients)

By default the server uses stdio (subprocess) transport. For clients that cannot launch subprocesses (e.g. llama.cpp, OpenAI Codex secure mode), enable HTTP transport:

npx @wdio/mcp --http --port 3000

Then point your MCP client at http://localhost:3000/mcp.

Prerequisites For Mobile App Automation

• Appium Server: Install globally with npm install -g appium
• Platform Drivers:
  • iOS: appium driver install xcuitest (requires Xcode on macOS)
  • Android: appium driver install uiautomator2 (requires Android Studio)
• Devices/Emulators:
  • iOS Simulator (macOS) or physical device
  • Android Emulator or physical device
• For iOS Real Devices: You'll need the device's UDID (Unique Device Identifier)
  • Find UDID on macOS: Connect device → Open Finder → Select device → Click device name/model to reveal UDID
  • Find UDID on Windows: Connect device → iTunes or Apple Devices app → Click device icon → Click "Serial Number" to reveal UDID
  • Xcode method: Window → Devices and Simulators → Select device → UDID shown as "Identifier"

Start the Appium server before using mobile features:

appium
# Server runs at http://127.0.0.1:4723 by default

Cloud Providers

Run browser and mobile app tests on cloud real devices and browsers without any local setup. Currently supports BrowserStack, Sauce Labs, LambdaTest, TestingBot, and Digital.ai Testing.

Prerequisites

Set your provider credentials as environment variables or in your MCP client config:

export BROWSERSTACK_USERNAME=your_username
export BROWSERSTACK_ACCESS_KEY=your_access_key

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": ["-y", "@wdio/mcp@latest"],
      "env": {
        "BROWSERSTACK_USERNAME": "your_username",
        "BROWSERSTACK_ACCESS_KEY": "your_access_key"
      }
    }
  }
}

export SAUCE_USERNAME=your_username
export SAUCE_ACCESS_KEY=your_access_key

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": ["-y", "@wdio/mcp@latest"],
      "env": {
        "SAUCE_USERNAME": "your_username",
        "SAUCE_ACCESS_KEY": "your_access_key"
      }
    }
  }
}

| SAUCE_USERNAME | Sauce Labs username (required) | | SAUCE_ACCESS_KEY | Sauce Labs access key (required) |

The data center is set per-session via the region parameter in start_session (defaults to eu-central-1).

export TESTMU_USERNAME=your_username
export TESTMU_ACCESS_KEY=your_access_key

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": ["-y", "@wdio/mcp@latest"],
      "env": {
        "TESTMU_USERNAME": "your_username",
        "TESTMU_ACCESS_KEY": "your_access_key"
      }
    }
  }
}

| TESTMU_USERNAME | LambdaTest username (required) | | TESTMU_ACCESS_KEY | LambdaTest access key (required) |

export TESTINGBOT_KEY=your_key
export TESTINGBOT_SECRET=your_secret

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": ["-y", "@wdio/mcp@latest"],
      "env": {
        "TESTINGBOT_KEY": "your_key",
        "TESTINGBOT_SECRET": "your_secret"
      }
    }
  }
}

| TESTINGBOT_KEY | TestingBot key (required) | | TESTINGBOT_SECRET | TestingBot secret (required) |

export DIGITALAI_CLOUD_URL=https://your-cloud.example.com
export DIGITALAI_ACCESS_KEY=your_access_key

{
  "mcpServers": {
    "wdio-mcp": {
      "command": "npx",
      "args": ["-y", "@wdio/mcp@latest"],
      "env": {
        "DIGITALAI_CLOUD_URL": "https://your-cloud.example.com",
        "DIGITALAI_ACCESS_KEY": "your_access_key"
      }
    }
  }
}

| DIGITALAI_CLOUD_URL | Digital.ai cloud host, e.g. https://your-cloud.example.com (required) | | DIGITALAI_ACCESS_KEY | Digital.ai access key (required) |

The access key is sent via the digitalai:options capability (mobile) or the flat digitalai:accessKey capability (web).

Report pass/fail status: WebdriverIO defaults to the BiDi protocol, over which Digital.ai's cloud cannot observe command failures — so reports default to "Passed". To make the cloud reflect actual pass/fail, opt in to classic WebDriver per session:

start_session({
  provider: 'digitalai', platform: 'browser', browser: 'chrome', os: 'Windows 10',
  capabilities: { 'wdio:enforceWebDriverClassic': true }
})

(Pure client-side assertion failures still report as "Passed" — only failures that reach the cloud as WebDriver command errors are detected.)

Mobile (Appium): configure your Digital.ai project for Appium-server execution and pick its default Appium version via the project's "Manage default Appium server version" setting — the version is chosen at the project level (and tracks the versions your cloud supports), so this MCP does not pin one. See Appium Server Test Execution.

Browser Sessions

Run a browser on a specific OS/version combination:

// BrowserStack
start_session({
    provider: 'browserstack',
    platform: 'browser',
    browser: 'chrome',           // chrome | firefox | edge | safari
    browserVersion: 'latest',    // default: latest
    os: 'Windows',               // e.g. "Windows", "OS X"
    osVersion: '11',             // e.g. "11", "Sequoia"
    reporting: {
        project: 'My Project',
        build: 'v1.2.0',
        session: 'Login flow'
    }
})

// Sauce Labs
start_session({
    provider: 'saucelabs',
    platform: 'browser',
    browser: 'chrome',
    os: 'Windows',               // combined with osVersion → platformName
    osVersion: '11',             // e.g. "11", "15" (numbered Mac naming)
    region: 'eu-central-1',      // default: eu-central-1
    reporting: {
        build: 'v1.2.0',
        session: 'Login flow'
    }
})

// LambdaTest
start_session({
    provider: 'testmu',
    platform: 'browser',
    browser: 'chrome',
    os: 'Windows',               // combined with osVersion → platformName
    osVersion: '11',             // e.g. "11", "Sequoia" (optional)
    reporting: {
        project: 'My Project',
        build: 'v1.2.0',
        session: 'Login flow'
    }
})

// TestingBot
start_session({
    provider: 'testingbot',
    platform: 'browser',
    browser: 'chrome',
    os: 'Windows',               // combined with osVersion → platformName (default: Windows 11)
    osVersion: '11',
    reporting: {
        build: 'v1.2.0',
        session: 'Login flow'
    }
})

// Digital.ai
start_session({
    provider: 'digitalai',
    platform: 'browser',
    browser: 'chrome',
    os: 'Windows',               // combined with osVersion → digitalai:osName (optional)
    osVersion: '11',
    reporting: {
        session: 'Login flow'    // → digitalai:testName (flat capability, not nested)
    }
})

Provider-specific os / osVersion behavior:

• BrowserStack — os and osVersion map to separate bstack:options.os / bstack:options.osVersion fields.
• Sauce Labs / LambdaTest / TestingBot — os and osVersion are combined into the W3C platformName capability (e.g., os: 'Windows' + osVersion: '11' → platformName: 'Windows 11'). These providers use platformName values like "Windows 11", "MacOS Sequoia", or "Linux". TestingBot defaults to Windows 11 when os is omitted.
• Digital.ai — os and osVersion are combined into the flat digitalai:osName capability (NOT platformName), e.g. os: 'Windows' + osVersion: '11' → digitalai:osName: 'Windows 11'.

Mobile App Sessions

Test on cloud real devices. First upload your app (or use an existing app URL):

// BrowserStack: returns bs:// URL
upload_app({ provider: 'browserstack', path: '/path/to/app.apk' })

// Sauce Labs: returns storage:filename= reference
upload_app({ provider: 'saucelabs', path: '/path/to/app.apk' })

// LambdaTest: returns lt:// URL
upload_app({ provider: 'testmu', path: '/path/to/app.apk' })

// TestingBot: returns tb:// URL
upload_app({ provider: 'testingbot', path: '/path/to/app.apk' })

// Digital.ai: returns cloud:<package-or-bundle> reference
upload_app({ provider: 'digitalai', path: '/path/to/app.apk' })

// Start a session
start_session({
    provider: 'browserstack',
    platform: 'android',
    app: 'bs://abc123...',
    deviceName: 'Samsung Galaxy S23',
    platformVersion: '13.0'
})

// Sauce Labs native app
start_session({
    provider: 'saucelabs',
    platform: 'android',
    app: 'storage:filename=myapp.apk',
    deviceName: 'Samsung.*',
    platformVersion: '16'
})

// LambdaTest native app
start_session({
    provider: 'testmu',
    platform: 'android',
    app: 'lt://abc123...',
    deviceName: 'Pixel 7',
    platformVersion: '13'
})

// TestingBot native app
start_session({
    provider: 'testingbot',
    platform: 'android',
    app: 'tb://abc123...',
    deviceName: 'Pixel 7',
    platformVersion: '13'
})

// Digital.ai native app — devices are selected via a deviceQuery
start_session({
    provider: 'digitalai',
    platform: 'android',
    app: 'cloud:com.example.app',
    deviceQuery: "@os='android' and @version='14' and @name='.*Pixel.*'"
    // or omit deviceQuery and pass deviceName / platformVersion to build one
})

Mobile Browser Sessions

Run a browser on a cloud mobile device — real device or emulator/simulator — without uploading an app:

// BrowserStack — Chrome on Android emulator
start_session({
    provider: 'browserstack',
    platform: 'android',
    browser: 'chrome',
    deviceName: 'Google Pixel 7',
    platformVersion: '13'
})

// Sauce Labs — Safari on iOS simulator
start_session({
    provider: 'saucelabs',
    platform: 'ios',
    browser: 'safari',
    deviceName: 'iPhone 15',
    platformVersion: '18',
    region: 'eu-central-1'
})

// LambdaTest — Chrome on Android emulator
start_session({
    provider: 'testmu',
    platform: 'android',
    browser: 'chrome',
    deviceName: 'Pixel 7',
    platformVersion: '13'
})

// TestingBot — Chrome on Android emulator
start_session({
    provider: 'testingbot',
    platform: 'android',
    browser: 'chrome',
    deviceName: 'Pixel 7',
    platformVersion: '13'
})

// Digital.ai — Chrome on an Android device (real or emulator; selected via a deviceQuery)
start_session({
    provider: 'digitalai',
    platform: 'android',
    browser: 'chrome',
    deviceName: 'Pixel 7',
    platformVersion: '13'
    // or omit deviceName / platformVersion and pass deviceQuery directly, e.g.
    // deviceQuery: "@os='android' and @emulator='true'" to force an emulator
})

Note: Mobile browser sessions do not require app, appPath, or noReset. The provider launches a browser directly on the selected device — real or emulator/simulator.

Use list_apps to see previously uploaded apps:

list_apps({ provider: 'browserstack' })
list_apps({ provider: 'saucelabs', sortBy: 'app_name' })
list_apps({ provider: 'testmu' })
list_apps({ provider: 'testingbot' })
list_apps({ provider: 'digitalai' })
list_apps({ provider: 'browserstack', organizationWide: true })

Local Tunnel

To test against URLs that are only accessible on your local machine or internal network, enable a local tunnel:

// Auto-start tunnel (provider manages lifecycle)
start_session({
    provider: 'saucelabs',
    platform: 'browser',
    tunnel: true                  // auto-starts tunnel before session
})

// Use an already-running tunnel
start_session({
    provider: 'saucelabs',
    platform: 'browser',
    tunnel: 'external'            // uses existing tunnel
})

The tunnel parameter replaces the deprecated browserstackLocal, saucelabsLocal, and testmuLocal params. Set it to true to auto-start the tunnel (stopped automatically after the session), or 'external' to use a tunnel already running on your machine.

Note: With tunnel: true the provider downloads and manages the tunnel binary for you. For tunnel: 'external' you run it yourself — the wdio://saucelabs/local-binary, wdio://testmu/local-binary, and wdio://testingbot/local-binary resources provide download URLs and setup instructions. The TestingBot Tunnel is a single cross-platform Java JAR (requires Java 11+) rather than a per-platform binary.

Reporting Labels

All session types support reporting labels that appear in the provider dashboard:

Cloud Provider Tools

Both tools require a provider parameter ('browserstack', 'saucelabs', 'testmu', 'testingbot', or 'digitalai').

Features

Browser Automation

• Session Management: Start and close browser sessions (Chrome, Firefox, Edge, Safari) with headless/headed modes
• Navigation & Interaction: Navigate URLs, click elements, fill forms, and retrieve content
• Page Analysis: Get visible elements, accessibility trees, take screenshots
• Cookie Management: Get, set, and delete cookies
• Scrolling: Smooth scrolling with configurable distances
• Attach to running Chrome: Connect to an existing Chrome window via --remote-debugging-port — ideal for testing authenticated or pre-configured sessions
• Connect to existing WebDriver endpoints: Reuse an already-running Selenium-compatible WebDriver endpoint, such as a framework-managed browser or a desktop webview automation bridge (like Tauri)
• Device emulation: Apply mobile/tablet presets (iPhone 15, Pixel 7, etc.) to simulate responsive layouts without a physical device
• Session Recording: All tool calls are automatically recorded and exportable as runnable WebdriverIO JS

Mobile App Automation (iOS/Android)

• Native App Testing: Test iOS (.app/.ipa) and Android (.apk) apps via Appium
• Touch Gestures: Tap, swipe, long-press, drag-and-drop
• App Lifecycle: Launch, background, terminate, check app state
• Context Switching: Seamlessly switch between native and webview contexts for hybrid apps
• Device Control: Rotate, lock/unlock, geolocation, keyboard control, notifications
• Cross-Platform Selectors: Accessibility IDs, XPath, UiAutomator (Android), Predicates (iOS)

Available Tools

The server lists only the tools that fit the current session: browser sessions get the page tools below, mobile sessions the gestures and device tools, Electron sessions the Electron tools. Rarely used groups (mocks, cookies, device emulation, extensions, attaching, the raw element list, cloud app uploads) are listed after the agent calls enable_tools, so their definitions aren't sent with every request. With several live sessions, tools are listed for the union of their platforms. Set WDIO_MCP_TOOLS=all to list everything up front.

Set WDIO_MCP_NETWORK_LOGS to configure the default Chromium network/performance log capture mode for start_session: none (default, off), failures (Network.loadingFailed and Network.responseReceived entries with HTTP status >= 400), or all (every Chromium performance log entry). Individual sessions can override this default via start_session({ networkLogs: 'none' | 'failures' | 'all' }).

Session Management

Multiple sessions

By default the server keeps one session: starting a new one closes the previous one. To run sessions side by side, pass onExisting: "keep" and a name to start_session. The new session is not made the default, so the original keeps answering calls that omit a target.

Every session-bound tool accepts an optional session argument, either a name or a sessionId (sessionId is matched first). Omitting it uses the default session, and targeting a session never changes the default. When a call is targeted, or more than one session is live, the result starts with [session: name (id8)]. Calls to the same session queue and run in order; calls to different sessions run concurrently. An unknown target, or no default session while others are live, returns an error that lists the live sessions. Names are scoped to one server process. The wdio://session/current/* resources always refer to the default session.

start_session({ platform: "browser", browser: "chrome", name: "alice" })
start_session({ platform: "browser", browser: "chrome", name: "bob", onExisting: "keep" })
navigate({ url: "https://example.com", session: "bob" })

Navigation & Page Interaction (Web & Mobile)

Element Interaction (Web & Mobile)

click_element, set_value, tap_element and perform_actions take a ref from snapshot (e12) as well as a selector, in browsers and apps, and each result lists what the action changed on the page or screen: new or changed elements with their refs, or the page it navigated to. An agent rarely needs a separate screenshot or snapshot to see the effect.

Recommended workflow (also sent to clients as server instructions):

• snapshot, then act with refs.
• Several steps in a row (fill a form, then submit): one perform_actions call.
• Refs from the latest result stay valid until the page changes.

Cookie Management (Web, after enable_tools)

Mobile Gestures (iOS/Android)

Context Switching (Hybrid Apps)

Device Control (iOS/Android)

Documentation Search

MCP Resources (read-only, no tool call needed)

Usage Examples

Real-World Test Cases

Example 1: Testing Demo Android App (Book Scanning)

Test the Demo Android app at C:\Users\demo-liveApiGbRegionNonMinifiedRelease-3018788.apk on emulator-5554:
1. Start the app with auto-grant permissions
2. Get visible elements on the onboarding screen
3. Tap "Skip" to bypass onboarding
4. Verify main screen loads
5. Take a screenshot

Example 2: Testing World of Books E-commerce Site

You are a Testing expert, and want to assess the basic workflows of worldofbooks.com:
- Open World of Books (accept all cookies)
- Get visible elements to see navigation structure
- Search for a fiction book
- Choose one and validate if there are NEW and used book options
- Report your findings at the end

Browser Automation

Basic web testing prompt:

You are a Testing expert, and want to assess the basic workflows of a web application:
- Open World of Books (accept all cookies)
- Search for a fiction book
- Choose one and validate if there are NEW and used book options
- Report your findings at the end

Browser configuration options:

// Default settings (headed mode, 1280x1080)
start_session({platform: 'browser'})

// Firefox
start_session({platform: 'browser', browser: 'firefox'})

// Edge
start_session({platform: 'browser', browser: 'edge'})

// Safari (headed only; requires macOS)
start_session({platform: 'browser', browser: 'safari'})

// Headless mode
start_session({platform: 'browser', headless: true})

// Custom dimensions
start_session({platform: 'browser', windowWidth: 1920, windowHeight: 1080})

// Pass custom capabilities (e.g. Chrome extensions, profile, prefs)
start_session({
    platform: 'browser',
    headless: false,
    capabilities: {
        'goog:chromeOptions': {
            args: ['--user-data-dir=/tmp/wdio-mcp-profile', '--load-extension=/path/to/unpacked-extension']
        }
    }
})

Mocking

Mocking is available through mock, get_mock_calls, and manage_mock (listed after enable_tools({ groups: ['mocks'] })), for both Electron main-process API functions and browser network requests.

mockType accepts 'electron' or 'browser'. Browser mocks are the default in WebDriver sessions when mockType is omitted. Electron sessions require an explicit selection because they can target both kinds of mocks. iOS/Android Appium sessions do not support mocking.

mock({
  mockType: 'electron', apiName: 'dialog', funcName: 'showOpenDialog',
  behavior: 'mockResolvedValue', value: { canceled: false, filePaths: ['/tmp/example.txt'] }
})
// Interact with the renderer to open the application's file picker, then inspect its calls.
get_mock_calls({ mockType: 'electron', apiName: 'dialog', funcName: 'showOpenDialog' })
manage_mock({ mockType: 'electron', apiName: 'dialog', funcName: 'showOpenDialog', action: 'restore' })

Electron behavior defaults to mockReturnValue; mockResolvedValue and mockRejectedValue support async APIs. Each has a Once variant for queued responses. Repeated configuration preserves the existing mock and call history. Values must be JSON; omit value for undefined. clear removes call history, reset also removes behavior and queued responses, and restore reinstates the original function. These tools support individual API functions; class mocks and arbitrary mock implementations are not exposed.

Documentation truncated — see the full README on GitHub.