Debugging Mobile Tests with Appium MCP [Testμ 2026]

The Case for an Official Server

Community Appium MCP servers already exist, so the session opens by answering why an officially built one earns its place.

The answer is the pain points the pair keep meeting while travelling with the project: documentation, building and signing WebDriverAgent for iOS, generating locators, and writing gestures.

Srinivasan Sekar calls the WebDriverAgent build one of the hardest and most painful parts of Appium, and says plainly that he still fails at it at times. That is why the server handles signing, installing and preparing an iOS device rather than leaving it to you.

The maintenance trap he describes will be familiar to anyone running a mobile suite. Time goes into generating locators, identifying elements and negotiating with developers to add accessibility identifiers, rather than into deciding what is worth automating at all.

Agents already carry public training data about Appium. Their claim is narrower and more defensible: debugging goes faster and lands more often when the agent has Appium-specific tools built in.

MCP in One Protocol

Their definition is compact: one open standard made of tools, resources and prompts, described as USB-C connectors for AI agents talking to external systems.

The architecture is client and server. The server advertises its capabilities to a client such as Claude Code, Cursor or VS Code Copilot, and the model behind that client decides when to use what.

One detail matters for anyone worried about tool sprawl: clients now load MCP tools dynamically rather than holding them all in memory, which is why a server with eighty-plus tools still functions. The speakers are quick to say that is not a licence to ship eighty.

Two transports get covered, standard input/output running the process on your own machine and streamable HTTP, alongside newer stateless servers. A single client can hold several servers at once, so Appium MCP sits comfortably beside a GitHub or filesystem server, and it spans Android, iOS and Mac across real devices, emulators and simulators.

The Documentation Problem

This is the most relatable problem in the session and the least glamorous fix.

Appium’s documentation spans more than a hundred repositories, of which they reckon only ten to fifteen are actively maintained and relevant. Checking Google the day before the session, they found an older documentation version outranking the current release.

The community forum compounds it, because answers there are pinned to specific Appium versions and the same problem was solved differently in each.

Their fix is retrieval rather than curation: chunk the documentation, index it, and let a retriever pull the relevant pieces into the model at query time.

Shipping it as a separate opt-in package is a deliberate design call with three reasons, and the third is the interesting one. Docs release on their own cadence, the chunks inflate package size, and every extra tool makes the agent’s decision harder, because fewer tools make for better choices.

No Standalone Server

Classic Appium is client and server: you start an Appium server, then write tests against a Java client, a Ruby client, WebdriverIO or another binding.

Appium MCP bundles the drivers instead, UiAutomator2 for Android and XCUITest for iOS, so no standalone server needs starting for local execution.

A local real-device run drives through the installed UiAutomator2 driver under the hood, with the package handling the rest. Cloud execution takes the same flow, spinning up a server and reaching remote machines through the grid mechanism.

From 80 Tools to 33

The project started as a lightning-talk demo and had grown past eighty tools a year ago, which both speakers describe as an anti-pattern they walked into themselves.

It now ships 33, and the live tool listing on stage confirmed roughly that count.

The pattern they name and reject is vendors shipping one MCP tool per API endpoint, which Srinivasan Sekar calls the very worst way to ship an MCP server.

Tools are shaped around user intent instead. Gestures are one tool covering scroll up, scroll down, left, right and double tap, because the intent is a gesture even though the underlying endpoints differ. A separate actions tool remains for anyone building custom W3C Actions sequences.

Plugins let teams add their own tooling on top while inheriting the common plumbing, and the authenticated remote server the pair maintain outside the Appium organisation was built that way as a reference.

Opening Settings

The first demo prompt is deliberately bare: open the settings app using the Appium MCP server. No device named, no package name, no tool specified.

The trace is what makes it interesting. The agent called a device-selection tool first and chose the already-booted Android emulator because nothing iOS was connected, then created a session and surfaced the session ID, which shows the MCP managing the session lifecycle itself.

To launch Settings it worked out that it needed the package name, fetched it, and reached for the app lifecycle tool rather than a specific activate-app endpoint. That is the intent-based design showing up in a real run rather than on a slide.

It then took two or three screenshots to confirm Settings was actually open, and that verification loop became the session’s cost lesson. Full-resolution images pushed into the session ran to roughly 13,000 to 14,000 tokens, against roughly 2,000 or fewer for the same goal through their own optimised agent. Both numbers are their own measurements rather than independent benchmarks.

Ranked Locators

The sample project is an ordinary TypeScript repository running WebdriverIO against a demo app on an emulator, and Sai Krishna says twice that it is a sample rather than a best-practice reference.

Asked for locators across the home, login and success screens, the agent noticed the app was already in the foreground and skipped re-activating it. With no credentials supplied it invented its own test data to reach the success state the prompt required.

