🔗 github.com/dkmostafa/app-automating
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:
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.
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.
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.