TestingBot MCP server

TestingBot MCP Server

TestingBot's official Model Context Protocol (MCP) server implementation. This server enables AI assistants to interact with TestingBot's testing infrastructure, allowing you to manage tests, browsers, devices, and more through conversational interfaces.

⚡ One-Click Install

Claude Desktop: download mcp-server.mcpb from the releases page and double-click it. Claude will set up the TestingBot MCP server automatically.

After install, set your credentials from TestingBot account settings.

Features

• 📱 App Automate - Run Maestro, Espresso, and XCUITest suites on real devices and emulators, straight from the agent
• 🖥️ Live Testing - Start interactive manual testing sessions on real browsers and devices
• 🌐 Browser & Device Management - Query available browsers and real devices
• 🧪 Test Management - Create, retrieve, update, and delete tests with comprehensive details
• 📦 Storage Management - Upload and manage mobile app files (APK, IPA, ZIP)
• 📸 Screenshot Testing - Take cross-browser screenshots
• 🏗️ Build Management - Organize tests into builds
• 👤 User Account - View and update account information
• 👥 Team Management - Manage team settings and team members
• 🔌 Chrome DevTools Protocol - Create CDP sessions for advanced browser automation
• 🚇 Tunnel Management - Start, stop and manage TestingBot tunnels to test localhost and private sites

Prerequisites

• Node.js >= 20 (recommended: 22.15.0 or later)
• TestingBot Account with API credentials
• An MCP-compatible client (Claude Desktop, VS Code with Continue, Cursor, etc.)

Installation

Quick Setup

Install the MCP server globally:

npm install -g @testingbot/mcp-server

Or add to your project:

npm install @testingbot/mcp-server

Configuration

Recommended: log in with tb_login (no key/secret to copy)

You don't have to find and paste API credentials. Install the server, leave the credentials blank, and just ask the agent:

Log me in to TestingBot.

The agent calls the tb_login tool. It uses OAuth-style browser authentication — no secret ever leaves the browser — and picks the right mechanism for your environment automatically:

• Browser (loopback, the default on a desktop): your browser opens to a TestingBot authorization page. Sign in if needed and click Authorize; the credentials are captured on a local callback and the agent finishes the sign-in. Nothing to type. (RFC 8252.)

• Device code (automatic fallback on SSH / remote / dev containers / web): the tool prints a short URL and code instead:

  1. Open the URL in your browser (e.g. https://testingbot.com/device).
  2. Enter the code, sign in if needed, and click Authorize.
  3. Tell the agent you've authorized — it calls tb_login again to finish.

  (RFC 8628.)

You can force a mechanism by passing mode: "loopback" or mode: "device" to tb_login (the default is "auto").

Your credentials are written to ~/.testingbot/credentials (mode 0600) and used by every subsequent tool call — no restart and no JSON editing. This works in any MCP client (VS Code, Cursor, Cline, Claude Desktop, …). To use a different account, set TESTINGBOT_PROFILE; to relocate the file, set TESTINGBOT_CONFIG_DIR.

Environment Variables

Alternatively (or for CI, where env vars take precedence over the file), set your TestingBot credentials as environment variables:

export TESTINGBOT_KEY="your-api-key"
export TESTINGBOT_SECRET="your-api-secret"

Or create a .env file in your project:

TESTINGBOT_KEY=your-api-key
TESTINGBOT_SECRET=your-api-secret

The key also accepts the aliases TB_KEY / TESTINGBOT_USERNAME, and the secret accepts TB_SECRET / TESTINGBOT_ACCESS_KEY.

How credentials are resolved

Credentials are resolved in this order, highest priority first:

1. Environment variables (above) — both a key and a secret must be set. This lets CI and per-client config override everything else.
2. The ~/.testingbot/credentials file written by tb_login, for the active profile (default, or TESTINGBOT_PROFILE).
3. Neither set: the server starts in a degraded mode where every tool except tb_login reports "Run tb_login to authenticate" — so first run is self-healing rather than a hard error.

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%/Claude/claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "testingbot": {
      "command": "npx",
      "args": ["-y", "@testingbot/mcp-server"],
      "env": {
        "TESTINGBOT_KEY": "your-api-key",
        "TESTINGBOT_SECRET": "your-api-secret"
      }
    }
  }
}

