Docs / Guide: Appium & LambdaTest

Appium, Selenium and LambdaTest through mcpgate

An AI client such as Claude Code drives a test device with your own Appium or Selenium client. mcpgate adds two connectors: LambdaTest for the results of your test runs, and WebDriver for single steps inside a session that is already running. This guide shows which part does what.

The parts

Your own Appium or Selenium client starts the session and drives the device. The LambdaTest connector reads and manages your test runs. The WebDriver connector acts inside the same session, addressed by its id.

Part	Runs where	What it does	Credential
Your Appium or Selenium client	Your computer	Starts the session. Taps, swipes, reads the screen.	Your grid user name and access key
LambdaTest connector	mcpgate	Reads and manages test runs on LambdaTest (TestMu AI).	OAuth, per user
WebDriver connector	mcpgate	Finds an element, types into it, taps it, in a running session.	Your grid user name and access key, per user

The LambdaTest connector

The connector gives your AI client the hosted LambdaTest MCP server of TestMu AI (formerly LambdaTest), through mcpgate. In October 2026 the server has 88 tools; LambdaTest can add or change tools at any time:

Test runs: builds, sessions, the command, network, console and Selenium logs, screenshots and videos.
Analytics: flaky tests, test trends, errors, concurrency.
Real devices and apps: the device list, app uploads, capabilities for a mobile test.
HyperExecute: jobs, stages, tasks, logs and artifacts.
SmartUI: visual comparisons and baselines.
Test Manager: projects, test cases, test runs and milestones, and links to Jira issues.

Each user signs in on accounts.lambdatest.com with the method of their account: a password, Google or SSO. mcpgate registers itself as a client at LambdaTest, so the operator creates no OAuth app.

mcpgate treats a tool that deletes, stops or changes a build, a session, an app or a Test Manager record as a destructive write. If the operator turns on the approval policy for such writes, mcpgate holds the call for approval. The policy is off by default. An accessibility scan and an app analysis through a tunnel start new work, so mcpgate serves them as writes too.

The WebDriver connector

The connector speaks W3C WebDriver to a hub that the operator names. The protocol is the same on every grid and on your own Appium or Selenium server, so one connector covers all of them.

The connector does not start or drive a test. It acts inside a session that your own client started, addressed by the session id:

Action	Kind	WebDriver endpoint
`find_element`	read	`POST session/{session_id}/element`
`send_keys`	write	`POST session/{session_id}/element/{element_id}/value`
`click`	write	`POST session/{session_id}/element/{element_id}/click`

find_element takes a locator strategy and a locator. On Appium these are for example accessibility id, id, xpath, -android uiautomator or -ios predicate string. On a browser session they are css selector or xpath. The answer has the element id for send_keys and click.

Why a step goes through mcpgate

mcpgate shows the model a token such as ⟦EMAIL_1:ma•••@example.com⟧ in place of personal data, for example the email address of a test account in a Jira ticket. If the model tells your local Appium client to type the token, the device gets the token, and the login fails. Your Appium client does not go through mcpgate, so nothing puts the real value back.

send_keys is a write through mcpgate. Before a write leaves the gateway, mcpgate puts the real value in place of each token. The steps:

The AI client reads the ticket through mcpgate and gets ⟦EMAIL_1⟧.
Your Appium client starts the session and taps to the login screen. The AI client gets the session id.
The AI client calls find_element for the login field, then send_keys with ⟦EMAIL_1⟧ as the text.
mcpgate puts the real address into the call and sends it to the same session at the hub.
The device gets the real address. The model still sees only the token.

Part	What it sees
The model	The token only
Your Appium client	No personal data: the session, the taps, the swipes
mcpgate	The real value: it replaces it for the model and puts it back for the hub
The device	The real value

The same gap exists for local files and commands. A local vault, such as the one in maisecrets, puts the real value into a local Write, Edit or Bash call. It does not put a value into the arguments of a local MCP server. For a device, use send_keys.

Set up

LambdaTest (operator): nothing to set up. Each user connects LambdaTest on the connections page of mcpgate and signs in.
WebDriver (operator): set “WebDriver hub URL” to the hub that your testers’ clients use, with its path. For LambdaTest real devices this is https://mobile-hub.lambdatest.com/wd/hub. For BrowserStack it is https://hub-cloud.browserstack.com/wd/hub. For your own Appium server it is for example http://appium.example.com:4723.
WebDriver (each user): enter your grid user name and access key on the connections page. Use the pair that your own Appium or Selenium client uses. On LambdaTest, both are under Account Settings → Password & Security.

Limits

The WebDriver connector never starts a session. Your own client starts it and gives the session id.
Three actions only: find_element, send_keys and click. Your own client does every other step.
Each user acts with their own pair. A user who stored no user name and access key gets an error. mcpgate never uses a shared or a server-wide account for this connector.
The connector does not check who owns a session. A cloud grid limits sessions to their account. Your own Appium server without accounts does not.

Both connectors are in the service catalog.