QApilot MCP for Android - Android app testing inside your coding agent

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.

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

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!

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

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.

Is there any mechanism that detects UI drift between various versions of applications in the element-caching?
Btw, Congratulations @charan_tej_kammara @aakash_balu & team @QApilot 🎊.

@charan_tej_kammara Congrats on the launch ! This looks like a useful tool for mobile app testing. Is iOS support on the roadmap?

This is a really smart use of MCP. Love that the tests run locally on the actual device instead of sending everything through the cloud. Congrats on the launch Charan!

It is great to see am app dedicated to android apps. There are so many that focus on ios it is refreshing to see android getting attention. Although I am not a mobile app developer (yet) I am an android user so kobe seeing this.

I also like the ease of use being able to use plain language.

One question, does it work with other coding agents (in particular I use opencode so would be interested in an opencode config).

Good luck with the launch.