TestingOps.ai

Test execution · Execution provider · MCP tool for agents

BrowserStack and TestingOps: an agent tool and a policy-restricted runner

Your TestingOps agents can use BrowserStack's hosted MCP server as a tool once you sign in. Running TestingOps cases directly on BrowserStack Automate is a separate role, and the execution policy switches it off on testingops.ai.

  • Execution provider
  • MCP tool for agents
  • Available with limits
Request a demo BrowserStack remote MCP server
Connection
Execution provider, MCP tool for agents
Writes back
Runs on your provider account
Last checked
7 Nov 2026

In short

BrowserStack and TestingOps in short

BrowserStack appears in TestingOps in two separate roles.

As an MCP tool for agents, it lets your TestingOps agents call BrowserStack's hosted MCP server (real devices and browsers, accessibility checks and failure analysis) once you sign in with a BrowserStack account; the execution policy does not apply to it, and tool calls that BrowserStack marks as writing wait for approval first.

As a direct test runner, BrowserStack Automate is switched off on testingops.ai by the execution policy, which allows only RunningOps and manual runs, and it has never been run against a real BrowserStack account.

RunningOps lists BrowserStack among its own browser and device options, which are set up in RunningOps rather than in TestingOps.

What it does

What it does for your testing

  1. 1

    Agent tool: BrowserStack inside an agent's task

    Input
    A task that needs a real browser or device, an accessibility check or a look at a failure
    TestingOps
    The agent calls the tools BrowserStack's MCP server offers to your signed-in account
    Output
    The tool's answer inside the agent's task; nothing is imported into TestingOps by itself
  2. 2

    Agent tool: writes wait for approval

    Input
    A tool call that BrowserStack marks as writing or deleting, or whose name says it creates, updates or sends something
    TestingOps
    Holds the call and posts an Approve tool action card on the task with the exact arguments, valid for one hour
    Output
    The call runs once after approval, or not at all
  3. 3

    Direct runner: refused by the policy

    Input
    A run that asks for BrowserStack Automate on testingops.ai
    TestingOps
    The execution policy refuses it before any session opens, and the runner card shows only the policy note
    Output
    No BrowserStack session; test runs go through RunningOps

Step by step

How it works

  1. Agent tool: sign inUnder Integrations → API & MCP → Extra tools your agents may use, choose BrowserStack and select Continue to sign-in. You sign in on BrowserStack's own screen, and TestingOps registers itself with BrowserStack.
  2. Agent tool: tools are listedWhen you return, TestingOps lists the tools BrowserStack's server offers. By default all agents in scope can use them; read tools run directly and tools that write or delete ask first.
  3. Agent tool: agents call it while they workAn agent calls a BrowserStack tool when its task needs one. Each run gets a gateway token that lasts one hour and can only list and call tools; your BrowserStack sign-in stays on the server.
  4. Direct runner: switched offThe BrowserStack Automate card under Integrations → Project tools → Test execution shows "Disabled by execution policy: all runs go through RunningOps" and offers no form.

The two roles are independent. Signing in for the agent tool does not make BrowserStack a test runner, and the execution policy that switches off the runner does not apply to the agent tool.

Connect

Setup

  1. Agent tool: open Integrations → API & MCP, choose BrowserStack under Extra tools your agents may use and select Continue to sign-in.
  2. Sign in on BrowserStack's screen with the account whose plan your agents may use; when you return, its tools are listed for your agents.
  3. Leave write and delete tools on ask first; approvals appear as an Approve tool action card on the agent's task.
  4. Direct runner: there is nothing to set up on testingops.ai, because the execution policy switches it off.

Documentation: BrowserStack remote MCP server

Where you connect it in TestingOps: Integrations → API & MCP → Extra tools your agents may use → BrowserStack

Use cases

Use cases

Agent tool: look into a browser-specific failure

Trigger
A defect says a public page breaks in one mobile browser
Uses
BrowserStack's real browsers and devices through its MCP tools
Agent activity
Uses the BrowserStack tools to open the page in that browser and adds what it found to its task
Result
A defect analysis that includes the BrowserStack check
Condition
The hosted server cannot reach localhost or VPN-only environments, and calls use your BrowserStack plan's minutes

Agent tool: accessibility check before a release

Trigger
A release candidate of a public site is ready
Uses
BrowserStack's accessibility checks through its MCP tools
Agent activity
Runs the check through the tool and turns its findings into defects or test cases for review
Result
Accessibility findings in the team's usual defect flow
Condition
A tool that starts a check without being marked as writing runs without asking first

