Google Play MCP

update_track

Replace a Google Play track's releases array with specified release objects to handle custom or unusual release configurations, with optional dry-run validation before publishing.

Instructions

Low-level: replace a track's releases array with exactly what you pass (TrackRelease objects). Prefer create_release / promote_release / the rollout tools; use this for unusual shapes. Production tracks are gated by PLAY_MCP_ALLOW_PRODUCTION_RELEASE. Set dryRun:true to validate without publishing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "packageName": "<packageName>",
      "track": "<track>",
      "releases": "<releases>"
    },
    "name": "update_track"
  }
}

Input Schema

Name	Required	Description
`track`	Yes	Track name: internal, alpha (closed testing), beta (open testing), production, a custom closed-testing track name, or a form-factor track such as wear:production
`dryRun`	No	Preview only: open a temporary edit, apply, validate, then delete it. Nothing is published (default false). Ignored when editId is set.
`editId`	No	Optional: an open edit from insert_edit. The change is applied inside that edit and NOT committed — batch several changes, then call commit_edit.
`releases`	Yes	TrackRelease objects: { status, versionCodes, userFraction?, name?, releaseNotes?, ... }
`packageName`	Yes	Application id (package name), e.g. com.example.app
`changesNotSentForReview`	No	Commit option: keep the changes out of review until sent from Play Console. Google requires this for some apps and rejects it for others — set it only if a commit error asks for it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does it well: it discloses destructive replacement semantics (whatever you omit disappears), an environment-variable gate that can block production writes, and a dryRun path that validates without publishing. The editId batch-then-commit behavior is covered jointly here and in the parameter docs, leaving no surprise for a mutation call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the "Low-level" framing, then the alternative-tool routing, then the constraints. Every clause adds a decision-relevant fact and nothing is repeated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, unannotated, no-output-schema mutation tool, the description covers purpose, safer alternatives, replacement danger, environment gating, and dry-run validation. An agent has everything it needs to call this correctly or to choose a better tool instead.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: that the `releases` array is a wholesale replacement rather than a merge. The dryRun sentence largely restates the schema's own description of that parameter, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Low-level: replace a track's `releases` array with exactly what you pass" names a specific verb (replace), a specific resource (a track's releases array), and its exact semantics. It also distinguishes itself from create_release, promote_release, and the rollout tools, so an agent can reject the wrong sibling without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing guidance: prefer create_release / promote_release / the rollout tools, and reserve this call for "unusual shapes." It also states the production prerequisite (PLAY_MCP_ALLOW_PRODUCTION_RELEASE), which is a when-you-may-use condition, not just a warning.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server