MCP Appium - Mobile Development and Automation Server

Open a new tab in the real Chromium window the user is in, optionally navigated to a URL. This is your primary tool for "go look at a website" — it does literally what a person does when they Cmd+T and type a URL. The page loads with full JavaScript, cookies, redirects, and captchas just like for a human. New tabs open in the background by default so the user's view doesn't get yanked; the AI's "active tab" follows the new one. Use this for: web search (always via http://localhost:8484/search?q=…, never google.com directly), opening a specific site the user mentioned, opening a result link from a previous search.

Show a person how to do something on a website: an animated spotlight, a pointing arrow and a caption walk them through it step by step on the real page. Use when the user says "show me how…", "where do I…", "walk me through…", "guide me". Default mode "guided" points and explains — the person clicks/types themselves, and the tour advances on their click, their input, or navigation; pressing Next does the step's action for them (never into password/payment/one-time-code fields), and Back undoes a step that navigated. Mode "demo" performs the steps itself, slowly, with a visible cursor. Guided calls return waiting:true with a tourId when the person is still busy; call again with `resume` to keep waiting, or `stop` to end it. Tours always run where the person can see them: a headless session is reopened in a visible browser first (same page, cookies and localStorage), and the call fails if no visible browser can open.

Press a keyboard key or key combination on the AI's active tab — same as a human pressing it. Use Enter to submit a form after typing in a search box, Tab to advance focus, ArrowDown to scroll suggestions, etc. Supports modifiers (Control, Shift, Alt, Meta).

Reload the current page. Only works with Playwright web sessions.

Drive the AI's active tab through a sequence of steps in one call, like a human would. Survives page navigations (form submits no longer abort the rest of the script) and falls back to a humanised, hidden-element-revealing path only when the normal fast path fails — useful for modals/menus that a plain click cannot reach. Returns per-step results; on a failing step it stops and hands back a `continuationId` you can pass as `resume` to pick up where it left off after you adjust. Prefer this over chaining many single-action tools when a flow (login, multi-field form, open-menu-then-click) should run as one human-like unit. An upload step puts local files into a file input or the file picker a button opens.

Select an option from a <select> dropdown element. Provide value, label, or index. Only works with Playwright web sessions.

Change which existing open tab the AI is acting on. By default this does NOT change what the user sees — the user's foreground tab stays put — it only retargets subsequent playwright_* calls. Pass bringToFront=true to also surface the tab in the user's window (only do this if the user explicitly asked to be shown that tab).

Type text into a real input field, exactly the way a human types — character by character with optional inter-key delay. Use this for search boxes, sign-in forms, contenteditable elements, or anywhere `set_value` would skip JS-driven autocomplete/validation. Targets either a specific element (by UUID from appium_find_element) or whatever the active tab currently has focused.

What the user did in their own browser (clicks, field changes, Enter, form submits, page loads, new tabs) since you last looked. Attached to the user's Chrome only. Use it to work together in one tab: ask the user to do a step (log in, pick something, approve a 2FA prompt), then call this with waitSeconds to see when and what they did. Every other tool result also starts with this report when there is something new. Password and card fields never show values.

Select a specific device from available LOCAL devices. For LOCAL Appium servers ONLY. DO NOT use this tool for REMOTE Appium servers - remoteServerUrl indicates a remote server. WORKFLOW FOR LOCAL SERVERS: - Use this tool ONLY when select_platform returns multiple devices - For Android: Use before calling create_session if multiple devices are found - For iOS: Use before calling boot_simulator or create_session if multiple simulators/devices are found - Ask the user which device they want to use from the list provided WORKFLOW FOR REMOTE SERVERS: - SKIP this tool entirely - Device selection should be handled via capabilities in create_session (e.g., appium:deviceName, appium:udid) - The remote Appium server is already configured for specific device(s)

Select the platform for LOCAL servers ONLY. DO NOT use this tool if the user mentions a REMOTE Appium server URL (e.g., http://localhost:4723, http://192.168.1.100:4723, or any other server address). WORKFLOW FOR LOCAL SERVERS: 1. First, ASK THE USER which platform they want to use (Android, iOS, or Web) 2. You MUST explicitly prompt the user to choose between Android, iOS, or Web 3. DO NOT assume or default to any platform 4. For Android/iOS: After platform selection, available devices will be listed 5. If multiple devices are available, use select_device to let the user choose 6. After device selection, proceed to create_session 7. For Web: No device selection needed, proceed directly to create_session WORKFLOW FOR REMOTE SERVERS: If user provides a remote server URL, SKIP this tool entirely. Instead, infer the platform and device type from the user's request (e.g., 'ios xcuitest driver with iphone 17 simulator' means platform='ios') and call create_session directly with the remoteServerUrl parameter.

Set an existing Appium session as the active session for subsequent tool calls.

Download and setup prebuilt WebDriverAgent (WDA) for iOS/tvOS simulators only (not for real devices). This significantly speeds up the first Appium session by avoiding the need to build WDA from source. Downloads the latest version from GitHub and caches it locally.