google-cloud-console-mcp

Update testers for a track

play_update_testers

Replaces the full tester list for a Google Play track using Google Group email addresses, so you can manage who tests internal, alpha, beta, or custom releases.

Instructions

Replaces the full tester list for a track. Provide googleGroups (Google Group email addresses) and/or googleGroups-managed testers per the Play API — most projects manage testers via a Google Group, so pass that group's email in googleGroups.

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>",
      "editId": "<editId>",
      "track": "<track>"
    },
    "name": "play_update_testers"
  }
}

Input Schema

Name	Required	Description
`track`	Yes	Track name, e.g. "internal", "alpha", "beta", or a custom testing track
`editId`	Yes	Edit id returned by play_create_edit
`packageName`	Yes	Play Console package name, e.g. "com.example.app"
`googleGroups`	No	Google Group email addresses whose members are testers

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the key destructive nuance that the operation replaces rather than appends the tester list. However, it omits other important behavior: permission requirements, the edit/validate/commit lifecycle implied by editId, and what happens to existing testers not included in the new list.

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

Conciseness4/5

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

Two sentences, front-loaded with the replace semantics that matter most, with no padding. The phrase 'and/or googleGroups-managed testers per the Play API' is slightly vague and costs it a point.

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

Completeness3/5

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

A mutation tool with no annotations and no output schema, so the description should do more heavy lifting. It covers replace semantics and the tester input form, but omits the edit lifecycle (create/validate/commit) that governs when this call actually takes effect.

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, and the description adds genuine semantic value by recommending the Google Group email form for googleGroups, which is the practical way most projects configure testers. It adds nothing for track/editId/packageName, but those are self-evident.

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

Purpose4/5

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

States a specific verb and resource with scope ('Replaces the full tester list for a track'), which is more precise than the title alone. It does not explicitly differentiate itself from the sibling play_get_testers or firebase_appdistribution_add_testers, so it stops short of a 5.

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

Usage Guidelines3/5

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

It gives positive guidance on how to supply testers ('pass that group's email in googleGroups') but no when-to-use-vs-alternatives or when-not guidance, e.g. nothing about how this differs from editing testers via other flows or that an edit must be committed.

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

Deploy Server