google-cloud-console-mcp

List store listing images

play_list_images

List uploaded images such as screenshots, icons, and feature graphics for a specific language and image type in a Google Play Store listing. Use to review or manage store assets.

Instructions

Lists uploaded images of a given type (screenshots, icon, feature graphic, ...) for a language.

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>",
      "language": "<language>",
      "imageType": "<imageType>"
    },
    "name": "play_list_images"
  }
}

Input Schema

Name	Required	Description
`editId`	Yes	Edit id returned by play_create_edit
`language`	Yes	BCP-47 language code as used by Play Console, e.g. "en-US", "tr-TR"
`imageType`	Yes	Which image slot in the store listing to operate on
`packageName`	Yes	Play Console package name, e.g. "com.example.app"

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

B3.1/5.0

Behavior2/5

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

No annotations, so the description carries full burden. It does not disclose that operations require an open edit (despite the editId param), that the listing may be a draft, read-only status, or any return/ordering behavior. For a read on an edit-scoped resource, this is thin.

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?

Single front-loaded sentence with a scoping enumeration. Efficient, though the parenthetical enumeration duplicates the schema enum slightly.

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

Completeness2/5

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

For a 4-required-param Play Edit operation with no annotations and no output schema, the description omits edit-context requirements, return shape, and ordering. It is adequate but incomplete for a stateful edit-scoped read.

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

Parameters3/5

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

Schema coverage is 100% and each parameter has a description plus an enum for imageType, so the schema does the heavy lifting. The description re-lists image types but adds no syntax or format beyond the schema. Baseline 3 applies.

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 (lists) and resource (uploaded images) with scoping by type and language. Clear and distinct from play_list_listings, but does not name alternatives or contrast scope.

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?

Usage is implied: read image slots within an edit for a language. No explicit when-to-use vs play_list_listings/play_get_listing, and no prerequisites beyond what the schema implies.

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

Deploy Server