Runner: BrowserStack browsers and devices through RunningOps

Trigger
A team wants its TestingOps runs on BrowserStack browsers or devices
Uses
RunningOps' own BrowserStack options: Automate as a cloud browser, App Automate as a device provider
Agent activity
TestingOps sends the cases to RunningOps as usual, and RunningOps runs them on BrowserStack
Result
The run shows Provider · BrowserStack, as reported by RunningOps
Condition
Set up inside RunningOps; this path was not checked against a real BrowserStack account for this page

Capabilities

Capabilities and limits

What is read

  • Agent tool: what BrowserStack's tools return to the agent during a task; TestingOps does not import BrowserStack data by itself
  • Direct runner (switched off on testingops.ai): WebDriver session results and the plan's parallel-session limit

What is produced

  • Agent tool: tool results inside the agent's task, and whatever the agent writes from them, such as a defect
  • Direct runner: nothing on testingops.ai

Where it can write

  • Agent tool: sessions or tests on the signed-in BrowserStack account when an agent calls a tool that starts them; tools marked as writing or deleting wait for approval
  • Direct runner: nothing on testingops.ai; in code it opens WebDriver sessions and marks each session passed or failed through BrowserStack's REST API

How it connects

  • Agent tool: BrowserStack's hosted MCP server (mcp.browserstack.com) with BrowserStack's own sign-in; TestingOps registers itself with BrowserStack
  • Direct runner: BrowserStack's WebDriver hub and Automate REST API with a username and access key

Account and permissions

  • Agent tool: a BrowserStack account whose plan your agents may use
  • Agent tool: write approvals on a connection your organisation set up go to people with Manage integrations rights (the TestingOps team can approve too); tools that delete stay with the TestingOps team
  • Direct runner: username and access key, not accepted on testingops.ai

Limits

  • Agent tool: the hosted server cannot reach apps on localhost or behind a VPN
  • Agent tool: a tool runs without approval only when BrowserStack marks it read-only or its name says it reads; tools named run or start ask first
  • Agent tool: tools that are new or changed after a catalog refresh stay quarantined until someone with Manage integrations rights reviews them on the connection's row
  • Agent tool: the BrowserStack sign-in has not been tested end to end
  • Direct runner: switched off on testingops.ai by the execution policy (RunningOps and manual runs only)
  • Direct runner: needs structured browser steps that TestingOps does not produce, so AI-written cases would be refused; never run against a real BrowserStack account; App Automate settings cannot be entered in the runner form

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A support ticket reports that a sign-up form does not submit in one mobile browser. The team has connected BrowserStack as an agent tool.

The investigating agent uses the BrowserStack tools to open the public sign-up page in that browser, records the result in its task and drafts a defect for review. The form's regression cases keep running on RunningOps.

Frequently asked questions

Can I run my TestingOps test cases on BrowserStack Automate?

Not directly on testingops.ai. The execution policy there allows RunningOps and manual runs only, so the BrowserStack Automate card is switched off. The direct runner has also never been run against a real BrowserStack account, and it needs structured browser steps that AI-written cases do not have.

Is the BrowserStack agent tool affected by the execution policy?

No. The policy decides which runners execute test cases. The agent tool is a connection your agents call over MCP while they work, so it stays available.

What can agents do with the BrowserStack tool?

They can call the tools BrowserStack's hosted MCP server offers to your account, which cover real devices and browsers, accessibility checks and failure analysis. The exact tool list comes from BrowserStack and is shown after you sign in.

Do BrowserStack tool calls need approval?

Tools that BrowserStack marks as writing or deleting, or whose names say they create, update, send or delete, ask first: the agent waits, and the stored call runs once after approval. Tools that only start or run something without such a mark run without approval and use your plan's minutes.

Can the BrowserStack tool reach our staging environment?

Only if it is reachable from the internet. BrowserStack's hosted server cannot reach apps on localhost or behind a VPN.

Can RunningOps use BrowserStack?

RunningOps lists BrowserStack Automate as a cloud browser and BrowserStack App Automate as a device provider. Those are set up inside RunningOps, and TestingOps then shows the provider RunningOps reports for the run.

Next step

Tell us in a demo how your team uses BrowserStack today, and we will show what the agent tool can do and where your runs go.

Request a demoMore test execution integrations