Skip to main content
Glama

google_create_one_time_product

Create a Google Play one-time product with buy or rent options, localized listings, and regional pricing, then inspect the returned purchase-option state and activate it when DRAFT.

Instructions

Create a new one-time product (buy or rent) on Google Play. Inspect the returned purchase-option state and call google_activate_purchase_option when it is DRAFT.

Input Schema

NameRequiredDescriptionDefault
listingsYesAt least one localization is required
offerTagsNo
productIdYesOne-time product ID, e.g. com.example.app.remove_ads
packageNameYesAndroid package name (e.g. com.example.app)
regionsVersionNoGoogle Play regions version. Default 2022/02 matches Google API expectations.2022/02
purchaseOptionsYesAt least one purchase option (buy or rent) is required
taxAndComplianceSettingsNo
restrictedPaymentCountriesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.0

TDQS

A3.7/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 behavioral burden. It usefully discloses that the returned purchase option may be in DRAFT state and that google_activate_purchase_option is the follow-up, but it omits important mutation details such as whether an edit transaction is required, permission requirements, idempotency, and what exactly gets created.

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 short sentences, front-loaded with the core action and followed by the critical post-creation workflow. Every sentence adds value and nothing is redundant.

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 create tool with 8 parameters, nested objects, no annotations, and no output schema, the description is too sparse. It covers the activation workflow but not the prerequisites or the structure of the large configuration payload an agent must supply.

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 63% across 8 parameters, many nested. The description adds no parameter-level meaning beyond repeating the buy/rent distinction already present in the schema, leaving substantial gaps such as regional pricing, tax settings, and listing structure unaddressed.

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?

The description states a specific verb and resource ('Create a new one-time product (buy or rent)') and clearly distinguishes the scope from sibling subscription or IAP creation tools. The parenthetical clarifies the two purchase-option modes without ambiguity.

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?

It gives clear usage context: use this to create a new one-time product, then inspect the returned purchase-option state and call google_activate_purchase_option if it is DRAFT. It does not explicitly state when not to use it (e.g., use google_update_one_time_product for existing products) or mention prerequisites such as an edit session.

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

Deploy Server

Other Tools