VS Code (with Continue extension)

Add to .continue/config.json:

{
  "mcpServers": [
    {
      "name": "testingbot",
      "command": "npx",
      "args": ["-y", "@testingbot/mcp-server"],
      "env": {
        "TESTINGBOT_KEY": "your-api-key",
        "TESTINGBOT_SECRET": "your-api-secret"
      }
    }
  ]
}

Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "testingbot": {
      "command": "npx",
      "args": ["-y", "@testingbot/mcp-server"],
      "env": {
        "TESTINGBOT_KEY": "your-api-key",
        "TESTINGBOT_SECRET": "your-api-secret"
      }
    }
  }
}

🤖 Let an AI Agent Drive a Remote Browser or Device

This server already includes the automation tools from @testingbot/automation-mcp — installing this package gives the agent the ability to actually drive a remote browser or real mobile device on TestingBot's grid, not just manage resources.

Just ask:

Open Safari 17 on macOS on TestingBot. Navigate to example.com and click the "More information" link.

The agent will call tb_openBrowser, tb_navigate, tb_snapshot, tb_click — and surface a live-view URL so you can watch it in real time. For real iOS / Android devices, the bundled appium-mcp child gives the agent the full appium_* toolbelt (appium_session_management, appium_gesture, appium_set_value, appium_screenshot, ~30 more) — no separate install or config required. Just ask: "Open an iPhone 15 Pro on iOS 17 on TestingBot, tap the login button, take a screenshot." See the @testingbot/automation-mcp README for the full tool list, caveats (sessions are metered), and configuration options.

🚇 Testing localhost and private sites

TestingBot's browsers and devices run in the cloud, so they can't open localhost, private IPs (10.x, 192.168.x, …) or intranet hosts directly. To reach them, they need a TestingBot Tunnel running on your machine. Just ask:

Start a tunnel and open http://localhost:3000 in Chrome on Windows 11.

The agent calls startTunnel, which needs Java 17+. The tool returns the tunnel's identifier and ID, and the agent passes them on:

Run	How it uses the tunnel
tb_openBrowser (agent-driven browser)	tunnelIdentifier (required: sessions without it go direct). Or set TESTINGBOT_TUNNEL_IDENTIFIER
appium_session_management (native apps)	"tb:options": {"tunnel-identifier": "…"} in the capabilities
startLiveSession / startDesktopLiveSession / startMobileLiveSession	tunnelId (the numeric ID)
runMaestroTest	tunnelIdentifier. Without it, the account's newest running tunnel is used
takeScreenshot, runAppAutomateTest (Espresso / XCUITest)	The account's newest running tunnel is used automatically

Android apps and flows: Android never sends localhost / 127.0.0.1 through a proxy, so on an Android device or emulator those URLs reach the device itself, not your machine. Use a hostname that resolves to 127.0.0.1 on your side instead, such as http://myapp.localtest.me:3000. The tunnel resolves it on your machine.

stopTunnel stops the tunnel. Tunnels started by the server are also stopped when the server exits. If you'd rather run the tunnel yourself, start it with --tunnel-identifier <name> and give the agent that name.

Available Tools

Live Testing

startLiveSession

Start an interactive live testing session on TestingBot. Returns a link that opens the session in your TestingBot dashboard, where you confirm it with Start. Mobile sessions run on emulators/simulators; real-device live sessions are started from the dashboard.

Parameters:

• platformType: "desktop" or "mobile"
• desiredURL: The URL to open
• desiredOS: Operating system (Windows, Mac, Linux for desktop; android, ios for mobile)
• desiredOSVersion: OS version: Windows 11/10/8.1/8; macOS by name (Sonoma) or number (14); or a platform code like WIN11
• desiredBrowser (desktop only): Browser name (chrome, firefox, safari, edge, ie)
• desiredBrowserVersion (desktop only): Browser version or "latest"
• desiredDevice (mobile only): Device name (e.g., "iPhone 14", "Galaxy S23")
• tunnelId (optional): Numeric ID of a running tunnel, needed for localhost / private URLs (see Testing localhost and private sites)