The output is one file per screen, each element carrying a best locator plus alternates, including a biometric hint on the login screen.

Ranking is built in per platform. For iOS the order runs accessibility ID, resource ID, class chain, iOS predicate, XPath, then class name, which is the kind of preference most teams hold informally and inconsistently.

Where nothing better existed the output degraded gracefully rather than silently: one label fell back to a deprecated selector strategy, with XPath listed underneath as the next alternative rather than promoted to the pick.

Breaking a Locator

Asked to generate the tests as well, the agent produced spec files alongside the locator files, and Sai Krishna pruned the result live, deleting a land-on-home-screen test he calls useless along with others he did not need.

The kept test enters a username and password, waits for the title and asserts a successful login.

He then deliberately corrupted the email input locator and ran the suite, which started the Appium server and failed to find the element. The traditional recovery is opening an inspector, or reasoning over the application source if you have access to it.

Handing the failing run to the agent instead produced two fixes rather than one. It restored the correct input locator, and it flagged missing navigation, reusable code he had deleted during the pruning, and wrote it back into the test.

Asking the Docs Tool

The documentation query is deliberately scoped: how do I run this test on multiple devices in parallel, answer only, no code changes.

Srinivasan Sekar frames the value around discoverability, noting Appium carries hundreds of capabilities most people never find, and joking that the maintainers do not hold them all in their heads either.

The tool reported finding 25 relevant documentation chunks and the model rendered the answer as a table, naming the per-session capabilities that must be unique and, because the project uses WebdriverIO, showing it as an array of devices with a unique system port, UiAutomator2 port and chromedriver port each.

A second query asked which capabilities let Appium use a WebDriverAgent you have already built while avoiding the Xcode signing path, which is exactly the question the earlier pain point sets up.

Tools Are Not an Agent

The most useful idea in the session is a boundary, and it recurs whenever someone asks the server to be smarter than it is.

That division explains their position on auto-healing. It is technically possible and belongs behind a guardrail, because a failing locator may be reporting a real defect and healing it silently hides the reason.

Their cautionary observation is sharper than the principle: they have watched an agent go past the test and modify the mobile application’s own code base, rebuilding it locally, rather than fixing the locator. Agents also reach outside the tool list, sometimes issuing raw device commands that are not Appium MCP tools at all.

Where reliability actually comes from, in their account, is the agent layer, which is why they built one of their own on top: reduced-quality rather than degraded screenshots, fetching only interactable elements instead of a page source that can run to ten pages, and markdown app guides telling the agent where hidden features live, such as an archive action behind a swipe.

Q & A Session

The workshop took eleven audience questions. The six with the widest application are below.

• How do you handle authentication and sensitive data with a hosted model?

  Srinivasan Sekar: Do not use a hosted model. If you are concerned about any LLM seeing your data, run an open model on your own machine, supply that model’s token in the MCP server configuration, and drive Appium with it. Because inference is local, the data never leaves the machine.

• What is the biggest challenge to making autonomous mobile QA reliable at scale?

  Srinivasan Sekar and Sai Krishna: Any strong model works, and you actually need two kinds, a reasoning model and a vision model. Vision matters because React Native, Flutter and Compose apps often fail to expose a clean accessibility tree with usable identifiers, so vision lets you assert on things you cannot locate, such as counting icons beside a piece of text.

• Can it stream live device screenshots to a vision model?

  Sai Krishna: Yes, there is a screenshot tool, but for anything seamless do not go screenshot by screenshot. Start Appium with the MJPEG server capability and stream instead: by their measurements a normal screenshot takes roughly 200 to 300 milliseconds while streaming takes around 20, with fewer tokens and the option to shrink the frame.

• How do you stop provisioning failures breaking WebDriverAgent in CI?

  Sai Krishna: WebDriverAgent is a test server rather than an app, so building and signing it inside every pipeline run costs time and breaks whenever a provisioning profile is misconfigured. Pre-build the IPA once as a separate preparation stage that need not live in your test code, then tell Appium it already exists.

• What happens when the WebDriverAgent certificate expires?

  Srinivasan Sekar and Sai Krishna: A free Apple account expires in seven days and an enterprise account lasts a year. If it expires, the tooling removes WebDriverAgent and tries to rebuild, and that rebuild still fails, because it cannot distinguish a valid certificate from an invalid one. Supplying a valid certificate is the user’s responsibility; neither Appium nor Appium MCP will fetch one.

• In a Flutter app with infinite scroll, can the agent keep scrolling until it finds an element?

  Sai Krishna: Doable, and it splits along the same boundary as everything else. The MCP does the scrolling; deciding whether to scroll further or whether the element has appeared is the agent’s job. You have to instruct it and cap the maximum number of scrolls, or it will run forever.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.