MCP server

The same 27 tools, two ways in: a hosted MCP endpoint (URL + your API key, nothing to install or keep current) and a local stdio server in one stdlib-only Python file. Agents that speak the Model Context Protocol get PreviewAPK as native tools — including screenshots that return as images inside the conversation.

Hosted MCP — no install

Point your MCP client at https://previewapk.siteport.site/mcp with your account API key as a Bearer token. The server speaks MCP Streamable HTTP (2024-11-05 and 2025-03-26) and answers with the same tools, the same receipts, and the same error envelopes as the local server — your key's scope is enforced identically (a read-only key observes here and cannot drive).

Claude Code

claude mcp add --transport http previewapk https://previewapk.siteport.site/mcp \
  --header "Authorization: Bearer <your key>"

Cursor / generic remote-MCP clients

{
  "mcpServers": {
    "previewapk": {
      "url": "https://previewapk.siteport.site/mcp",
      "headers": { "Authorization": "Bearer <your key>" }
    }
  }
}

Codex

# ~/.codex/config.toml — with PREVIEWAPK_API_KEY set in the environment
[mcp_servers.previewapk]
url = "https://previewapk.siteport.site/mcp"
bearer_token_env_var = "PREVIEWAPK_API_KEY"

How selection works here: at connect, the server issues a session id (Mcp-Session-Id) and your working-device selection rides on it — select once with previewapk_use_device (or start a device), then drive, exactly like the local server. Two connections never share a selection, even on the same key. Selections live in the server's memory: they survive about two idle hours and are forgotten on a server restart (select again — nothing else is lost). Calls that name their device also work with no session at all.

Hosted differences — the server cannot read your disk: previewapk_push_apk takes apk_b64 (the file as base64) instead of path; previewapk_device push_file takes data_b64 instead of a local path, and pull_file returns the content as data_b64; previewapk_record_download returns the MP4 as data_b64 instead of writing a file. Request bodies cap at 25 MB and inline downloads at ~25 MB — for very large APKs or recordings, the CLI's resumable transfers are the right tool.

Local install (stdio)

curl -o previewapk_mcp.py https://previewapk.siteport.site/mcp/previewapk_mcp.py

Claude Code

claude mcp add previewapk \
  --env PREVIEWAPK_API_KEY=<your key> \
  -- python3 /path/to/previewapk_mcp.py

Cursor / generic MCP clients

{
  "mcpServers": {
    "previewapk": {
      "command": "python3",
      "args": ["/path/to/previewapk_mcp.py"],
      "env": { "PREVIEWAPK_API_KEY": "<your key>" }
    }
  }
}

Google Antigravity

PreviewAPK is not in Antigravity's built-in MCP Store — Google curates that shelf itself, and there is no submission path. The raw-config route below takes about two minutes and works the same in the Antigravity IDE, App, and CLI, which all share the one config file (~/.gemini/config/mcp_config.json).

In the IDE: open the agent panel's … menu → MCP Servers → Manage MCP Servers → View raw config, and add the entry:

{
  "mcpServers": {
    "previewapk": {
      "command": "python3",
      "args": ["/path/to/previewapk_mcp.py"],
      "env": { "PREVIEWAPK_API_KEY": "<your key>" }
    }
  }
}

Save, then click Refresh in the MCP servers panel. Antigravity's agent gets the same 27 tools listed below, screenshots included.

The working-device model: an agent session has a working device, like a working directory. previewapk_use_device selects it (or previewapk_start, which requires naming the device and selects it too); every other tool then talks to the working device without repeating its name, and a per-call device argument overrides for one call. With nothing selected, action tools refuse — there is no default device to guess. Each agent session holds its own selection, so two agents on one account never inherit each other's place.

Tools