Example prompts:

"Start a live testing session on Chrome latest with Windows 11 for https://example.com" "Open https://myapp.com on iPhone 14 with iOS 16 for manual testing"

startDesktopLiveSession

Convenience tool to start a desktop browser live testing session.

Parameters:

• desiredURL: The URL to open
• desiredOS: Windows, Mac, or Linux
• desiredOSVersion: OS version
• desiredBrowser: chrome, firefox, safari, edge, or ie
• desiredBrowserVersion (optional): Browser version or "latest" (default: latest)
• tunnelId (optional): Numeric ID of a running tunnel, for localhost / private URLs

Example prompt:

"Start desktop live session on Firefox 120 with Mac Monterey for https://example.com"

startMobileLiveSession

Convenience tool to start a mobile device live testing session.

Parameters:

• desiredURL: The URL to open
• desiredOS: android or ios
• desiredOSVersion: OS version
• desiredDevice: Device name
• tunnelId (optional): Numeric ID of a running tunnel, for localhost / private URLs

Example prompt:

"Start mobile live session on Galaxy S23 with Android 13 for https://example.com"

Browser & Device Management

getBrowsers

Get list of available browsers and platforms for testing.

Parameters:

• type (optional): Filter by "web" or "mobile"

Example prompt:

"Show me all available browsers for testing" "What mobile browsers are available?"

getDevices

Get list of available mobile devices (real devices and simulators).

Example prompt:

"List all available iOS devices" "Show me Android devices for testing"

Test Management

getTests

Retrieve a list of recent tests with pagination.

Parameters:

• offset (optional): Pagination offset (default: 0)
• limit (optional): Number of tests to retrieve (default: 10, max: 100)

Example prompt:

"Show me my last 20 tests" "Get recent test results"

getTestDetails

Get comprehensive details about a specific test including:

• Test status, browser, platform, and timing information
• Video recording URL and screenshot URLs
• Selenium, browser, and Appium logs
• Test execution steps with commands and timestamps
• Network logs, exception logs, and JS errors

Parameters:

• sessionId: The session ID of the test

Example prompt:

"Get details for test session abc123" "Show me the video and logs for test xyz789" "Show execution steps for test abc123"

updateTest

Update test metadata such as name, status, or build.

Parameters:

• sessionId: The session ID of the test
• name (optional): New name for the test
• status (optional): "passed" or "failed"
• build (optional): Build identifier
• extra (optional): Additional metadata (JSON string)

Example prompt:

"Mark test abc123 as passed" "Update test xyz789 with name 'Login Flow Test'"

deleteTest

Delete a test by session ID.

Parameters:

• sessionId: The session ID of the test to delete

Example prompt:

"Delete test abc123"

stopTest

Stop a running test by session ID.

Parameters:

• sessionId: The session ID of the test to stop

Example prompt:

"Stop test abc123"

Build Management

getBuilds

Get a list of builds with pagination.

Parameters:

• offset (optional): Pagination offset (default: 0)
• limit (optional): Number of builds to retrieve (default: 10, max: 100)

Example prompt:

"Show me my recent builds"

getTestsForBuild

Get all tests associated with a specific build ID.

Parameters:

• buildId: The build ID

Example prompt:

"Show all tests for build 12345"

deleteBuild

Delete a build and all its associated tests.

Parameters:

• buildId: The build ID to delete

Example prompt:

"Delete build 12345"

Storage Management

uploadFile

Upload a local file (APK, IPA, or ZIP) to TestingBot storage.

Parameters:

• localFilePath: Path to the file to upload

Example prompt:

"Upload /path/to/app.apk to TestingBot"

uploadRemoteFile

Upload a file from a remote URL to TestingBot storage.

Parameters:

• remoteUrl: URL of the file to upload

Example prompt:

