playstore-release-mcp

An MCP server that drives Google Play releases: bundle upload, track releases (internal / closed / open / production), listing metadata, store graphics, and review replies.

Sibling to appstore-release-mcp. Same shape, same conventions — but simpler in one important way: Play's REST API can do the entire release. There's no equivalent to Apple's "archive, sign, and upload" gap, because a .aab built by EAS Build (or Gradle) already arrives signed. This server is a pure Android Publisher API client — no fastlane, no local build toolchain, no async job runner.

Requirements

• A Google Cloud service account with the Android Publisher API enabled, granted access to your app in Play Console.

• An existing app record in Play Console. The Android Publisher API cannot create a brand-new app — the very first app must be created by hand (Play Console → Create app).

Related MCP server: Google Play Developer API MCP Server

Setup

1. Create a service account (once): Google Cloud Console → IAM & Admin → Service Accounts → Create Service Account → skip granting Cloud-level roles → Keys → Add Key → JSON. Download it.

2. Grant it access in Play Console: Play Console → Users and permissions → Invite new users → paste the service account's email (from the JSON's client_email field) → grant at least Release manager permissions on the app(s) it should manage.

3. Register with Claude Code:

claude mcp add playstore \
  -e GOOGLE_SERVICE_ACCOUNT_KEY_PATH=$HOME/.play/service-account.json \
  -e PLAY_PACKAGE_NAME=com.example.myapp \
  -- npx playstore-release-mcp

(Or GOOGLE_SERVICE_ACCOUNT_KEY_CONTENT with the JSON base64-encoded, if you'd rather not keep the key on disk.)

4. Verify: ask the agent to run play_doctor. All checks should be ✓.

Tools

Release walkthrough

play_doctor
play_upload_bundle {aab_path: "./build/app.aab"}        # → versionCode
play_release_to_track {track: "internal", version_code}  # no review gate — fast sanity check
...
play_release_to_track {track: "production", version_code, status: "completed"}
play_app_status                                           # confirm rollout

Staged rollout example: play_release_to_track {track: "production", version_code, status: "inProgress", rollout_fraction: 0.1} ships to 10% of users; call it again with a higher fraction to widen, or status: "completed" to go to 100%.

What this can't do

Play Console (web) only — no public API exists for either of these, as far as I've found:

• Data Safety form — the data-collection disclosure questionnaire.

• Content rating (IARC) questionnaire.

Both are one-time-per-app forms (rarely touched after initial setup), so this is a minor gap in practice, but worth knowing going in — don't expect a play_update_data_safety tool.

Notes

• Google's OAuth2 flow requires exchanging a signed JWT for an access token (one extra network call versus Apple's ES256 JWT, which is used directly as the bearer token). Tokens are cached and refreshed automatically.

• Play's release model is transactional ("Edits"): open an edit, stage changes, commit. Only one open edit per app is allowed at a time. Every tool here opens and commits (or abandons, on error) its own edit — you never have to think about edit IDs.

• play_release_to_track targeting production is the point of no return for a public rollout — the tool description tells agents to confirm with a human first, same convention as appstore-release-mcp's asc_submit_review.

License

MIT