Android Developer MCP by Nova (CIVAI)

upload_screenshot_asset

Upload an image into the app's Asset Library. NOTE: for store listing graphics use upload_store_listing_graphic instead — the Asset Library's image cannot be attached to a listing slot (it lacks the blobKey the listing requires, confirmed live). This tool is only for getting an image into the Asset Library itself.

Input Schema

Name	Required	Description
`image_url`	No	https URL the replay host fetches the image from — the route for anything over the base64 cap. Must be publicly resolvable (a URL that resolves to a private address is refused).
`image_path`	No	Absolute path ON THE REPLAY HOST, inside the secops container (repo root = /app). Only usable if you can already put files there — most operators cannot, so prefer image_base64 or image_url.
`play_app_id`	Yes	Numeric Play app id from the Play Console URL (.../app/<this>/...). NOT the package name.
`developer_id`	Yes	Numeric Play Console developer id (from the Play Console URL).
`image_base64`	No	The image's bytes as base64 (a data: URI prefix is fine) — the route that needs no file on the replay host and no hosting at all. Capped at 64 KiB of image because CLI steps receive their arguments in one environment variable and Linux caps that at 128 KiB; anything larger must use image_url. A 512x512 icon usually fits, a full-resolution screenshot usually does not.
`google_account_email`	Yes	The signed-in Google account email that owns this Play Console developer account. Call list_accounts first and confirm with the user — do not guess.
`notification_message`	No	Short user-facing sentence for this action if the follow-up reply fails. Plain text only; do not mention template syntax or variable names.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the Asset Library/blobKey limitation, which is important context beyond the schema, but it does not describe auth requirements, failure behavior, idempotency, or what the upload returns.

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?

The description is front-loaded and mostly efficient, with the purpose first and the critical sibling routing immediately after. The final sentence slightly restates the opening scope, keeping it just short of maximally concise.

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 mutation tool with no annotations and no output schema, the description covers the key selection concern: this is only for the Asset Library and not for store listing graphics. It does not explain the result of a successful upload, but the highly detailed input schema covers invocation semantics.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already explains each parameter in detail, including the base64 cap and URL restrictions. The description does not add further parameter semantics beyond what the schema provides, so the baseline 3 is appropriate.

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: uploading an image into the app's Asset Library. It also explicitly distinguishes this from the sibling tool upload_store_listing_graphic and clarifies the exact scope, so an agent can tell the two apart without inspecting their schemas.

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?

Gives explicit routing guidance: use this for Asset Library uploads, but use upload_store_listing_graphic for store listing graphics because the Asset Library image lacks the blobKey a listing slot requires. The alternative and when-not condition are both named directly.

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

All Android Developer MCP by Nova (CIVAI) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?