Ein npx-Aufruf startet einen Prozess, der sich als MCP-Server ausgibt und auf Anfrage die Accessibility-Struktur eines laufenden iOS-Simulators oder Android-Emulators zurückliefert. Das Projekt mobile-next/mobile-mcp verbindet damit Sprachmodelle und Agenten mit Mobilgeräten, ohne dass für jede Plattform eigener Code geschrieben werden muss. Die Steuerung eines Telefons wird damit zu einer Aufgabe, die ein Modell übernehmen kann. Die Beschreibung im Repository ist nüchtern: skalierbare mobile Automatisierung über eine plattformunabhängige Schnittstelle.
Der Server läuft lokal, spricht mit Simulatoren, Emulatoren und echten Geräten und gibt sich gegenüber dem Agenten als Sammlung von Werkzeugen aus, die nach gewöhnlichen Verben benannt sind: installieren, starten, tippen, wischen, auslesen. Der Agent muss nicht wissen, wie iOS oder Android intern funktionieren, er muss nur wissen, was er erreichen will. Wie dieser MCP-Server funktioniert, wofür er gedacht ist und wo die Grenzen liegen, schauen wir uns im Folgenden an.
Ein Reiseadapter zwischen Agent und Gerät
Wer eine App auf einem iPhone automatisiert, landet früher oder später bei XCUITest und Swift, für Android bei Espresso und Kotlin. Zwei Werkzeugketten, zwei Denkweisen, zwei Sorten von Fehlermeldungen, in die man sich einarbeitet. Der MCP-Server von Mobile Next setzt hier an und bietet eine einzige, plattformunabhängige Oberfläche. Aus Sicht des Agenten ist es gleichgültig, ob dahinter ein Google Pixel, ein Samsung-Gerät oder ein Simulator auf dem eigenen Rechner steht.
Das funktioniert wie ein Reiseadapter für Steckdosen: Das Gerät, das du anschließt, bleibt dasselbe, nur die Form des Anschlusses ist kein Problem mehr. So läuft ios android automatisierung mit diesem Server — der Agent beschreibt eine Absicht, die Übersetzung in die jeweilige Plattformsprache passiert im Hintergrund. Für dich heißt das: Du lernst einmal eine Handvoll Werkzeuge kennen und nutzt sie über alle Ziele hinweg. Kein XCUITest, kein Espresso, kein plattformspezifischer Klebstoff, den jemand pflegen muss.
Sobald die Schnittstelle stabil ist, lassen sich Abläufe beschreiben statt programmieren. Ein Agent kann eine Anmeldung durchspielen, ein Formular ausfüllen, einen Warenkorb befüllen oder eine Fehlermeldung reproduzieren, ohne dass jemand dafür Testcode schreibt.
Accessibility-Baum statt Screenshot
Der wichtigste technische Unterschied zu vielen anderen Ansätzen liegt darin, wie der Server ein Gerät wahrnimmt. Er liest nicht in erster Linie Pixel, sondern den Accessibility-Baum der laufenden App. Das ist die strukturierte Beschreibung aller Bedienelemente, die das Betriebssystem ohnehin für Screenreader bereitstellt: Textfelder, Schaltflächen, Listen, deren Position und Eigenschaften. Der Agent arbeitet damit mit echten Elementen und deren Koordinaten, statt ein Bild zu interpretieren, und braucht dafür kein Vision-Modell. Das spart Zeit und Token, weil keine Bilddaten durch das Modell müssen. Die Ausgabe ist außerdem deterministisch: Dasselbe Element hat denselben Namen, dieselbe Rolle, dieselbe Position. Wo ein reiner Screenshot-Ansatz bei jedem Lauf neu raten muss, kann der Agent hier gezielt zugreifen.
Manche Oberflächen zeichnen sich selbst und tauchen im Accessibility-Baum kaum auf, etwa Spiele, Karten oder individuell gerenderte Canvas-Flächen. Für solche Fälle greift der Server auf Screenshots und Koordinaten zurück. Für mobile scraping heißt das: Texte und Listen aus nativen Apps lassen sich als Daten extrahieren, solange die App ihre Oberfläche korrekt beschreibt.
Vier Ziele und ihre Voraussetzungen
Der Server deckt vier Betriebsarten ab. Der iOS-Simulator läuft über xcrun simctl und verlangt Xcode mit einem gestarteten Simulator. Ein echtes iPhone muss per USB angeschlossen und am Gerät als vertrauenswürdig bestätigt sein. Der Android-Emulator setzt das Android SDK sowie einen laufenden Emulator voraus, echte Android-Geräte brauchen adb, aktiviertes USB-Debugging und eine am Gerät bestätigte Autorisierung. In allen vier Fällen sprechen dieselben Werkzeuge mit dem Ziel, nur der Transportweg unterscheidet sich.
Auf der Rechnerseite brauchst du die Xcode-Kommandozeilenwerkzeuge, die Android Platform Tools, Node.js ab Version 20 und einen MCP-fähigen Klienten, also etwa Claude Code, Codex, Gemini, GitHub Copilot, Cursor oder eine andere MCP-kompatible Anwendung. Fehlt eines davon, bleibt die Geräteliste meist einfach leer. Der erste sinnvolle Test nach der Einrichtung ist deshalb die Frage an den Agenten, welche Geräte verfügbar sind. Erscheinen die laufenden Simulatoren, Emulatoren und angeschlossenen Telefone, ist die Verbindung in Ordnung.
Wer nicht auf der eigenen Maschine bleiben will, kann denselben Satz von Werkzeugen gegen echte Geräte in der Cloud richten. Dafür gibt es Werkzeuge zum Anmelden beim Anbieter, zum Auflisten verfügbarer Gerätemodelle, zum Reservieren eines physischen Geräts für exklusive Nutzung und zum Freigeben danach. Der Zugriff läuft über Streamable HTTP, ist zustandslos und kommt damit ohne Sitzungsaffinität aus, was ihn für CI-Umgebungen und horizontale Hosts interessant macht. Für den Agenten ändert sich dabei nichts: gleiche Werkzeuge, kein lokaler Aufbau.
Was die Werkzeuge konkret abdecken
Bei der Geräteverwaltung geht es ums Grobe und ums Feine. Der Agent kann verfügbare Geräte auflisten, die Bildschirmgröße in Pixeln abfragen, die aktuelle Ausrichtung lesen und ändern, den gemeldeten GPS-Standort überschreiben oder löschen und die Zwischenablage lesen oder ersetzen. Der Standort ist für Tests interessant, die von regionalen Daten abhängen, die Zwischenablage für alles, was mit Einfügen und Übertragen zu tun hat. Notizen und Kalendereinträge landen dort, wo man sie erwartet.
Die App-Verwaltung folgt demselben Muster. Installierte Apps lassen sich auflisten, die App im Vordergrund lässt sich ermitteln, ein Start über den Paketnamen ist möglich, ebenso das Beenden, Installieren aus einer Datei im Format .apk, .ipa, .app oder .zip und das Deinstallieren. Damit lässt sich ein reproduzierbarer Ausgangszustand herstellen. Danach beginnt die eigentliche Interaktion: Screenshots aufnehmen oder speichern, Elemente samt Koordinaten auflisten, an einer Stelle klicken, doppeltippen oder lange drücken, in jede Richtung wischen, die Bildschirmaufzeichnung starten und stoppen.
Dazu kommen Eingabe und Navigation: Text in ein fokussiertes Feld schreiben, optional mit Absenden, Hardwaretasten wie HOME, BACK, LAUTER, LEISER oder ENTER drücken, URLs im Gerätebrowser öffnen. Dazu Diagnosewerkzeuge, die Live-Logs vom Gerät sammeln, also logcat unter Android und das vereinheitlichte Log unter iOS, verfügbare Absturzberichte auflisten und einen Bericht im Volltext herausgeben. Ein Sammelwerkzeug erlaubt es, mehrere Schritte in einem Aufruf hintereinander auszuführen, etwa klicken, tippen, klicken, und am Ende die Bildschirmelemente gleich mitzuliefern. Das reduziert die Zahl der Hin-und-Her-Runden zwischen Modell und Gerät.
Installation zwischen Claude Code, Cursor und Codex
Die Einrichtung ist bewusst langweilig gehalten. In den meisten Klienten genügt dieselbe Konfiguration:
{"mcpServers":{"mobile-mcp":{"command":"npx","args":["-y","@mobilenext/mobile-mcp@latest"]}}}Je nach Werkzeug gibt es zusätzlich einen kurzen Befehl in der Kommandozeile, etwa bei Claude Code, Codex, der Gemini CLI oder dem Copilot-CLI, oder einen Knopf zum Installieren wie bei Cursor und Goose. Andere Umgebungen wie Amp, Cline, Kiro, opencode, Windsurf und Antigravity erwarten die Eintragung in ihrer jeweiligen Konfigurationsdatei. Im Kern steht immer derselbe Aufruf von npx. Läuft der Server standardmäßig über die Ein- und Ausgabe des Prozesses, lässt er sich mit dem Schalter --listen auch als HTTP-Dienst starten und an eine bestimmte Adresse binden. Der HTTP-Modus nutzt inzwischen Streamable HTTP auf dem Pfad /mcp, der frühere SSE-Transport ist abgelöst.
Was das für die Praxis bedeutet
Für Teams, die mobile app testing betreiben, ändert sich vor allem der Aufwand für den Einstieg. Statt für jeden Testfall eine Plattformimplementierung zu pflegen, beschreibt man Abläufe und lässt sie ausführen. Das eignet sich für wiederkehrende Routinen wie Registrierung, Login, Bestellvorgang oder Datenimport, aber auch für Erkundung: Ein Agent kann eine App durchklicken und dabei Logs und Abstürze sammeln, was sonst mühsame Handarbeit ist. Für mobile scraping mit MCP-Server gilt dasselbe in eine andere Richtung, nämlich Daten aus nativen Apps herausziehen statt hineinschreiben.
Die Grenzen sollte man trotzdem kennen. Der Accessibility-Baum ist nur so gut wie die App, die ihn füllt; schlampig beschriftete Schaltflächen oder selbst gezeichnete Oberflächen zwingen den Agenten auf den Koordinatenweg, und der ist fragiler, weil sich Layouts mit jeder Bildschirmgröße verschieben. Ein Agent auf einem echten Gerät hat außerdem dieselben Rechte wie ein Mensch, der es bedient, inklusive Zugriff auf eingerichtete Konten und Nachrichten. Wer das produktiv einsetzt, sollte Zielgeräte trennen und Tests nicht auf dem privaten Telefon der Entwicklerin laufen lassen. Die Automatisierung von iOS und Android war bisher zwei Probleme. Jetzt ist es eines.
Quelle: github.com
