Frequently asked questions

MCP servers are LLM-agnostic, which means they work with any LLM model that supports the Model Context Protocol.

The TestingBot MCP server works with Claude Desktop, Claude Code, Cursor, VS Code (Copilot/MCP), Windsurf, and any MCP-compatible client that can launch a stdio server. One-click installers are available for VS Code (https://testingbot.com/mcp/install?client=vscode) and Cursor (https://testingbot.com/mcp/install?client=cursor), and Claude can install the bundled .mcpb from the GitHub releases page. For any other client, use the standard JSON config shown on the Setup page.

No. All browsers, emulators, simulators and real devices run on TestingBot's cloud. The only local requirement is Node.js 18+ (20+ recommended), which runs the MCP server itself via npx -y @testingbot/mcp-server@latest. Browser and mobile automation are handled by the bundled @testingbot/automation-mcp package, which drives remote sessions over WebDriver, you do not install Appium, Selenium, Chrome or any device tooling on your machine.

No, the MCP server does not send any information to an LLM. It's the LLM that is requesting information from the MCP server. The MCP server will perform API calls to the TestingBot API.

When you log in with the tb_login tool, your TestingBot key and secret are written to ~/.testingbot/credentials, an INI file with profile sections such as [default]. The directory is created with 0700 permissions and the file with 0600, so only your user account can read it. Credentials never leave your machine: they are used only by the MCP server to call the TestingBot API directly, and are never passed to the LLM provider. See Authentication for full details.

TestingBot MCP is a local server you connect to your AI assistant (Claude, Cursor, VS Code, etc.) so it can manage your TestingBot account and drive real cloud browser and mobile sessions through natural language. TestingBot WebMCP is a separate, in-browser approach. If you want your coding assistant or AI agent to interact with TestingBot's infrastructure, this MCP server is what you want.

There are three options. The easiest is to run the tb_login tool, which opens a browser login (loopback) on a desktop or prints a short device code for remote/headless setups, no key is ever pasted. Alternatively, set TESTINGBOT_KEY and TESTINGBOT_SECRET in your client's env block (get them at https://testingbot.com/members/user/edit). The server resolves credentials in this order: environment variables (both must be set), then the credentials file, then degraded mode. See Authentication.

That message means the server is running in degraded mode: it found no usable credentials in the environment or the credentials file, so every tool except tb_login is disabled. Run the tb_login tool to authenticate, or set TESTINGBOT_KEY and TESTINGBOT_SECRET in your client config. On SSH or headless hosts, use the device-code flow, see Troubleshooting.

Use the device-code flow by running tb_login with mode set to device. It prints a short code; open https://testingbot.com/device in any browser, enter the code and click Authorize. The flow is resumable, if it times out, just run tb_login again to finish. The default auto mode already falls back to device login on headless machines.

Emulators (Android) and simulators (iOS) are virtual devices, they are cheaper and plentiful, so they are great for functional checks and CI. They are the default: tb_openBrowser with a deviceName and platform of Android or iOS uses realDevice:false. Set realDevice:true when you need physical hardware, real GPU, sensors and the real Chrome or Safari engine. Browse all available hardware at https://testingbot.com/device. You can also list devices through the agent with the getDevices tool.

When you request a real device with realDevice:true and that device or OS version is busy or not offered, tb_openBrowser runs a pre-flight check and returns guidance without starting (and billing) a session. The agent can then wait and retry, pick an available OS version it suggests, or fall back to an emulator/simulator. See Use cases for the full workflow.

Yes. Every automation session returns a live-view URL in the form https://testingbot.com/tests/<sessionId>/live?auth=<hash>. Open it in your browser to watch the session in real time and interact with it directly when you need to step in.

Account and management actions, listing tests, fetching results, reading logs, managing builds or storage, do not consume testing minutes. Live and automation sessions do: opening a browser or device session (for example with tb_openBrowser or a live session tool) uses minutes while it runs. Close sessions with tb_closeBrowser when finished; idle sessions also auto-close. Use tb_listSessions to see what is currently open.

Yes. For CI and headless environments, provide credentials through environment variables instead of the interactive login. Set TESTINGBOT_KEY and TESTINGBOT_SECRET in the env block of your MCP config:

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

Get your key and secret at https://testingbot.com/members/user/edit. If you cannot use env vars, the device-code login flow also works on remote hosts.

You can share the MCP config block itself (command and args), but each member should supply their own credentials. For shared or CI configs, an API key/secret in the env block is the most portable option. For local desktop use, each member runs tb_login once and credentials are written to their own ~/.testingbot/credentials file. You can keep multiple sets of credentials side by side using profile sections and the TESTINGBOT_PROFILE environment variable. Team-level details (members, usage) are available through the getTeam and getUsersInTeam tools, see the Tool reference.