Loading ToolBench

Reading the current corpus…

google-play-store-mcp MCP server · F · ToolBench

← Browse

google-play-store-mcp

github.com/hemati/google-play-store-mcp

MCP server exposing Google Play tools (reviews, reporting, purchases).

2026-07-28+STDIO0 tools

19/100

Definition Quality0

Protocol Readiness0

Supportability31

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Scoring was not performed

Issues (7)

CRITICALtool ↗

Output schemas not documented. No tool provides documentation of what fields and structure are returned. LLMs cannot plan downstream tool calls or extract necessary context (e.g., what fields does list_reviews return? Does it include review_id?). This is critical for composability.

list_reviewscrash_rate_queryanr_rate_querysubscriptions_v2_getlist_subscriptionslist_localized_listingsget_listingimages_listlist_locale_coverage

CRITICALconfirmation-request ↗

Destructive operations lack confirmation or dry-run pattern. images_deleteall and similar destructive tools (delete_all, publish) provide no opportunity for agents to preview or confirm before executing. This risks catastrophic errors.

images_deleteall

HIGHrecovery-guide ↗

Error handling guidance absent. Tool descriptions do not explain what errors can occur, how to recover, or what the agent should do if a call fails. For example, if clone_listing_to_locale fails, should the agent retry? Try a different language? Ask the user?

Recommendations

Document output schemas for every tool. Specify field names, types, and what they represent. Example: 'Returns: {reviews: [{review_id: string, rating: int 1-5, text: string, author: string, date: string (ISO 8601)}], total_count: int, has_more: boolean}'
Add explicit confirmation or dry-run support for destructive operations. For images_deleteall, add an optional 'dry_run' parameter that lists images that would be deleted without deleting them. Or require a confirmation_token returned by a separate preview call.
Enhance error descriptions with recovery guidance. Example: 'If clone_listing_to_locale fails with "language not supported", check available languages with list_localized_listings. If it fails with "source listing not found", verify the src_language exists.'
Clarify patch_listing vs update_listing in their descriptions. State explicitly: 'patch_listing: Updates only non-null fields (PATCH semantics). Use when modifying one or two fields. update_listing: Replaces the entire listing with provided values (PUT semantics). Use for complete replacement.' Alternatively, consolidate into a single tool.
Add format constraints to parameter descriptions. Example: 'start_date (string, YYYY-MM-DD format, required): Must be a valid date in YYYY-MM-DD format, e.g. "2024-01-15". Invalid formats will be rejected.'
Document pagination for list tools. Example: 'Returns up to max_results items. If total_count > returned items, use the cursor from the response to fetch the next batch. Always compare your batch size to total_count to determine if more data exists.'

Score history

Overall score trend

↓ 19 points across a rubric change (v1 → v2)

19/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	F	19	2026-07-28+	v2
2026-03-09	F	38	-	v1