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).

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

Tool	What it does
play_doctor	Verify credentials, package name, API reachability — run first
play_app_status	All tracks + their current release, version codes, rollout %
play_upload_bundle	Upload a local .aab → returns the resulting versionCode
play_release_to_track	Assign a versionCode to a track, set status/rollout %/release notes
play_update_listing	Title / short description / full description, per locale
play_upload_graphics	Screenshots, hi-res icon, feature graphic — Play's API allows this directly
play_list_reviews	Recent user reviews with star ratings and text
play_reply_review	Post a public developer reply to a review

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