Until today, DemoBro's demobro-plugin-mobile (Appium-based mobile testing) only
existed as a REST API. If you wanted to drive it from an AI agent — Claude,
Cursor, VS Code Copilot, anything speaking MCP — you were out of luck.
Not anymore. Four new tools just landed on the DemoBro MCP server:
register_mobile_app— register a local.apk/.aab(Android) or.ipa/zipped.app(iOS) binary for testing.create_mobile_flow— script a scenario in a small, safe YAML DSL:wait_for,tap,type,swipe,screenshot,back,sleep.start_mobile_test_run— install the binary on a real emulator/simulator, run the flow, record a video, capture screenshots.get_mobile_test_run— poll status, progress, and results.
Ask your agent something like "register this build, tap through the login flow, and show me a screenshot of the dashboard" — it now just works.
Built on the same billing rails as everything else
Mobile test runs are billed exactly like our other render plugins (Blender,
3D product): 25 credits per run, gated behind the same plugins plan
feature. Nothing bespoke, nothing to learn twice.
And because a flaky emulator or a bad build shouldn't cost you credits, every
run that ends in FAILED triggers an automatic, idempotent refund — the
same signal-driven pattern we use for regular demo renders. We didn't just
write that logic, we watched it fire for real: two failed runs, two refunds,
25 credits back both times, confirmed against the live ledger.
We didn't just ship it — we stress-tested it on real infra
Before calling this done, we spun up a real cloud test rig and ran the whole pipeline against it, twice, on both platforms:
- iOS: real Appium 3.2.2 + XCUITest driver + an actual iPhone 17 simulator (iOS 26.5), running locally — no mocks.
- Android: a fresh Azure VM (
Standard_D4s_v5, KVM-accelerated), a real Android 14 emulator, Appium 3.6.0 — fully booted and ready to accept sessions in about 90 seconds from a cold container start. - A real open-source test app (Appium's own
ApiDemos-debug.apk, checksum-verified) was installed, launched, and driven through a fullwait_for → screenshot → swipe → screenshotflow — with a real screenshot to prove it, not a log line we're asking you to trust.
Found and fixed two blockers along the way
Stress-testing against real infrastructure surfaced two latent bugs that would have blocked any real upload through this feature — a missing default file-storage backend, and a file path that could silently overflow the database column on longer filenames. Both are now fixed, so the feature isn't just new — it's the first time it has ever actually worked end to end.
What's next
- URL-based app binaries, so a remote worker doesn't need to share a disk with the emulator it's driving.
- Android emulator fleets on demand, the same way we already scale render workers.
Get in the beta
Mobile testing via MCP is rolling out as a closed beta, invitation-code gated — same access model as the rest of early access DemoBro. We're onboarding a first batch of teams to shake out real-world flows (multi-step logins, deep navigation, flaky network conditions) before opening it wider.
Want in?
- Email us at bro@demobro.com with your use case (Android, iOS, or both) and we'll send you an invitation code.
- Already have a DemoBro account? Ask for the mobile-testing beta flag when you write in — we'll flip it on your plan directly.
Try it: point any MCP-capable agent at DemoBro and ask it to test your app.