google-cloud-console-mcp

Release a version to a track (composite)

play_release_to_track

Ship an app build by releasing versionCodes to a Google Play track with status/rollout: creates an edit, updates the release, and commits it.

Instructions

High-level helper for the common 'ship this build' workflow: creates an edit, sets the given track's release to exactly the given versionCode(s) with the given status/rollout, and commits. Use this instead of manually chaining play_create_edit + play_update_track + play_commit_edit unless you need finer control (e.g. multiple simultaneous releases on a track, or editing other things in the same edit first).

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>",
      "versionCodes": "<versionCodes>"
    },
    "name": "play_release_to_track"
  }
}

Input Schema

Name	Required	Description	Default
`track`	Yes	Track name: "internal", "alpha", "beta", "production", or a custom closed-testing/open-testing track name as shown in Play Console.
`status`	No	"completed" = fully rolled out, "inProgress" = staged rollout in progress, "halted" = rollout paused, "draft" = not yet released	completed
`packageName`	Yes	Play Console package name, e.g. "com.example.app"
`releaseName`	No
`releaseNotes`	No
`userFraction`	No	Required when status is inProgress or halted; staged rollout fraction (0-1)
`versionCodes`	Yes	versionCode(s) to release on this track — normally just one

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does disclose the composite side-effect chain (creates an edit, mutates the track release, commits) — so the agent knows this is a mutating, immediately-committed operation rather than a staging one. It stops short of stating permission requirements, whether the commit is atomic/rollback-safe, or that existing track releases are replaced rather than appended.

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?

Two sentences, zero filler, with the primary action stated first and the escape hatch to manual chaining second. Every clause earns its place.

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

Completeness4/5

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

No annotations and no output schema, so the description must cover behavior on its own; it adequately covers the workflow and the replacement semantics. What is missing is what the tool returns on success/failure and any permissions or track-state preconditions, which matters for a commit-performing mutation.

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 71% and the description adds the key semantic the schema does not: the release is set to 'exactly' the given versionCodes, implying replacement of the track's prior release configuration, plus it ties status/rollout together as the release state. It does not clarify releaseName, releaseNotes, or the userFraction/status dependency beyond what the schema already documents.

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?

Names a specific composite action (create edit + set track release + commit) and states exactly what it does: 'sets the given track's release to exactly the given versionCode(s) with the given status/rollout, and commits.' An agent can distinguish it from play_create_edit/play_update_track/play_commit_edit without opening any 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?

Explicitly says to use it 'instead of manually chaining play_create_edit + play_update_track + play_commit_edit' and names the precise condition to prefer the manual chain ('unless you need finer control — e.g. multiple simultaneous releases on a track, or editing other things in the same edit first'). This is textbook when/when-not/alternative routing.

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

Deploy Server