"Upload https://example.com/app.ipa to TestingBot"

getStorageFiles

List all files in TestingBot storage.

Parameters:

• offset (optional): Pagination offset (default: 0)
• limit (optional): Number of files to retrieve (default: 10, max: 100)

Example prompt:

"Show me all uploaded apps"

deleteStorageFile

Delete a file from TestingBot storage.

Parameters:

• appUrl: The app_url of the file to delete

Example prompt:

"Delete app tb://app123 from storage"

App Automate — Maestro

Run Maestro flows on TestingBot real devices, emulators, and simulators. Runs are asynchronous: start one, poll its status, then fetch results — the agent is never blocked while devices execute.

uploadMaestroApp

Upload the app under test (.apk, .aab, .ipa, or zipped .app). Uploads are deduplicated by checksum — re-running with the same binary is instant.

Parameters:

• localFilePath: Local path to the app file

Returns a Project ID used by the other Maestro tools.

Example prompt:

"Upload ./build/app.apk for Maestro testing"

uploadMaestroFlows

Upload the Maestro flow YAML files for a project. Accepts a directory (structure preserved, so runFlow subflows keep working), a pre-built .zip, or inline YAML written by the agent. Replaces previously uploaded flows.

Parameters:

• projectId: Project ID from uploadMaestroApp
• flowsPath (optional): Directory or .zip of flow YAML files
• flows (optional): Inline flows as [{ fileName, content }]

runMaestroTest

Start a Maestro run. Returns immediately with the run ID — poll with getMaestroRunStatus.

Parameters:

• projectId: Project ID
• platformName: "Android" or "iOS"
• deviceName (optional): Device name, wildcards/regex supported (e.g. "Pixel 8", "iPhone 1[4-6]", "*")
• version (optional): OS version
• realDevice (optional): Run on a physical device (required for .ipa)
• name (optional): Run name shown in the dashboard
• env (optional): Environment variables passed to the flows
• includeTags / excludeTags (optional): Filter flows by Maestro tags
• shardSplit (optional): Split flows across parallel devices
• otherApps (optional): Up to 4 companion app URLs to install alongside the app
• tunnelIdentifier (optional): Run through this tunnel, so the app can reach localhost / private backends

Example prompt:

"Run my Maestro flows on a real Pixel 8 with Android 14"

getMaestroRunStatus

Poll run progress. Lists per-flow statuses (WAITING, READY, DONE, FAILED, CANCELLED), failures first.

getMaestroRunResults

Final results of a completed run: per-flow outcomes plus the JUnit XML report.

getMaestroFlowDetails

Deep-dive into one flow: error messages, step-level JUnit report, and links to the video, screenshots, and device logs. This is the debugging tool — fetch it for a failed flow, fix the YAML, then retry.

Parameters: projectId, runId, flowId

cancelMaestroRun / retryMaestroRun

Cancel a running run, or retry a run — pass flowId to retry only a single failed flow.

uploadMaestroCompanionApp

Upload a supplementary app installed alongside the app under test. Returns a tb:// URL for runMaestroTest's otherApps.

listMaestroProjects / listMaestroRuns

Discover existing projects (app, flows, run IDs) and runs across the account. listMaestroRuns accepts a buildName to look up runs by name — e.g. "rerun whatever failed in last night's nightly build".

maestroCheatSheet

Returns a Maestro YAML syntax reference (commands, selectors, flow structure, and the TestingBot workflow). Agents call this before writing or fixing flows.

Example workflow:

User: "Run the Maestro flows in ./flows against ./app.apk on a real Pixel 8. Fix any failures."
Assistant: [uploadMaestroApp → uploadMaestroFlows → runMaestroTest]
Assistant: [polls getMaestroRunStatus until complete]
Assistant: [getMaestroFlowDetails for the failed flow, reads the error + screenshots]
Assistant: [fixes the flow YAML, uploadMaestroFlows, retryMaestroRun]

App Automate — Espresso & XCUITest

Run pre-built Espresso (Android) and XCUITest (iOS) suites on TestingBot devices. Same async pattern: start, poll, fetch results.

