mcp-appium
Enables automation and inspection of Android applications via Appium, including element discovery, screen analysis, and interaction with UI components.
Allows connecting to an existing Appium server session to inspect and interact with mobile applications, providing tools for UI hierarchy analysis, element location, screenshots, and user actions like tapping and typing.
Enables automation and inspection of iOS applications via Appium, including element discovery, screen analysis, and interaction with UI components.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-appium Suggest robust locators for the save button on this screen"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-appium
Un assistant qui écrit des tests mobiles invente des sélecteurs. Il propose
accessibility_id=bouton_valider parce que c'est ce qu'un développeur aurait
écrit, et le test échoue parce que l'application expose autre chose.
Ce serveur MCP lui donne l'écran réel.
pip install mcp-appiumCe qu'il fait
Onze outils, exposés à l'assistant via le Model Context Protocol :
Outil | Rôle |
| Se rattache à une session Appium déjà ouverte |
| L'arbre de l'écran, simplifié ou brut |
| Recherche par sélecteur ou par texte |
| Des sélecteurs qui existent, classés par robustesse |
| Attributs, position, état d'un élément |
| L'écran, réduit avant envoi |
| Clic, avec vérification que l'écran a bougé |
| Saisie dans un champ |
| Retour arrière |
| Plateforme, appareil, identifiant de session |
| Libère l'appareil, si ce serveur a ouvert la session |
Android, iOS, iPadOS et Windows.
Related MCP server: Autonomo MCP
Le cas courant : observer une session existante
Un test tourne, il échoue sur un élément. Tu demandes à l'assistant ce que l'écran contient vraiment.
connect_to_session()Sans argument, le serveur cherche une session active sur
http://127.0.0.1:4723 et s'y rattache. Il ne crée rien, ne redémarre rien,
et aucune configuration n'est nécessaire.
C'est le mode à privilégier : l'assistant voit exactement ce que le test voit, au moment où il le voit.
Créer une session
Si aucune session n'existe, le serveur peut en ouvrir une. Il lui faut alors des
capabilities, déclarées dans appium-caps.json à la racine de ton projet :
{
"platformName": "Android",
"automationName": "UiAutomator2",
"appPackage": "com.exemple.app",
"appActivity": ".MainActivity"
}Les clés sont préfixées par appium: automatiquement quand il le faut.
Plusieurs plateformes dans le même fichier :
{
"android": { "platformName": "Android", "automationName": "UiAutomator2", "appPackage": "com.exemple.app" },
"ios": { "platformName": "iOS", "automationName": "XCUITest", "bundleId": "com.exemple.app" }
}La variable MCP_APPIUM_PLATFORM choisit laquelle. À défaut, la première
déclarée. Deux autres variables existent : MCP_APPIUM_CAPS pour passer le JSON
directement, et MCP_APPIUM_CAPS_FILE pour désigner un autre fichier.
Déclarer le serveur
Dans VS Code, .vscode/mcp.json :
{
"servers": {
"appium": {
"type": "stdio",
"command": "mcp-appium"
}
}
}Le format est le même pour les autres clients MCP : une commande, transport standard.
Le parti pris qui compte : borner les sorties
Un arbre de vue Appium brut dépasse couramment les cinquante mille caractères. Envoyé tel quel, il sature la fenêtre de contexte du modèle avant de lui avoir appris quoi que ce soit. Pire : ce qui entre dans le contexte y reste, et se repaie à chaque échange suivant de la conversation.
Toutes les sorties sont donc plafonnées, et le serveur le dit quand il coupe :
arbre simplifié à 400 lignes, avec les seuls attributs qui servent à cibler ;
source brute à 40 000 caractères ;
15 éléments détaillés au maximum dans une recherche ;
captures réduites à 1280 pixels de large.
Un outil d'inspection qui ne borne pas ses sorties est inutilisable en conversation, quelle que soit la qualité de ce qu'il expose.
Deux autres partis pris
Un tap vérifie son effet. tap_element compare l'écran avant et après, et
signale explicitement un clic resté sans conséquence. Un élément désactivé ou
recouvert répond à click() sans rien faire : sans cette vérification,
l'assistant croit avoir avancé et enchaîne dans le vide.
Une session ne se ferme que si on l'a ouverte. close_session libère
l'appareil quand le serveur a créé la session, et se contente de s'en détacher
sinon. Fermer la session d'un test en cours couperait ce test.
suggest_locators classe par robustesse. L'identifiant d'accessibilité
d'abord, le XPath sur le texte en dernier, avec la mention qu'il cassera au
prochain changement de libellé.
Ce qu'il ne fait pas
Il n'écrit pas de tests et n'impose aucun framework. Il expose l'état de l'application, l'assistant fait le reste avec les outils que tu utilises déjà.
Il ne dépend d'aucun service d'IA. Ni clé d'API, ni compte, ni appel sortant : le seul réseau qu'il touche est ton serveur Appium local.
Il ne remplace pas Appium Inspector pour l'exploration manuelle. Il sert à donner ces informations à un modèle, ce qu'une interface graphique ne sait pas faire.
Compatibilité
Python | 3.10 et plus |
SDK MCP | 2.0 et plus |
Appium | 2 et 3 |
Plateformes | Android, iOS, iPadOS, Windows |
Le SDK MCP 2 a renommé FastMCP en MCPServer : le code écrit pour la version 1
ne fonctionne pas avec celle-ci, et inversement. La contrainte est donc
volontairement stricte.
Licence
MIT.
Available Tools
11 toolsclose_sessionA
Ferme la session, mais uniquement si ce serveur l'a créée.
Une session ouverte par un test appartient à ce test : la fermer couperait l'exécution en cours. Le rattachement se contente donc d'oublier la session, qui continue de vivre.
Inputs: no named parameters. Returns: result
connect_to_sessionA
Se connecte à un serveur Appium en cours d'exécution.
Si session_id est fourni, se rattache à cette session.
Sinon, tente de trouver une session active.
Si aucune session n'existe et create_if_needed=True, crée une nouvelle session avec les capabilities du projet.
Args: appium_url: URL du serveur Appium (défaut: http://127.0.0.1:4723) session_id: ID de session Appium existante (optionnel) create_if_needed: Si True, crée une session si aucune n'existe
Inputs: appium_url, session_id, create_if_needed. Returns: result
find_elementsB
Recherche des éléments dans l'application.
Args: locator: Le locator à chercher. Exemples : - "//*[@content-desc='MonBouton']" (XPath) - "accessibility_id=MonBouton" - "id=com.exemple.app:id/mon_bouton" - "predicate=label == 'Valider'" (iOS) - "MonTexte" (recherche par texte dans tous les attributs) strategy: "auto" (détection automatique), "text_search", ou une stratégie explicite : xpath, accessibility_id, id, name, class, android (uiautomator), predicate, class_chain.
Inputs: locator (required), strategy. Returns: result
get_element_infoA
Récupère toutes les informations d'un élément (texte, position, taille, attributs, visibilité, cliquabilité...).
Args: locator: Locator de l'élément (XPath, accessibility_id, id, etc.)
Inputs: locator (required). Returns: result
get_page_sourceA
Récupère l'arbre XML de l'écran actuel. C'est l'équivalent du DOM pour une application native.
Args: simplified: Si True, retourne une version allégée avec seulement les attributs utiles (type, text, label, content-desc, accessibility_id, bounds, enabled, visible). Si False, retourne le XML brut complet.
Inputs: simplified. Returns: result
get_session_infoA
Retourne les informations de la session Appium en cours : plateforme, capabilities, taille d'écran, etc.
Inputs: no named parameters. Returns: result
go_backA
Appuie sur le bouton retour (Android/Windows).
Inputs: no named parameters. Returns: result
screenshotA
Prend une capture de l'écran actuel et la renvoie pour analyse. Une copie est aussi écrite dans le répertoire temporaire du système.
Inputs: no named parameters.
suggest_locatorsA
Cherche un élément par texte/description et suggère les meilleurs locators Robot Framework pour le cibler (du plus stable au moins stable).
Utile pour : "quel locator utiliser pour le bouton Valider ?"
Args: text_or_description: Texte visible, label, ou description de l'élément.
Inputs: text_or_description (required). Returns: result
tap_elementA
Tap ou clic sur un élément de l'application.
Args: locator: Locator de l'élément à cliquer. verify: Si True, compare l'écran avant/après et signale un tap sans effet (coûte deux lectures du page source).
Inputs: locator (required), verify. Returns: result
type_textC
Saisit du texte dans un champ de l'application.
Args: locator: Locator du champ de saisie. text: Texte à saisir.
Inputs: text (required), locator (required). Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 11 tools
Most tools are clearly distinct: session management, element lookup, and actions. Minor overlap exists between get_page_source/screenshot and find_elements/get_element_info, but descriptions make the differences clear.
All tool names follow a consistent snake_case verb_noun pattern (connect_to_session, get_page_source, type_text, find_elements, etc.). go_back is a phrasal verb but matches the style.
11 tools is well-scoped for an Appium MCP server. Each tool serves a clear purpose in session management, element inspection, or interaction, with no redundant or unnecessary entries.
Core workflows like connecting, inspecting, tapping, typing, and navigating back are covered. However, common mobile interactions such as swipe, scroll, long press, and wait-for-element are missing, which could block typical automation flows.
Maintenance
Related MCP Connectors
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
Let your AI agent control real iPhones: screenshots, tap, swipe, type and open apps.
Give AI agents a real cloud Chrome: open sessions, navigate, read pages, click, type and screenshot.
remote debug iOS/Android/Unity/Godot/Flutter/RN/Web on real-device.ui-tree/screenshots/taps,tests.
Related MCP Servers
AlicenseAqualityAmaintenanceEnables AI assistants to automate mobile app testing and development for iOS and Android through natural language interactions. Supports intelligent element identification, session management, automated test generation, and comprehensive device interactions including clicks, swipes, screenshots, and app management.3214,478 npm518Apache 2.0- FlicenseNot gradedqualityDmaintenanceGives AI coding assistants live, structured access to running apps' state and UI elements, enabling real-time verification and interaction across web, mobile, and desktop.36-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to inspect and verify mobile UI hierarchies, nodes, styles, screenshots, and runtime attributes of iOS apps in simulators or on USB devices.252 npm2Apache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to remotely control, debug, and automate real browsers, iOS simulators, and Android emulators, including navigation, element inspection, interaction, screenshots, and mobile gestures.27 npmMIT