clousd-mcp: a real Android phone for your AI agent

Clousd MCP server gives any MCP-capable agent a real Android phone in the cloud. Not an emulator: each device is built as a specific handset (Pixel, Galaxy, Xiaomi, Motorola, OnePlus, realme, OPPO, vivo, Sony, TECNO, Infinix and 150+ more, Android 12 to 17) with the same build, sensors, cameras, codecs and GPU strings as the real hardware, Google Play inside, and its own network exit in the country you choose. Apps see a phone, so your agent sees the same screens a person sees: no "unusual activity" walls, no emulator detection, no captcha loops.

Six tools cover the whole loop: observe the screen (screenshot with numbered elements plus the UI tree), act on it (tap by element number, swipe, type in any language, open apps and links), inspect the phone without touching the screen (notifications, clipboard, app versions, crashes), snapshots to reset every run to the same state or clone a prepared phone into many, recipe to replay a recorded flow without a model, and devices to manage the fleet. Works with Cursor, Windsurf, Zed, desktop assistants, LangChain-style agents and anything else that speaks MCP, locally or through the hosted endpoint at https://api.clousd.com/mcp.

Early access: keys on request at clousd.com/agents. Docs: clousd.com/docs. Source: github.com/Clousd-Android/clousd-sdk.

Why a real cloud phone instead of an emulator

That is why agents built for social apps, marketplaces, banking flows, app testing and research run here: the phone behaves like the device in a user's pocket, and every episode starts from the same state.

Install

pip install clousd-mcp

Any MCP client, local (stdio) server, one environment variable:

{
  "mcpServers": {
    "clousd": {
      "command": "clousd-mcp",
      "env": { "CLOUSD_API_KEY": "cl_live_..." }
    }
  }
}

Clients that take a command line instead of JSON: run clousd-mcp with CLOUSD_API_KEY in the environment.

Remote server, no install

The same server runs at https://api.clousd.com/mcp (streamable HTTP). Point any MCP client at it with your key in the Authorization header; clients that cannot set headers can pass ?api_key=cl_live_... in the URL.

{
  "mcpServers": {
    "clousd": {
      "url": "https://api.clousd.com/mcp",
      "headers": { "Authorization": "Bearer cl_live_..." }
    }
  }
}

Self-hosting the remote mode: CLOUSD_MCP_HTTP=127.0.0.1:8790 clousd-mcp serves /mcp over HTTP; every request must carry a key, nothing is read from the environment. The hosted endpoint is also listed in the MCP registry as io.github.Clousd-Android/clousd-mcp.

Tools

Nine tools: a few large tools are easier for a model to choose from than dozens of small ones. Every tool has parameter descriptions, a result schema and hints (read-only, destructive, idempotent), so clients and models pick the right one.

Screenshots come back 540 px wide (CLOUSD_SHOT_WIDTH to change). Act on an element by its number from the last observe: the most reliable way to press a button. Coordinates, when needed, are in that image and the server scales them to the phone. Typing goes through the input method and works in any language and in password fields.

Automate, do not tap

Tapping through observe -> act is for exploring and for screens no recipe covers. For a known app task the agent should run a recipe, and for several phones one fleet call, not a loop:

fleet op=recipes app=instagram                      -> login, warm, publish_post, publish_story, delete_last_post
fleet op=run devices=all package=com.instagram.android action=warm
          vars={"seconds":"900","comment_chance":"0.1"} stagger=20,90
                                                    -> {"job": "j_8a1c", "devices": [10 phones]}
fleet op=status job=j_8a1c                          -> {"counts": {"running": 7, "done": 3}, "devices": {...}}

Signing ten accounts in at once from the saved accounts (resources op=accounts), the password never passes through the agent: fleet op=run devices=all steps=[{"op":"login","package":"com.instagram.android","account":"linked"}] signs every phone into the account linked to it. Or with logins given right there: fleet op=run devices=["dev_01","dev_02",...] package=com.instagram.android action=login vars_by_device={"dev_01":{"login":"anna.k","password":"..."}, ...}. Passwords never appear in the output.

What a session looks like

observe   dev_04f2                               -> screenshot, "On screen: com.android.chrome", elements 1..34
act       dev_04f2 tap element=12                -> "ok" (settled in 0.6 s)
act       dev_04f2 type text="weather in Berlin"
act       dev_04f2 key text=enter
act       dev_04f2 wait_text text=Berlin         -> "found after 1.9 s"
inspect   dev_04f2 crashes                       -> []
snapshots dev_04f2 restore snapshot_id=snap_7f3  -> "restored"   (next episode starts clean)

What teams use it for

• Agent evaluation and training: restore a snapshot, run the agent for N steps, check the screen, repeat. One phone, hundreds of identical episodes. Run AndroidWorld-style task sets on real device models.
• App testing on real models: the same test on a Galaxy A35, a Pixel 9 and a moto g05, Android 14 to 16, without a device farm. Crashes, ANRs and the logcat are one inspect away.
• Account and content operations: each phone keeps its own identity, network and app state; clone a prepared phone instead of setting up the next one by hand; recipes replay a flow on many phones.
• Anything that needs a phone in a specific country: the exit, SIM, time zone and locale match.

Security and scope

• Keys are issued per account with a scope (read or control) and an explicit list of phones; a read key can observe and inspect but never acts.
• Over HTTP the key travels in the Authorization header of every request; the hosted server keeps nothing between requests.
• Phones never leak traffic outside their configured exit: a kill-switch below Android drops anything that is not going through the exit.
• ADB is available on request per phone, with an IP allow-list and a one-time code, for checks that need to go deeper than the screen.

FAQ

Is this an emulator? No. Each phone is a full Android system built as a specific real model; apps read the same hardware identity the real handset reports. Emulator detection does not trigger.

Which MCP clients work? Anything that speaks MCP over stdio or streamable HTTP: Cursor, Windsurf, Zed, desktop assistants, agent frameworks with MCP support, and your own code through the Python client (clousd).

How fast is a step? observe with the UI tree takes about 1 to 3 seconds; act with settle 0.3 to 1 second. A typical agent step including the model is 5 to 10 seconds.

What does it cost? Per minute while the phone runs, or a monthly plan; stopped phones cost nothing. Network traffic by the gigabyte. See clousd.com/pricing.

Can I run my own flows without a model? Yes: record a flow once (recipe with record_start / record_stop, or by hand in the dashboard) and replay it with recipe run on any number of phones.

Links

• Phones for AI agents: https://clousd.com/agents/
• Documentation and API reference: https://clousd.com/docs/ and https://clousd.com/docs/reference/
• Device catalog (150+ models): https://clousd.com/devices/
• Networks: https://clousd.com/network/
• Snapshots and clones: https://clousd.com/snapshots/
• Python client: https://pypi.org/project/clousd/
• Source, OpenAPI description, issues: https://github.com/Clousd-Android/clousd-sdk

Built on the clousd Python client. MIT license.

mcp-name: io.github.Clousd-Android/clousd-mcp