Google Play Console MCP
An MCP server for Google Play Console — 170 tools across publishing, Android vitals, revenue, ASO and store assets, with a confirmation gate on every destructive write.
Connect Claude, Cursor, VS Code, Codex, Gemini CLI, Windsurf, or any Model Context Protocol client to your Google Play developer account.
Ship a release. Ask whether it is crashing. Find out what it earned. See what users searched to find it. Reply to a review. All of it from the same session, and none of the destructive parts without you saying yes first.
"Is the 4.2.1 rollout healthy?"
-> vitals freshness checked, crash rate by version code, worst issue's stack
trace, current rollout fraction — and a recommendation
"How much did we make in July, and where did the installs come from?"
-> earnings per currency, acquisitions by traffic source, top search terms
"Ship 4.2.2 to production at 10%."
-> a preview you have to approve before anything moves
Why this one
There are a dozen Google Play MCP servers. This is the only one that covers the whole surface, and the only one with a real test suite.
| this | typical | |
|---|---|---|
| Tools | 170 | 3–150 |
| Google APIs covered | 3 + scraping + preflight | 1 |
| Tests | 1,198 | 0 |
| Branch coverage | 100% | none |
| Confirmation gate on destructive writes | yes | no |
| Audit log | yes | no |
Most servers wrap the Android Publisher API and stop. That API cannot tell you your crash rate, cannot tell you what you earned, and cannot tell you what people typed to find your app — those live in two other places entirely.
The five planes
| Plane | Source | What it answers |
|---|---|---|
| Publishing | Android Publisher v3 | releases, tracks, listings, IAP, subscriptions, testers, users |
| Android vitals | Play Developer Reporting v1beta1 | crash rate, ANR rate, slow start, wakelocks, error clusters, anomalies |
| Revenue & acquisition | Cloud Storage bulk reports | earnings, installs, ratings, store conversion, search terms |
| Public store | scraping | competitor listings, chart positions, keyword suggestions, review history |
| Store assets | local | image preflight against Play's real rules, before upload |
Each needs different credentials, and the server tells you exactly which are missing and how to fix it.
Install
One line. It registers the server with the agents you pick:
uvx google-play-console-mcp install
You get a checklist of the agents found on your machine — Claude Code, Claude Desktop, Cursor, VS Code, Codex, Gemini CLI, Windsurf, Zed, Cline, Goose, OpenCode and 11 more — and it writes the right config file, in the right shape, for each one. No JSON to paste, no path to look up.
# pick agents up front and skip the prompts
uvx google-play-console-mcp install -a claude-code -a cursor -y
# read-only, with credentials wired in
uvx google-play-console-mcp install --read-only --credentials ~/sa-key.json
# see the exact command without running it
uvx google-play-console-mcp install --dry-run
install keeps the server itself out of your way: uvx fetches it on demand,
so there is nothing to upgrade by hand. To keep a permanent copy instead:
uv tool install google-play-console-mcp # then: google-play-console-mcp install
pipx install google-play-console-mcp
pip install google-play-console-mcp
The wiring is done by add-mcp
(Apache-2.0), which tracks each agent's config format so this server does not
have to. It runs under npx; if you have no Node.js, install prints the exact
config block to paste instead of failing.
Configure by hand
Add to your MCP client (.mcp.json, claude_desktop_config.json, …). VS Code
nests the same entry under servers, Zed under context_servers:
{
"mcpServers": {
"google-play-console": {
"command": "uvx",
"args": ["google-play-console-mcp"],
"env": {
"GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json",
"GOOGLE_PLAY_MCP_REPORTS_BUCKET": "pubsite_prod_rev_0123456789"
}
}
}
}
Credentials
Store the key in your OS keychain — macOS Keychain, Windows Credential Locker, or a Freedesktop Secret Service on Linux — instead of leaving it on disk or naming its path in an agent config file:
google-play-console-mcp credentials set service-account.json
google-play-console-mcp credentials show # what is configured; prints no secrets
install --credentials key.json --keychain does both in one step: files the key
in the keychain and writes nothing about it into any config file.
Environment variables still work and take precedence — GOOGLE_APPLICATION_CREDENTIALS
(path) or GOOGLE_PLAY_STORE_CREDENTIALS (path or inline JSON) — which is what
you want in CI, in Docker, and anywhere a keychain does not exist.
User OAuth instead of a service account:
google-play-console-mcp credentials adc # prints the exact login command
It authenticates with gcloud auth application-default login, so there is no
client secret or redirect to configure. It is off unless you set
GOOGLE_PLAY_MCP_USE_ADC=1 (or pass --use-adc): those credentials are
ambient machine state shared with every Google tool, and a server that can ship
a release should never quietly inherit whoever ran gcloud last.
Resolution order:
--credentials, then the environment variables, then the keychain, then ADC if enabled.
Setting up the service account
- Service account — Google Cloud Console → enable the Google Play Android Developer API → create a service account → download the JSON key.
- Invite it in Play Console → Users and permissions.
- Grant these, which are separate and independently forgettable:
| For | Grant |
|---|---|
| Publishing | the app permissions you want the agent to have |
| Android vitals | the playdeveloperreporting scope |
| Revenue & acquisition | the account-level permission "View app information and download bulk reports" |
The bulk-reports permission is account-level. An app-level grant does not reach the storage bucket, and this is the most common reason those tools 403.
Find the bucket in Play Console → Download reports → Statistics → Copy Cloud Storage URI. There is no API that discovers it.
Then ask the agent to run check_reports_access, or read the
gplay://config resource — both report what is configured and what each missing
piece needs.
Safety
This server can ship to production, delete every localized listing, and refund real money. So:
18 destructive tools are behind a two-step confirmation gate. The first call returns a preview — what changes, what it affects, how to undo it — and does nothing. Only a second call carrying that preview's token executes.
The token is an HMAC over a canonical fingerprint of the operation, keyed with a per-install secret the model never sees. It catches an invented token, a token from a different operation, a parameter changed between preview and confirmation, a reused token, and an expired one.
The threat model is not a hostile user. It is a language model that hallucinates confirmation tokens, replays old ones, adjusts a parameter between the preview and the confirmation, and will cheerfully report that you approved something you never saw.
halt_release is deliberately not gated. Stopping a bad rollout is the one
operation that reduces blast radius, and demanding a second round-trip during an
incident is itself the failure mode.
Production cannot go to 100% in one step. The staged-rollout policy caps the first step at 20%; reaching everyone requires the separately named widening tool. The ceiling can be tightened but not disabled.
Everything is audited — previewed, confirmed, rejected, executed, failed —
to ~/.google-play-mcp/audit.jsonl, with secrets scrubbed.
GOOGLE_PLAY_MCP_READ_ONLY=1 refuses every write outright, for exploratory
sessions.
See Write safety.
What it knows that you would otherwise learn the hard way
- Screenshots must have no alpha channel. The icon must have one. A plain
"PNG" export is RGBA — right for the icon, rejected for everything else.
preflight_store_imagecatches it before a sixty-image bake fails at upload. - Play requires at least two screenshots per type per locale. A set of one is valid file by file and still blocks the release.
- A subscription purchase left unacknowledged for three days is automatically refunded and revoked by Google. Silent revenue loss.
- The API accepts a 50-character title; Play policy caps it at 30. It uploads fine and is rejected at review.
- Vitals data lags by hours to days. A seven-day query that returns five days reads as an improvement rather than a gap, so freshness is a first-class tool.
- Earnings for a month are not published until around the 5th of the next. Reporting "$0" before that reads as a collapse rather than an absence.
- Earnings are never summed across currencies — 1000 JPY plus 10 EUR is a wrong answer that looks like a right one.
com.acme.freemust not collectcom.acme.freemium's revenue. Attribution stops at a package-segment boundary.
Tools
170 tools. Full reference in docs/.
| Area | Examples |
|---|---|
| Releases | deploy_app promote_release update_rollout halt_release create_track |
| Edits | create_edit describe_edit validate_open_edit commit_edit delete_edit |
| Listings | update_listing list_locale_coverage clone_listing_to_locale upload_image |
| Vitals | query_vitals get_vitals_freshness search_error_issues list_vitals_anomalies |
| Revenue | get_earnings_report get_installs_report get_store_conversion_report get_search_terms |
| Monetization | create_subscription subscription_offers_* acknowledge_subscription_purchase refund_order |
| Reviews | get_reviews reply_to_review delete_review_reply scrape_reviews |
| ASO | search_store get_keyword_suggestions browse_store_chart check_aso_metadata |
| Assets | preflight_store_image preflight_screenshot_set list_store_image_specs |
| Escape hatch | android_publisher_invoke |
Plus 2 prompts (publish_screenshots, release_health_check) and 4 resources.
Tested
1,198 tests · 100% line and branch coverage · 15 modules
ruff clean · mypy clean · every release gated at --cov-fail-under=100
No live API call in the suite. Report parsing is tested against real UTF-16 bytes, image preflight against real PNG and JPEG headers.
Out of scope
Screenshot generation — use appscreens or any other tool, then preflight and upload here.
Licence
Keywords: google play console mcp, google play mcp server, android publisher api mcp, play developer api, model context protocol google play, android app release automation, android vitals mcp, play console api claude, aso mcp, google play earnings api, play store screenshots api, android release agent
Metadata
Release files for google-play-console-mcp 0.4.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| google_play_console_mcp-0.4.0.tar.gz | 375.1 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| google_play_console_mcp-0.4.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 560.5 kB
Release files / google_play_console_mcp-0.4.0.tar.gz
| Download URL | google_play_console_mcp-0.4.0.tar.gz |
|---|---|
| Size | 375.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
9232fa1b74b39a3944cd039644cb736d6f5ad76387e64efd14434057c14edeb8
|
|
BLAKE2b-256 checksum How to use checksums |
76911c9addbc7c639d0cc8e911e27fe2aefb48ed0808b1508de4775f83aaf3c2
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 23, 2026.
Transparency logRelease files / google_play_console_mcp-0.4.0-py3-none-any.whl
| Download URL | google_play_console_mcp-0.4.0-py3-none-any.whl |
|---|---|
| Size | 185.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
8d4e66e592f5d947bf8306c95c3fbfe9ead3b2c761d8517caa466794210f1410
|
|
BLAKE2b-256 checksum How to use checksums |
48588d68eb46b28760bc3e09e217677626b95f61d645fd6173e989f13edc271b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 23, 2026.
Transparency log