Google Play MCP

create_subscription

Creates a Google Play subscription product with listings and base plans for an app; new base plans start as drafts and require separate activation.

Instructions

Create a subscription. subscription is a Subscription resource: { listings: [{ languageCode, title, benefits?, description? }], basePlans: [{ basePlanId, autoRenewingBasePlanType: { billingPeriodDuration: 'P1M' }, regionalConfigs: [{ regionCode: 'US', price: { currencyCode: 'USD', units: '4', nanos: 990000000 } }] }] }. New base plans start as DRAFT — activate them with activate_base_plan. Takes effect immediately (no edit).

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>",
      "productId": "<productId>",
      "subscription": "<subscription>"
    },
    "name": "create_subscription"
  }
}

Input Schema

Name	Required	Description
`productId`	Yes	Subscription product id
`packageName`	Yes	Application id (package name), e.g. com.example.app
`subscription`	Yes	Subscription resource
`regionsVersion`	No	Regions version for regional prices (default 2022/02; override the default with PLAY_MCP_REGIONS_VERSION)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and discharges most of it: it discloses the post-creation lifecycle state (DRAFT), that the change is immediate and not part of an edit transaction, and the exact shape of the nested resource including price representation. It omits failure modes (duplicate productId, permission/auth requirements, whether a product exists check is needed).

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?

Front-loaded with the verb, then the resource contract, then the two behavioral facts that matter (DRAFT state, immediate effect). The inline object notation is dense but structured and wastes no sentences. The single inline blob is harder to scan than a bulleted shape, which keeps it off a 5.

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 output schema exists, yet the description covers the input contract, lifecycle outcome, and the follow-up tool, which is what an agent needs to invoke this correctly. Remaining gaps (return value, error/precondition behavior, regionsVersion interaction) are secondary for a create call whose resource shape is spelled out.

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

Parameters5/5

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

Schema coverage is 100%, but the schema only declares `subscription` as an opaque object with additionalProperties:true — the description supplies the actual contract: listings with languageCode/title/benefits/description, basePlans with basePlanId, autoRenewingBasePlanType.billingPeriodDuration ISO duration, and regionalConfigs price as currencyCode/units/nanos. This is meaning the schema alone cannot convey, especially for the nested pricing structure.

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?

Names a specific verb and resource ('Create a subscription') and immediately defines the `subscription` payload it expects. It does not explicitly distinguish itself from near neighbors like create_subscription_offer or update_subscription, but the create semantics and the DRAFT/activation note make the intent unambiguous.

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

Usage Guidelines4/5

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

Gives concrete operational guidance: new base plans are created as DRAFT and must be promoted via activate_base_plan, and the call takes effect immediately rather than being staged in an edit. That routes the agent correctly for the common follow-up step. It stops short of stating when-not to use it (e.g., for offers, which belong to create_subscription_offer).

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

Deploy Server