uploadAppAutomateApp

Upload the app under test: .apk/.aab for Espresso, .ipa for XCUITest.

Parameters: framework ("espresso" or "xcuitest"), localFilePath

uploadAppAutomateTests

Upload the test suite: the instrumented test .apk for Espresso, or the zipped XCUITest runner bundle.

Parameters: framework, projectId, localFilePath

runAppAutomateTest

Start a run. Returns immediately with the run ID.

Parameters:

• framework, projectId
• deviceName, version, realDevice, name, build (optional): device selection and metadata
• testClasses, skipTestClasses, packages, annotations, testRunner (optional, Espresso only): test filtering
• locale, timeZone (optional)

Example prompt:

"Run the Espresso suite on a real Galaxy S23, only the com.example.LoginTest class"

getAppAutomateRunStatus / getAppAutomateRunResults

Poll run progress, then fetch per-run outcomes and the JUnit XML report. Each run's Appium session ID is surfaced, so getTestDetails / getFailureLogs work for logs and video.

Screenshot Testing

takeScreenshot

Take screenshots of a URL across multiple browsers and platforms.

Parameters:

• url: The URL to screenshot
• browsers: Array of browser configurations
  • browserName: Browser name (chrome, firefox, safari, etc.)
  • version (optional): Browser version or "latest"
  • os: Operating system (WIN11, MAC, etc.)
• resolution (optional): Screen resolution (default: "1920x1080")
• waitTime (optional): Seconds to wait before screenshot (default: 5, max: 60)
• fullPage (optional): Capture full page or viewport (default: false)

For a localhost / private URL, the screenshots go through the account's newest running tunnel. If no tunnel is running, the tool says so instead of taking the screenshots.

Example prompt:

"Take a screenshot of https://example.com on Chrome and Firefox" "Screenshot my homepage on mobile devices"

retrieveScreenshots

Retrieve screenshot results by screenshot ID.

Parameters:

• screenshotId: The screenshot ID from takeScreenshot

Example prompt:

"Get screenshots for job abc123"

getScreenshotList

Get a list of all screenshot jobs.

Parameters:

• offset (optional): Pagination offset (default: 0)
• limit (optional): Number of jobs to retrieve (default: 10, max: 100)

Example prompt:

"Show me my recent screenshot jobs"

User Management

getUserInfo

Get current user account information including minutes used, plan details, and limits.

Example prompt:

"Show my account information" "How many minutes have I used?"

updateUserInfo

Update user account information.

Parameters:

• firstName (optional): First name
• lastName (optional): Last name
• email (optional): Email address

Example prompt:

"Update my email to newemail@example.com"

Team Management

getTeam

Get team information including concurrency limits, allowed parallel VMs, and mobile concurrency.

Example prompt:

"Show my team information" "What are my team's concurrency limits?"

getUsersInTeam

List all users in your team with their roles and access levels.

Parameters:

• offset (optional): Pagination offset (default: 0)
• limit (optional): Number of users to retrieve (default: 10, max: 100)

Example prompt:

"Show me all team members" "List users in my team"

getUserFromTeam

Get detailed information about a specific team member by user ID.

Parameters:

• userId: The user ID to retrieve

Example prompt:

"Show details for user 12345"

Chrome DevTools Protocol (CDP)

createCdpSession

Create a Chrome DevTools Protocol session for advanced browser automation. Returns a WebSocket URL to connect to the browser.

Parameters:

• browserName: Browser name (chrome, firefox, safari, edge, etc.)
• browserVersion (optional): Browser version or "latest" (default: latest)
• platform: Operating system platform
• screenResolution (optional): Screen resolution (e.g., "1920x1080")
• name (optional): Session name
• build (optional): Build identifier

Example prompt:

"Create a CDP session on Chrome latest with Windows 11" "Start a CDP session on Firefox 120 for automation"

Tunnel Management

TestingBot's browsers and devices run in the cloud. To test localhost, private IPs or intranet sites, they need a TestingBot Tunnel running on your machine. These tools can start one for you.