Zendesk for StartupsUp to 2 years free for startups + AI Agents & Copilot
Promoted
QApilot is an AI-native, autonomous testing platform purpose-built for mobile applications, helping teams create, execute, and maintain tests with far less manual effort.
It combines intelligent agents, context-aware automation, and mobile-first infrastructure to deliver faster test coverage, resilient automation, and greater release confidence.
This is the 2nd launch from QApilot. View more
QApilot MCP for Android
Launching today
QApilot MCP automates tests on real Android devices and emulators by talking to Claude, Cursor or Codex. Describe a test flow in plain English, no Appium code required.
Your agent lays out the steps. QApilot runs the steps. It finds the elements, waits for the screen to settle, retries when something moves, and caches what it learns so repeat runs are faster. Every pass saves a Gherkin feature file and becomes a replayable test case.
Needs Node, Java and the Android SDK.
Free Options
Launch Team / Built With
TestMu AI
QApilot
Hey Product Hunt!
I am Charan. Thrilled to bring QApilot MCP to you. → https://qapilot.io/mcp/guide
Android app testing inside your AI client. You describe what needs to hold in plain English, and it runs on a device or emulator connected to your machine.
The specifics:
Android only. iOS is next.
Native Android apps. Hybrid and WebView aren't supported yet.
Local device or emulator.
Tested configs for Claude Desktop, Cursor and Codex.
You'll need Node, Java, the Android SDK, and Appium running locally.
Why an MCP?
Coding agents made mobile code cheap to write. They did nothing for verifying it, so the bottleneck just moved. A mobile lead put it well: "by the time your report reaches me, I've merged three more PRs." Our testing wasn't wrong. It was happening too late, in a tool he never opened. MCP is how we moved it into his editor.
What it does
You tell your agent what needs to hold: "verify checkout still works after this refactor." It lays out the steps; QApilot finds the actual element behind "Checkout" on a real Android screen, waits for it to settle, retries when something moves, and says so honestly when it can't.
You get a verdict, a live browser preview, and files on disk: YAML, JSON steps, Gherkin on pass. Accept a run and it becomes a test case you can replay by ID, in batch, or from Excel. It caches what it learns per app, so it gets faster the more you use it.
The part we care most about
It runs on your machine. Your app, your screenshots and your runs don't get uploaded. Only your account and the test cases you explicitly save go to QApilot. Most tools here force every run through their cloud behind a tunnel, and for a lot of teams that's an immediate no. We didn't want to build that.
If you build Android apps with a coding agent, I'd like to know what you still check by hand before every merge. That's what shapes where this goes next.
Happy to answer anything in the comments.
QApilot
Hey Product Hunt,
I'm Surendranath. I work on the QApilot MCP, mostly on the parts that decide whether a decision is trustworthy.
Charan covered why we built this. I'll tell you where the work actually went, because "agent taps on cart“ is the easy 20% and it's already free in a few places.
Three things are hard, and we’ve naturally decided to jump on them:
Resolving an element from a fuzzy name. Your agent says "tap Checkout." On a real Android screen that could be a label inside a nested container, a button with no content description, or one of three things containing that string. Getting from intent to the correct node, repeatedly, on someone else's app, is unglamorous and it is most of what we do.
Knowing when the screen has finished changing. The naive version is a sleep, which is why so much mobile automation is flaky. Acting one frame too early is the single biggest source of false failures, and a test that lies to you is worse than no test, because you learn to ignore it.
Retrying without laundering a real failure. Retry logic that hides genuine breakage is how you ship a bug with a green check. So we retry on movement and re-render, and when we can't do the step we say so instead of guessing.
One design decision worth flagging: On a brand new app your first session is a cold start, and your agent explores like anyone else's would. It earns the speedup over a few runs.
And it runs locally against the device already connected to your machine. That was an engineering preference before it was a privacy one: no tunnel, no mandatory upload step, no waiting on a queue in someone's cloud.
Limits: native Android only right now, so hybrid and WebView are out. iOS is next.
And deciding what should hold before a merge is still your judgment, not ours.
What I want from you: tell me where it gives you a wrong verdict, specifically a false pass. A false failure annoys you, but a false pass is the thing that gets shipped. Those reports go to the top of my list.
I'll be in the comments and available in the Slack channel - https://join.slack.com/t/qapilotmcp/shared_invite/zt-4a0dag17k-XxOoyGlYrT55NrVOdHnQ1A
Observer
Hey PH! Vidushee here. I am one of the makers of the QApilot MCP.
I wanted to add a few things that make this different from just pointing an agent at a phone, along with some honest caveats.
Your agent decides what to do; QApilot does the part that's hard on mobile - finding the real element behind "Checkout" in a live UI tree, and waiting for the screen to actually settle instead of guessing a sleep.
It caches what it learns per app from passing runs, so it gets faster the more you use it. And it all runs on your machine; your app is never uploaded.
Setup is the rough edge today. You need Node, Java, the Android SDK and Appium running before anything happens, and that's the next thing we're cutting down after iOS.
If there's something you'd want ahead of either, say so here - much easier to reorder this week than in three months.
Thanks!
Retro Y2K Theme
curious about the "plain language" part. i sometimes mess up what to say when trying to get the right retro look for a site, so if this can interpret some nonsense and still spit out a working test, i'd give it a shot. but i might forget to open the emulator. 😂
QApilot
@cepeshrc - Haha, messy input is mostly fine. It reads the actual screen, so "the button that takes you to checkout" works even if you don't know what it's called. Vague about what to verify is where it struggles more than vague wording. As long as the intent is communicated, you are set.
And it'll tell you straight away if there's no device connected, so the emulator thing sorts itself out. 😄
i can't imagine writing a test in plain language and having it actually get the idea right. would prob be like my reddit replies, where i wing it and hope for the best. but if it nails it on the first try, then maybe i'd stop winging it so much.
QApilot
@therayess - Winging it works better than you'd think. It reads the screen first, so it's matching your words against what's actually there. And when it can't tell what you meant, it stops and says so rather than guessing.
So roughly: better than a Reddit reply, worse than a spec. Somewhere in the middle is fine :)
QApilot
Hey Product Hunt. I am Aakash, part of the team that built QApilot MCP.
Adding a bit more on what this actually does.
You describe an Android test in plain English inside Claude, Cursor or Codex. It runs on a device or emulator connected to your machine, and you watch it happen in a live browser preview. You get a verdict, plus YAML and Gherkin files on disk. Accept a passing run and it becomes a test case you can replay later.
Android only today, iOS next. Everything runs locally, so your app never leaves your machine.
Happy to answer anything in the thread.
QApilot
Hey PH! Nihad here, one of the makers behind QApilot MCP.
We built QApilot because we wanted mobile testing to fit into the same workflow as AI-assisted development. Instead of switching between your editor, test tools, and a device, you can describe what you want to verify in plain English and let your agent run it on a real Android device or emulator.
There’s a lot we want to improve, but getting QApilot MCP out there and into developers’ hands is a big step for us. If you work with Android testing, I’d genuinely love to hear what you think, especially what still feels painful in your current workflow.
Thanks for checking us out and supporting the launch