🔗 github.com/dkmostafa/app-automating What it is app-automating is an open-source MCP server that gives an AI agent real control over Android — emulators and physical devices alike. It does three things: Manages the AVD environment. Create, boot, rename, stop and delete emulators. Download system images. List what's attached. No Android Studio, no clicking through a GUI — the agent owns the device lifecycle. Drives the screen. Tap, type, swipe, scroll, press keys, take screenshots, read the view hierarchy. Anything a finger can do, through Appium. Remembers how it got there. Every interaction records itself automatically, so the agent can ask "how do I get from the home screen to checkout?" instead of rediscovering the route on every run. That third one is the part that doesn't exist elsewhere. Most tooling in this space is a thin wrapper over adb — it gives a model hands but no memory, so every session starts from zero. 28 tools, three modules: android_ (10) for the device lifecycle, appium_ (13) for the screen, navigation_memory_ (5) for the map. Where it fits It's deliberately not a testing framework. It's a capability layer — the agent decides what the job is. You want to The agent does Test an app Boots a clean emulator, installs the build, walks the flows, screenshots what broke Scrape a mobile-only app Navigates to the data, reads the view hierarchy, pages through results Reproduce a bug Replays a recorded route to the exact screen, every time Explore an unfamiliar app Maps the screens it finds and builds a navigation graph as it goes Automate a repetitive chore Anything you'd otherwise do by hand, thirty times If the task involves an Android screen and you'd rather describe it than script it, this is the layer underneath. Built with Pure Python at the core — the server itself is a remote control for other people's tools, and it stays out of their way. Layer Stack MCP server FastMCP over STDIO — no sockets, deliberately Device control Appium + the uiautomator2 driver Emulator control The Android SDK directly: adb, emulator, avdmanager, sdkmanager Navigation memory SQLAlchemy + aiosqlite — one local SQLite file, no service to run Schemas & config Pydantic v2 + pydantic-settings Tooling Python 3.12+, uv, pytest, ruff Under that, the codebase is four-layer Clean Architecture — one vertical slice per module, dependencies pointing inward, and an architecture test in every module that walks the AST and fails the build on a layer violation. More on that later in the post. How it works