play_get_inapp_productRetrieve a single Google Play in-app product by its SKU and package name to inspect its details.
Fetches one in-app product by SKU.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | Product SKU / product id | |
| packageName | Yes | Play Console package name, e.g. "com.example.app" |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it only implies a read via 'Fetches'. It does not disclose permission/auth requirements, error behavior for a missing SKU, or any rate/consistency traits for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the lookup key is stated immediately. It is appropriately sized, though extremely terse given the absence of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read with full schema coverage and no output schema, the description is minimally adequate. However, with no annotations it should ideally state the read-only nature and any auth/edit prerequisites, which it omits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both packageName and sku documented, so the baseline is 3. The description's 'by SKU' loosely confirms the selector key but adds no format or syntax detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Fetches'), resource ('in-app product'), and a scoping key ('by SKU'), which the agent can distinguish from the sibling play_list_inapp_products. It stops short of naming alternatives or exclusions, so it is clear but not sibling-differentiating in text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of prerequisites (e.g. edit-session or auth context), and no reference to alternatives like play_list_inapp_products or play_get_subscription. Usage is only weakly implied by 'by SKU'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.