--- title: MCP FAQ | TestingBot MCP description: 'Frequently asked questions about the TestingBot MCP server: supported AI clients, data privacy, authentication, emulators vs real devices, minutes usage, CI and security.' source_url: html: https://testingbot.com/support/ai/mcp/faq md: https://testingbot.com/support/ai/mcp/faq/index.md --- # Frequently asked questions Answers to the most common questions about the [TestingBot MCP server](https://testingbot.com/support/ai/mcp): how it works with different AI assistants, how your data is handled, how authentication and billing work, and the difference between testing on emulators and real devices. If you are just getting started, see the [Setup & installation](https://testingbot.com/support/ai/mcp/setup) guide, the [Authentication](https://testingbot.com/support/ai/mcp/authentication) guide and the full [Tool reference](https://testingbot.com/support/ai/mcp/tools). Looking for in-browser, page-side AI tooling instead of the local MCP server? See [TestingBot WebMCP](https://testingbot.com/support/ai/webmcp), a different product. This page covers the local [TestingBot MCP server](https://testingbot.com/support/ai/mcp). ## General Questions about which AI clients the server works with and what you need installed locally. ### Is this MCP server compatible with various AI models or specific to a particular provider? MCP servers are LLM-agnostic, which means they work with any LLM model that supports the Model Context Protocol. ### Which MCP clients are supported? 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](https://testingbot.com/support/ai/mcp/setup). ### Do I need to install Appium, browsers or device emulators locally? 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. ## Privacy & security How your prompts, data and credentials flow between your AI client, the MCP server and TestingBot. ### Is the information that I feed through MCP used to train? 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. ### Where are my credentials stored, and is it secure? 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](https://testingbot.com/support/ai/mcp/authentication) for full details. ### What is the difference between TestingBot MCP and WebMCP? 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](https://testingbot.com/support/ai/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. ## Authentication How the server signs in to TestingBot and how to provide credentials in different environments. ### How does authentication to TestingBot happen? 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](https://testingbot.com/support/ai/mcp/authentication). ### Why do the tools reply "No TestingBot credentials configured. Run the tb\_login tool"? 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](https://testingbot.com/support/ai/mcp/troubleshooting). ### The browser login did not open, I am on SSH or a remote host. What do I do? 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. ## Devices & sessions How emulators, simulators and real devices differ, and how to watch or take over a live run. ### What is the difference between an emulator/simulator and a real device? 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. ### A requested real device is unavailable or busy, what happens? 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](https://testingbot.com/support/ai/mcp/use-cases) for the full workflow. ### Can I watch or take over a session the agent is running? Yes. Every automation session returns a live-view URL in the form `https://testingbot.com/tests//live?auth=`. Open it in your browser to watch the session in real time and interact with it directly when you need to step in. ## Usage, CI & teams Questions about billing, continuous integration and sharing the configuration with your team. ### Does using the MCP server consume my TestingBot minutes? 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. ### Can I use the MCP server in CI or other automated environments? 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": "", "TESTINGBOT_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. ### Can team members share a single configuration? 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](https://testingbot.com/support/ai/mcp/tools). Still stuck? The [Troubleshooting](https://testingbot.com/support/ai/mcp/troubleshooting) guide covers common errors such as degraded mode, unavailable devices, screenshots that do not render in chat, and Node version issues. ## More resources - [TestingBot MCP overview](https://testingbot.com/support/ai/mcp), what it is and what it can do. - [Setup & installation](https://testingbot.com/support/ai/mcp/setup), install and configure your AI client. - [Authentication](https://testingbot.com/support/ai/mcp/authentication), browser login, device code and API keys. - [Tool reference](https://testingbot.com/support/ai/mcp/tools), every available tool and its parameters. - [Use cases & workflows](https://testingbot.com/support/ai/mcp/use-cases), example prompts and tool sequences. - [Troubleshooting](https://testingbot.com/support/ai/mcp/troubleshooting), fixes for common issues. ### Looking for more help? Have questions or need more information? Reach out via email or Slack. [Email us](https://testingbot.com/contact/new)[Slack Join our Slack](https://join.slack.com/t/testingb0t/shared_invite/zt-3bcw9xch-jk19~6XPs_xBrsAgAedkCw)