Release inspection guide

Check a Google Play release with MCP.

Use PubShip to compare Production and Internal Testing from your AI client, without changing a release. Learn what the returned lifecycle state proves, and what still needs checking in Play Console.

Reviewed against PubShip 0.24.1. Examples use a synthetic package; no live Google account was queried for this guide.

1. Prepare read access

Follow the local setup guide to install uv, enable the Google Play Android Developer API and grant your service account read access to your app in Play Console. Configure GOOGLE_PLAY_PACKAGES with your actual package name. If using a service-account key, set GOOGLE_APPLICATION_CREDENTIALS to its absolute file path on your computer. Never paste the key contents into a chat.

Start with the credential-free installation check:

uvx pubship --check

This confirms the installed program can run. It does not authenticate with Google or prove that your account can read the app. Connect PubShip using the setup instructions for Claude Code, Codex, Cursor, Gemini CLI or your generic MCP client. Keep write opt-ins disabled for this walkthrough.

2. Inspect both tracks

Ask your client:

Inspect Production and Internal Testing releases for com.example.app. Make no changes. Show each track, version code, the exact releaseLifecycleState and the retrieval time. Separate a published release from one still in review. Explain anything the response does not establish.

Replace com.example.app with an app you own and have allowlisted. The read tool is list_releases. These are MCP tool arguments, not shell commands:

Production

{"package":"com.example.app","track":"production"}

Internal Testing

{"package":"com.example.app","track":"internal"}

The tool reads release lifecycle information without creating or committing an edit. Your client's wording may vary; inspect its actual tool call and response. An assistant saying it checked a release is not evidence unless the read succeeded.

3. Read the lifecycle

The response includes package, track, fetched_at, Google's response under data, and a note about lifecycle interpretation. Keep the exact lifecycle value alongside any plain-language summary.

In review is not published
A release returned from the production track may still be in review. The track name identifies its destination, not proof of public availability.
A staged edit is a draft snapshot
Track data read from an edit is not live release evidence. Even a staged status of completed does not prove the release is available to users.
Retrieval time is not publication time
fetched_at records when PubShip retrieved the response. Do not relabel it as Google's approval time or the moment users received the update.
Missing is not zero
An empty response, omitted field or excluded obsolete release is not proof that the app never had a release. State the scope and limits of the returned data.

Before announcing a rollout, reconcile the returned lifecycle with Play Console's publishing state and the intended countries, track and audience. This guide establishes a read workflow, not universal device availability or a release approval.

4. Check data freshness

To investigate quality after a release, enable the separate Google Play Developer Reporting API and its required access. Publisher access alone does not establish Reporting access. First inspect the exact method contract with the credential-free describe_api_method tool: 

{"method":"playdeveloperreporting.vitals.crashrate.get"}

Then retrieve crash-rate metric-set metadata through read_reporting: 

{"method":"playdeveloperreporting.vitals.crashrate.get","parameters":{"name":"apps/com.example.app/crashRateMetricSet"}}

This GET returns metric-set metadata, including freshness information when supplied. It does not return a daily crash-rate time series. Use the separate query method and its documented date, metric and dimension contract for that. Do not report missing or not-yet-available days as zero crashes, and keep the reporting timezone visible.

5. Resolve common failures

ADC authentication failed
Check the credential path and Google authentication setup in the client process. A terminal and a desktop client may have different environments. Follow the authentication guide; do not paste keys or tokens into the conversation.
Google returns 403
Verify the appropriate API is enabled and the actual service-account email has access to this app in Play Console. The local package allowlist does not grant Google permissions.
The package is outside the allowlist
Correct GOOGLE_PLAY_PACKAGES in your client's local configuration, then restart the MCP connection. Add only packages you or your organization own.
The client cannot find the tool
Check that the PubShip connection started successfully and lists its tools. Recheck the client configuration and executable path.

Once reads are working, use the permissions and data-flow guide before enabling any changes. PubShip runs locally with your credentials; tool results reach your MCP client and may reach its model provider.

Contracts and further reading