Google Play MCP

raw_request

Call any Google Play Android Publisher API endpoint not covered by dedicated tools by supplying the HTTP method and relative path, with optional query parameters and JSON body.

Instructions

Make a raw Google Play Android Publisher API call — use this for ANY endpoint not covered by a dedicated tool (orders, purchases, voided purchases, one-time product writes, device tier configs, app recovery, users/grants, data safety, etc.). path is relative (e.g. '/applications/{packageName}/reviews') and '/androidpublisher/v3' is added automatically. Edit-scoped paths need an editId from insert_edit — remember to commit_edit or delete_edit. Non-GET calls obey safe mode. See developers.google.com/android-publisher/api-ref/rest.

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": {
      "method": "<method>",
      "path": "<path>"
    },
    "name": "raw_request"
  }
}

Input Schema

Name	Required	Description
`body`	No	JSON request body (for POST/PUT/PATCH)
`path`	Yes
`query`	No	Query params as a flat object
`method`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does disclose key traits: the '/androidpublisher/v3' prefix is auto-prepended, edit-scoped paths require an editId, edits must be committed or deleted, and non-GET calls are gated by safe mode. It does not cover auth/permission requirements or failure behavior, so it stops short of full disclosure.

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 purpose and fallback scope, then packed with operational constraints in a compact space. The parenthetical example list is long but functional, since it helps the agent recognize whether its endpoint is covered.

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?

For a generic passthrough with an unbounded endpoint surface and no output schema, the description covers the essential call-shaping rules (relative path, auto prefix, edit lifecycle, safe mode) and defers detail to the linked API reference. It leaves the response shape implicit, which is a minor gap for a raw-passthrough tool.

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

Parameters4/5

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

Schema coverage is 50% — body and query are described in the schema, while path and method are bare. The description compensates by explaining that path is relative, giving a concrete example ('/applications/{packageName}/reviews'), and noting the automatic version prefix, which is meaning the schema alone does not convey. Method values are already enumerated in the schema, so no credit there.

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?

States a specific verb and resource ('Make a raw Google Play Android Publisher API call') and immediately defines its scope as the catch-all for endpoints not covered by dedicated tools. The enumerated examples (orders, purchases, voided purchases, users/grants, data safety) make it unmistakable versus siblings like get_review or create_inapp_product.

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

Usage Guidelines5/5

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

Explicitly names when to use it ('ANY endpoint not covered by a dedicated tool') and when its edit-scoped paths apply, routing the agent to insert_edit for an editId and to commit_edit/delete_edit afterward. It also flags that non-GET calls obey safe mode, which is decision-relevant before invoking.

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

Deploy Server