Check that a phone is reachable and report what it is. Call this first if anything seems wrong. Connects over Wi-Fi automatically if it can.

Find phones that could be added: devices on your tailnet running the client app. This is the normal way to discover a phone.

ADB is only relevant while setting a phone up from this machine; use list_adb_devices if you specifically need that.

Phones reachable over ADB from this machine - cable or wireless debugging.

Only useful while setting a phone up locally. Day-to-day the phones are reached over the network, not ADB.

Pair with a phone over Wi-Fi, once, so no cable is needed afterwards.

On the phone: Settings > Developer options > Wireless debugging > 'Pair device with pairing code'. Pass the ip:port and the 6-digit code it shows. Note that the pairing port differs from the connection port.

Switch a cabled phone over to Wi-Fi so the cable can be unplugged.

Needs the phone plugged in for this one step, but no pairing code. Use this when the user wants to stop using the cable. It does not survive a phone reboot - pair_wireless does.

Connect to an already-paired phone over Wi-Fi. Use after the phone reboots or wireless debugging is toggled - the port changes each time, so this rediscovers it.

Drop the wireless connection. The pairing is remembered, so connect_wireless will reconnect without pairing again.

Read what is currently on the phone screen, as a numbered list of tappable elements. This is the main way to see the phone - call it before acting, and after anything unexpected.

Take a picture of the phone screen. Use this when get_screen doesn't show what you need - videos, games, photos, or custom-drawn interfaces.

Tap an element by its number from get_screen. This is the normal way to tap - the index comes straight from the last get_screen listing.

Tap the element whose label matches this text. Use when you know what the button says but not its index.

Tap an exact pixel position. Only use this when an element has no index - for example something you found in a screenshot.

Scroll the screen: 'down' to see what is further down the page, 'up' to go back, or 'left'/'right' to move between pages.

Type text into the field that is currently focused. Tap a text field first.

Press a hardware or system key. Common ones: back, home, recents, enter, delete, volume_up, volume_down.

Wake the phone and dismiss a simple swipe lock. A PIN, pattern or fingerprint lock cannot be bypassed - the user must unlock it themselves.

List the apps installed on the phone and which ones this server is allowed to open.

Open an app by name, e.g. 'youtube' or 'chrome'. Only apps on the allowlist can be opened - call list_apps to see them.

Jump straight to a Settings page instead of navigating there by hand. Pages: wifi, mobile_data, network, airplane_mode, hotspot, bluetooth, display, sound, battery, storage, apps, location, security, accessibility, date_time, language, privacy, notifications, about_phone, settings_home.

Diagnose the phone's internet connection without touching the screen. Start here for 'my internet isn't working' - it shows whether the radios are on, whether traffic flows, and whether DNS resolves.

List the tabs open in Chrome on the phone. Use the ids with the other chrome_ tools; most of them default to the most recent tab.

Read a page in Chrome as structured content: its text plus a numbered list of links, buttons and fields. This is the web equivalent of get_screen, and far more reliable than reading the page off a screenshot.

Open a URL in a new Chrome tab on the phone.

Point an existing Chrome tab at a different URL.

Click an element by its number from chrome_read.

Type into a field in Chrome. Give the field's number from chrome_read, or omit it to type into whatever is already focused.

Unlike the phone's own keyboard, this handles any language and emoji.

Run JavaScript in a Chrome tab and return the result. Use for anything the other chrome_ tools do not cover - extracting data, submitting a form, scrolling to an element.

Close a Chrome tab by its id from chrome_tabs.

Check whether the phone is reachable and why not, if not.

Worth calling first when something stops working: the accessibility service can be switched off by the system without warning, and the failure looks like a network problem until you look.

Show what the background watchdog last saw, including when the phone went down and whether a repair was attempted. Use this to answer 'has the phone been reachable?' without poking the phone right now.

Put the phone's accessibility service back when it has been switched off.

Android periodically revokes accessibility access from apps it did not install. The phone can re-enable its own service, so this works over any network including cellular - no cable, and nobody has to touch the phone.

List the phones this server can drive, and whether each is reachable.

Every other tool takes an optional device naming one of these. With more than one phone configured, always name the one you mean.

Set which phone the other tools act on when no device is named.

This changes the default for everyone using this server, so prefer naming the phone per call when you are switching between them.

Look for phones on your tailnet that are running the client app.

Finds Android devices on the tailnet and checks whether each answers on the bridge port. A phone found here still needs its pairing token before it can be driven - read that from the Android Use app on the phone itself.

Register a phone so it can be driven by name.

host is its Tailscale address (see discover_phones) and token is the pairing token shown in the Android Use app on that phone.

Remove a phone from the registry. The phone itself is left untouched.

Work on one phone only, until unlocked.

Every tool then acts on this phone, and a request naming a different one is refused rather than redirected. Use this when helping one person, so a misread instruction cannot reach somebody else's phone.

Stop working on just one phone, so all registered phones are usable again.