# Mobilebox

> Mobile Sandboxes, controllable by your agents. API + MCP first. Android 14 arm64 virtual phones; your agent supplies the reasoning.

## Start
- [Quickstart](https://mobilebox.dev/docs/index.md): Runnable Node lifecycle and authentication.
- [Agent guide](https://mobilebox.dev/skill.md): Observe, act, verify, park.
- [API reference](https://mobilebox.dev/docs/reference.md): REST endpoints, exact limits and response semantics.
- [Errors](https://mobilebox.dev/docs/errors.md): Recovery and partial failures.
- [OpenAPI](https://mobilebox.dev/openapi.json): REST schemas including the shared action vocabulary.

## Reading
- [Give your coding agent an Android sandbox over MCP](https://mobilebox.dev/blog/android-agent-mcp): Add the remote MCP server to Claude Code or Cursor, see every phone tool, run a bounded first task and know what is proven.
- [Does this task need a phone or a browser?](https://mobilebox.dev/blog/native-app-or-browser): Choose the smallest runtime that can actually complete the task: HTTP, browser, or native Android.
- [Mobilebox or Mobilerun: where do the agent and the phone run?](https://mobilebox.dev/blog/mobilebox-vs-mobilerun): Compare Mobilebox’s hosted Android API and MCP with Mobilerun’s framework, coding-agent harness, hosted agent and cloud phones.
- [Mobilebox or Appium for Android automation?](https://mobilebox.dev/blog/mobilebox-vs-appium): Separate a managed phone runtime from a test automation framework before choosing your Android stack.
- [Android, E2B, Browserbase: which sandbox fits?](https://mobilebox.dev/blog/android-vs-agent-sandboxes): Compare execution surfaces and state, rather than treating every agent sandbox as interchangeable.
- [Why your agent tapped the wrong thing](https://mobilebox.dev/blog/screen-refs-and-recovery): Understand stale screen references, choose stable targets, and recover without repeating side effects.
- [Batch the steps you know. Observe the ones you don’t.](https://mobilebox.dev/blog/batch-android-actions): Build bounded Android action batches, inspect partial failure, and verify the resulting screen.
- [Install APKs and split bundles over an API](https://mobilebox.dev/blog/install-apk-split-bundles): Upload APK bytes or install by URL, handle arm64 split bundles, and diagnose update failures.
- [Keep the login. Stop the running phone.](https://mobilebox.dev/blog/park-resume-android): Understand what park and resume preserve, what restarts, and when to delete an Android sandbox.
- [Put a budget around your Android agent](https://mobilebox.dev/blog/android-sandbox-costs): Use idle timeouts, session caps, account balance, and session records to control phone runtime costs.
- [Timezone, locale, GPS and IP are four different inputs](https://mobilebox.dev/blog/locale-location-proxy): Configure an Android sandbox for regional workflows without confusing locale or GPS with network egress.
- [A successful tap is not a successful task](https://mobilebox.dev/blog/verify-agent-workflows): Design Android agent checks around outcomes, screen evidence, failure traces, and safe cleanup.
- [Screenshot or accessibility tree? Choose the evidence your agent needs](https://mobilebox.dev/blog/screenshot-vs-accessibility-tree): Choose structured Android observations for labels and state, screenshots for pixels, and synchronized evidence when both matter.
- [Run an APK smoke test from CI without a local emulator](https://mobilebox.dev/blog/android-apk-ci-smoke-tests): A complete Node script and GitHub Actions job that installs an APK on a remote Android sandbox, checks its first screen and deletes the phone even when the check fails.
- [Mobilebox or BrowserStack: agent runtime or device lab?](https://mobilebox.dev/blog/mobilebox-vs-browserstack): Compare an agent-facing Android sandbox with a real-device Appium testing workflow, using documented responsibilities instead of rankings.
- [Mobilebox or Genymotion: compare the Android control surface](https://mobilebox.dev/blog/mobilebox-vs-genymotion): Compare device provisioning, ADB-based toolchains, agent actions and the exact persistence semantics of your chosen Android workflow.
- [Give each agent a key. Keep the workspace boundary clear.](https://mobilebox.dev/blog/android-api-key-security): Understand project-wide API-key access, browser sessions, safe rotation and the difference between a named key and an isolated project.
- [Treat Android permission dialogs as part of the test](https://mobilebox.dev/blog/android-permission-dialogs): Handle real consent and denial screens, choose runtime permission pre-grants deliberately and keep special permissions separate.
- [Will this Android app work in a virtual sandbox?](https://mobilebox.dev/blog/android-app-compatibility): Check APK architecture, exposed UI, device services, physical features and attestation before promising a particular app workflow.
- [Fresh install, app restart, park or delete? Choose the right reset.](https://mobilebox.dev/blog/fresh-vs-persistent-sandboxes): Distinguish process state, saved app data, installed packages and remote records before resetting or retaining an Android sandbox.
- [How to evaluate an Android agent without grading its own story](https://mobilebox.dev/blog/android-agent-evaluations): Define testable outcomes, separate environment and control failures, include recovery cases and retain evidence for every attempt.
- [A timeout does not mean the tap never happened](https://mobilebox.dev/blog/retry-mobile-actions-safely): Reconcile phone creation, inspect partial action batches and check side effects before retrying an uncertain Android operation.
- [The locale changed. Why is the app still in English?](https://mobilebox.dev/blog/debug-android-localization): Debug system locale, per-app language, installed translations, server content and timezone as separate inputs to a localization test.
- [What leaves the phone when your agent reads the screen?](https://mobilebox.dev/blog/android-agent-data-boundaries): Map credentials, model inputs, screenshots, traces and CI artifacts so the evidence you keep matches the task you need to judge.

MCP endpoint: https://mobilebox.dev/mcp (stateless Streamable HTTP; Authorization: Bearer API_KEY). Public discovery does not authenticate the client. Never put keys in prompts.