google-cloud-console-mcp

Create in-app product

play_create_inapp_product

Creates a one-time in-app product in Google Play Console, requiring SKU, price, title, description, and default language.

Instructions

Creates a new managed in-app product (one-time purchase).

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>",
      "sku": "<sku>",
      "defaultLanguage": "<defaultLanguage>",
      "defaultTitle": "<defaultTitle>",
      "defaultDescription": "<defaultDescription>",
      "defaultPrice": "<defaultPrice>"
    },
    "name": "play_create_inapp_product"
  }
}

Input Schema

Name	Required	Description	Default
`sku`	Yes	Product SKU / product id
`status`	No		active
`packageName`	Yes	Play Console package name, e.g. "com.example.app"
`defaultPrice`	Yes
`defaultTitle`	Yes
`purchaseType`	No		managedUser
`defaultLanguage`	Yes	e.g. "en-US"
`defaultDescription`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: it does not say whether the product goes live immediately, whether an edit ID is required, what permissions/auth are needed, or what happens on SKU conflicts. Only the 'one-time purchase' trait is conveyed, which is arguably already implied by 'managed in-app product'.

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?

A single front-loaded sentence with no filler or redundancy. It is efficiently structured, though the brevity is arguably a consequence of under-specification rather than disciplined editing.

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 complex mutation with 8 parameters (6 required), a nested object, 38% schema coverage, and no annotations or output schema, one sentence is not enough. Missing the edit/commit workflow context, required-field expectations, and the managed-vs-subscription distinction makes this incomplete for correct invocation.

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

Parameters2/5

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

Schema description coverage is only 38% across 8 parameters, so the description is expected to compensate and does not. It says nothing about sku, packageName, defaultLanguage, the nested defaultPrice object (units/nanos/currency), or the status/purchaseType enums; the mention of 'one-time purchase' loosely implies purchaseType=managedUser but never states it, and in fact the enum also allows 'subscription', creating ambiguity.

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 ('Creates') and resource ('managed in-app product'), and adds a clarifying parenthetical ('one-time purchase') that separates it from the sibling subscription tools (play_list_subscriptions, play_get_subscription). It does not explicitly name play_update_inapp_product or play_list_inapp_products as alternatives, so sibling differentiation is only implicit.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as play_update_inapp_product for existing products. Critically, it never mentions the Play edit-transaction workflow (play_create_edit / play_commit_edit) that most write operations in this family depend on, leaving the agent to infer it.

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

Deploy Server