How do I use ASO MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ASO MCP Server suggest keywords for meditation" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ASO MCP Server

by RankoR

Overview Schema Source Related Servers Discussions Admin

Python

Remote

ASO MCP Server

A Model Context Protocol (MCP) server for App Store Optimization (ASO) research in Google Play Store.

Please note: This MCP is a very early feature-limited prototype and is not yet ready for production use.

Built on top of google-play-scraper - a Python library for scraping Google Play Store data.

Features

App Search - Search for apps by keyword with price filtering
App Details - Get comprehensive information about any app
App Reviews - Fetch user reviews with sorting, filtering, and pagination
Collections & Categories - Browse top free, top paid, and grossing apps by category
Keywords Research - Get keyword suggestions from Google Play Store autocomplete
Metadata Validation - Validate titles, short descriptions, and full descriptions against Google Play limits
Country & Language Support - Access all Google Play supported countries and languages
Proxy Rotation - Optional proxy support with automatic rotation and retry on failure

Related MCP server: play-console-mcp

Installation

Prerequisites

Python 3.14+
uv (recommended) or pip

Setup

# Clone the repository
git clone <repository-url>
cd aso-mcp-python

# Install dependencies with uv
uv sync

# Or with pip
pip install -e .

# Install development dependencies (for testing)
uv sync --dev
# Or with pip
pip install -e ".[dev]"

Usage

Running the Server

uv run python server.py

Integration with AI Assistants

Claude Code

Add to ~/.claude/settings.json:

{
  "mcpServers": {
    "aso": {
      "command": "uv",
      "args": [
        "run",
        "python",
        "server.py"
      ],
      "cwd": "/path/to/aso-mcp-python"
    }
  }
}

Gemini CLI

Add to ~/.gemini/settings.json:

{
  "mcpServers": {
    "aso": {
      "command": "uv",
      "args": [
        "run",
        "python",
        "server.py"
      ],
      "cwd": "/path/to/aso-mcp-python"
    }
  }
}

Available Tools

App Search & Discovery

`google-play-search`

Search for apps in Google Play Store by keyword.

Parameters:

country (string) - Country code (e.g., us, de, jp)
language (string) - Language code (e.g., en, de, ja)
term (string) - Search term
num (integer, optional) - Number of results (default: 20)
price (string, optional) - Price filter: "all", "free", or "paid" (default: "all")

Returns: List of app overviews with basic info (title, developer, score, etc.)

`google-play-list`

Browse Google Play Store collections and categories.

Parameters:

country (string) - Country code
language (string) - Language code
collection (string) - Collection type: "TOP_FREE", "TOP_PAID", or "GROSSING"
category (string) - Category (e.g., "APPLICATION", "GAME_ACTION", "PRODUCTIVITY")
num (integer, optional) - Number of results (default: 50)
age (string, optional) - Age filter: "AGE_RANGE1" (5 and under), "AGE_RANGE2" (6-8), or "AGE_RANGE3" (9+)

Available Categories:

General: APPLICATION, GAME, FAMILY
App Categories: BUSINESS, EDUCATION, ENTERTAINMENT, FINANCE, HEALTH_AND_FITNESS, PRODUCTIVITY, TOOLS, and more
Game Categories: GAME_ACTION, GAME_ADVENTURE, GAME_PUZZLE, GAME_RACING, GAME_STRATEGY, and more

Returns: List of app overviews

`google-play-app`

Get comprehensive details about a specific app.

Parameters:

country (string) - Country code
language (string) - Language code
app_id (string) - App package ID (e.g., "com.spotify.music")

Returns: Detailed app information including:

Basic info (title, developer, summary, descriptions)
Ratings (score, reviews count, histogram)
Pricing (price, currency, in-app purchases)
Install statistics (installs, min/max installs)
Media (icon, screenshots, video, header image)
Technical details (version, Android version, release/update dates)
Contact info (email, website, address)
Legal (content rating, privacy policy)

`google-play-reviews`

Get user reviews for a specific app with pagination support.

Parameters:

country (string) - Country code
language (string) - Language code
app_id (string) - App package ID
sort (string, optional) - Sort order: "newest", "rating", or "helpfulness" (default: "newest")
num (integer, optional) - Number of reviews (default: 100)
filter_rating (integer, optional) - Filter by rating (1-5)
continuation_token (string, optional) - Token for fetching next page

Returns: Reviews with user info, rating, text, developer reply (if any), and pagination token for next page

Keywords Research

`google-play-suggest`

Get keyword suggestions for a given seed keyword.

Parameters:

country (string) - Country code (e.g., us, de, jp)
language (string) - Language code (e.g., en, de, ja)
keyword (string) - Seed keyword or partial keyword

Example:

country: "us"
language: "en"
keyword: "calc"

Returns: List of suggested keywords like ["calculator", "calculator app", "calculator free", ...]

Metadata Validation

`google-play-validate-title`

Validate a title against Google Play's 30 character limit.

Parameters:

title (string) - Title to validate

`google-play-validate-short-description`

Validate a short description against Google Play's 80 character limit.

Parameters:

short_description (string) - Short description to validate

`google-play-validate-full-description`

Validate a full description against Google Play's 4000 character limit.

Parameters:

full_description (string) - Full description to validate

Returns: Validation result with length, validity status, and any errors.

Reference Data

`get-google-play-languages`

Get all language codes supported by Google Play.

`get-google-play-countries`

Get all country codes supported by Google Play.

`get-google-play-countries-with-languages`

Get country codes mapped to their supported languages.

Proxy Configuration

The server supports optional proxy rotation for requests to Google Play. This is useful for:

Avoiding rate limiting
Geographic distribution of requests
IP rotation

Setup

Set the ASO_MCP_PROXIES environment variable with a comma-separated list of proxy URLs:

export ASO_MCP_PROXIES="http://proxy1:8080,http://proxy2:8080,http://user:pass@proxy3:8080"

With Claude Code

{
  "mcpServers": {
    "aso": {
      "command": "uv",
      "args": [
        "run",
        "python",
        "server.py"
      ],
      "cwd": "/path/to/aso-mcp-python",
      "env": {
        "ASO_MCP_PROXIES": "http://proxy1:8080,http://proxy2:8080"
      }
    }
  }
}

With Gemini CLI

{
  "mcpServers": {
    "aso": {
      "command": "uv",
      "args": [
        "run",
        "python",
        "server.py"
      ],
      "cwd": "/path/to/aso-mcp-python",
      "env": {
        "ASO_MCP_PROXIES": "http://proxy1:8080,http://proxy2:8080"
      }
    }
  }
}

How Proxy Rotation Works

On each request, a random proxy is selected from the pool
If a request fails, the proxy is marked as failed and a different proxy is tried
Failed proxies are avoided until all proxies have failed
When all proxies fail, the failed list resets and rotation starts over
Credentials in proxy URLs are masked in logs for security

Supported Proxy Formats

http://host:port
http://username:password@host:port
https://host:port
https://username:password@host:port

Google Play Metadata Limits

Field	Character Limit
Title	30
Short Description	80
Full Description	4000

Supported Countries

The server supports 60+ countries including:

Region	Countries
Americas	US, CA, BR, MX
Europe	GB, DE, FR, ES, IT, NL, PL, and more
Asia Pacific	JP, KR, CN, IN, AU, SG, and more
Middle East	SA, IL, TR, and more

Use get-google-play-countries-with-languages to get the full mapping of countries to their supported languages.

Development

Project Structure

aso-mcp-python/
├── server.py                 # Main MCP server
├── proxy.py                  # Proxy rotation manager
├── constants/
│   ├── google_play_constants.py  # Countries, languages, limits, enums
│   └── mcp_constants.py          # Server instructions
├── models/
│   ├── google_play.py        # Data models (AppDetails, AppOverview, Review)
│   └── metadata.py           # Validation models
├── tests/
│   └── test_server.py        # Comprehensive test suite
├── pyproject.toml            # Project configuration
├── pytest.ini                # Pytest configuration
└── README.md

Dependencies

mcp[cli] - Model Context Protocol SDK
play-store-scraper-ng - Google Play Store scraper
httpx - HTTP client

Development Dependencies

pytest - Testing framework
pytest-asyncio - Async test support
pytest-mock - Mocking support

Running Tests

# Run all tests
uv run pytest

# Run with coverage
uv run pytest --cov=. --cov-report=html

# Run specific test file
uv run pytest tests/test_server.py

# Run specific test
uv run pytest tests/test_server.py::TestSearch::test_google_play_search_success

# Run with verbose output
uv run pytest -v

The test suite includes:

Unit tests for all tools
Mock-based tests (no actual API calls)
Proxy rotation and failure scenarios
Input validation tests
Pagination tests for reviews

License

MIT

Available Tools

16 tools

get-google-play-age-filtersA

Get list of age filters for browsing (FIVE_UNDER, SIX_EIGHT, NINE_UP)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 full burden. It discloses the tool returns a list of age filters but does not mention if it is read-only, cached, or requires authentication. The behavior is simple, so minimal transparency is acceptable.

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?

The description is a single, clear sentence that is front-loaded with the purpose and includes example values. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity and the presence of an output schema, the description is minimally adequate. However, it lacks information about when this tool is needed (e.g., as a prerequisite for searches) or any behavioral caveats.

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?

There are no parameters, so schema coverage is 100%. The description adds value by listing the expected filter values, which is useful beyond the empty schema.

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 clearly states the verb 'Get' and the resource 'age filters for browsing', and lists the specific filter values (FIVE_UNDER, SIX_EIGHT, NINE_UP), which distinguishes it from sibling tools like get-google-play-rating-filters.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool vs alternatives, nor does it mention prerequisites or context. For example, it does not indicate that this filter is needed for browsing or search tools.

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

get-google-play-categoriesA

Get list of app categories in Google Play Store

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/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 burden. It states a simple list retrieval but adds no details about idempotency, rate limits, or return format. Adequate but not thorough.

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?

A single sentence with no extraneous information. Every word serves a purpose.

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?

Given the tool has no parameters and an output schema exists, the description is mostly complete. It could mention the output format, but the output schema handles that. Slightly lacking for a simple 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?

There are no parameters, so the baseline is 4. The description does not add parameter information, but none is needed.

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 'Get list of app categories in Google Play Store' clearly states the verb 'Get' and the resource 'list of app categories', with context 'Google Play Store'. It is specific and distinguishes from sibling tools like 'get-google-play-collections'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its many siblings, such as 'get-google-play-collections' or 'get-google-play-countries'. Usage context is only implied.

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

get-google-play-collectionsA

Get list of collection types for browsing Google Play Store (TOP_FREE, TOP_PAID, GROSSING)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description carries the full burden. It does not disclose any behavioral traits (e.g., side effects, authentication needs, rate limits) beyond the basic purpose. However, for a simple read-only list without parameters, this is minimally adequate.

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?

The description is a single concise sentence, front-loaded with the key action and result. Every word is essential and adds value.

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?

Given the presence of an output schema, the description does not need to explain return values. It adequately conveys the tool's purpose and scope. Some may argue for a 5, but it could briefly mention that no parameters are required (though schema implies it).

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?

There are no parameters (0 params), and the schema coverage is 100%. The description adds no parameter-specific information, but per guidelines, a baseline of 4 is appropriate for zero-parameter tools.

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 clearly states the tool returns a list of collection types for Google Play Store, with specific examples (TOP_FREE, TOP_PAID, GROSSING). This distinguishes it from sibling tools that deal with filters, languages, etc.

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

Usage Guidelines3/5

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

The description implies usage for browsing collections but provides no explicit guidance on when to use this tool versus siblings, nor any exclusions or prerequisites.

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

get-google-play-countriesA

Get list of country codes supported by Google Play

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It indicates a read operation but provides no details on authentication, rate limits, or any side effects. For a 0-parameter tool, more could be said about the output nature.

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?

The description is a single sentence with no wasted words. It is front-loaded with the action and resource.

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?

Given no parameters and an output schema exists, the description is mostly complete. It could mention that it returns an array of country codes, but the output schema likely covers that.

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?

There are no parameters, and schema coverage is 100%. Per guidelines, baseline for 0 parameters is 4. The description does not add parameter info, but none is needed.

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 clearly states the tool retrieves a list of country codes supported by Google Play. The verb 'Get' and resource 'list of country codes supported by Google Play' are specific. It distinguishes from sibling tools like get-google-play-age-filters and get-google-play-languages.

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

Usage Guidelines2/5

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

No guidelines are provided on when to use this tool versus alternatives like get-google-play-countries-with-languages. The description only states what it does without context for selection.

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

get-google-play-countries-with-languagesA

Get list of country codes mapped with a list of languages in these countries supported by Google Play

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavioral traits. It only states the output type without details on pagination, rate limits, or authentication requirements. The agent lacks information on how the tool behaves beyond its basic function.

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?

The description is a single, clear sentence that front-loads the essential information. No unnecessary words.

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?

Given zero parameters and the presence of an output schema (from context signals), the description is fairly complete. It could mention the data format (e.g., a map or list) but is adequate for a simple lookup 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?

The tool has zero parameters, so the description does not need to add parameter meaning. Schema coverage is 100% vacuously. Baseline 4 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?

The description clearly states the tool retrieves a mapping of country codes to languages supported by Google Play. It distinguishes from siblings like get-google-play-countries and get-google-play-languages by combining both concepts.

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

Usage Guidelines3/5

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

The description implies usage for obtaining the combined mapping, but does not explicitly specify when to use this tool over related siblings (e.g., get-google-play-countries, get-google-play-languages). The context signals list these siblings, but no guiding text is provided.

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

get-google-play-languagesA

Get list of language codes supported by Google Play

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

The description implies a read-only operation ('Get list'), but does not elaborate on safety, idempotency, or other behavioral traits. With no annotations, the description carries minimal burden given the tool's simplicity.

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?

The description is a single sentence that directly states the tool's purpose with no extraneous words. It is optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description sufficiently explains what the tool returns (language codes). No additional context is necessary.

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?

There are zero parameters, so the description does not need to add parameter information. The baseline of 4 applies.

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 clearly states the verb ('Get') and the resource ('list of language codes supported by Google Play'), distinguishing it from sibling tools that fetch other types of lists (e.g., countries, categories).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for its use.

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

get-google-play-rating-filtersA

Get list of valid rating filters for reviews (1-5)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It states a safe read operation (get list) but does not mention rate limits, authentication, or any side effects. The behavioral context is minimal and implied.

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?

The description is a single sentence that is front-loaded with the key information, with no wasted words. It is perfectly concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there are no parameters and an output schema exists, the description is complete. It tells the agent exactly what the tool does and the range of valid values, requiring no further detail.

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?

There are no parameters, so the description does not need to explain them. The baseline for 0-param tools is 4, and the description adds no confusion.

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 uses a specific verb (Get) and resource (list of valid rating filters for reviews) and includes the range (1-5), making the purpose clear and distinct from sibling tools like get-google-play-age-filters.

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?

The description clearly indicates the tool is for retrieving rating filters, which implies usage when filtering reviews. However, it does not explicitly state when not to use it or mention alternatives, but given its simplicity, the context is clear.

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

get-google-play-sort-ordersA

Get list of sort orders for reviews (NEWEST, RATING, HELPFULNESS)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states it 'get list', offering no details about read-only nature, authentication requirements, or potential rate limits.

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?

Single sentence with exactly the needed information, no filler. Front-loaded with verb and noun.

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?

Given no parameters and presence of an output schema (not shown), the description adequately conveys the tool's purpose. However, explicitly stating the return type (e.g., 'array of strings') would enhance clarity.

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?

The tool has zero parameters and schema coverage is 100%, so baseline is 4. The description adds no parameter information, but none is needed.

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?

Description clearly states the tool retrieves a list of sort orders for reviews, with examples (NEWEST, RATING, HELPFULNESS). This distinctly sets it apart from siblings like get-google-play-reviews, which uses these orders.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. It does not mention its role as a prerequisite for constructing review queries, leaving the agent to infer usage context.

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

google-play-appC

Get detailed information about a specific app

ParametersJSON Schema

Name	Required	Description	Default
`app_id`	Yes
`country`	Yes
`language`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`free`	No
`icon`	No
`genre`	No
`price`	No
`score`	No
`title`	Yes
`video`	No
`app_id`	Yes
`ratings`	No
`reviews`	No
`summary`	No
`updated`	No
`version`	No
`comments`	No
`currency`	No
`genre_id`	No
`installs`	No
`released`	No
`available`	No
`developer`	No
`histogram`	No
`offers_iap`	No
`price_text`	No
`score_text`	No
`description`	No
`screenshots`	No
`developer_id`	No
`header_image`	No
`max_installs`	No
`min_installs`	No
`content_rating`	No
`privacy_policy`	No
`recent_changes`	No
`android_version`	No
`developer_email`	No
`description_html`	No
`developer_address`	No
`developer_website`	No

TDQS

C2.1/5.0

Behavior2/5

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

With no annotations, the description must fully convey behavioral traits. It only states 'get detailed information', omitting critical details like read-only nature, pagination, authentication requirements, or return format. The output schema exists but is not referenced. This under-disclosure forces the agent to guess behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short (one sentence), but it lacks necessary detail. It is under-specified rather than concise. Every word should earn its place, but here the brevity comes at the cost of clarity and completeness.

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?

The tool has 3 required parameters and an output schema, yet the description fails to explain the output or how to effectively use the parameters. Given the complexity and the presence of sibling tools, the description is incomplete, offering only a minimal characterization.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description adds no information about what app_id, country, or language mean or how to format them (e.g., IS codes). The agent must rely solely on parameter names, which is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'get' and resource 'detailed information about a specific app', which indicates the tool's purpose. However, it does not specify what kind of detailed information, making it somewhat vague compared to siblings like google-play-search which search for apps. It is clear but not specific.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as google-play-search or google-play-list. The description does not mention prerequisites or typical use cases, leaving the agent to infer usage without support.

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

google-play-listC

Browse Google Play Store collections (top free, top paid, grossing) by category

ParametersJSON Schema

Name	Required	Description	Default
`age`	No
`num`	No
`country`	Yes
`category`	Yes
`language`	Yes
`collection`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the abstract action, but does not mention pagination, rate limits, data freshness, or the read-only nature. The agent cannot infer important constraints from the description alone.

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 a single concise sentence that front-loads the verb and resource. Every word adds value, and there is no redundancy. However, it could be slightly expanded to cover key parameters without losing conciseness.

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?

Given the presence of many sibling tools and multiple parameters, the description is insufficient. It lacks mention of output format, filtering options, or relationship to other tools. The agent would need extensive schema inspection to use it correctly.

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 0%, and the description adds minimal parameter context. Although 'by category' hints at the category parameter, it does not explain country, language, num, or age. The agent would need to rely solely on schema names and enums, which are not descriptive enough.

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 clearly states the verb 'Browse' and the resource 'Google Play Store collections', specifying the types (top free, top paid, grossing) and the dimension 'by category'. This effectively distinguishes from sibling tools like google-play-search (which likely finds specific apps) and google-play-app (which gets details of a single app).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as google-play-search or google-play-app. The description does not mention context, prerequisites, or exclusions, leaving the agent without decision support.

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

google-play-reviewsC

Get user reviews for a specific app with pagination support

ParametersJSON Schema

Name	Required	Default
`num`	No
`sort`	No	2
`app_id`	Yes
`country`	Yes
`language`	Yes
`filter_rating`	No
`continuation_token`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`reviews`	Yes
`continuation_token`	No

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only mentions pagination support but does not explain other behavioral aspects such as rate limits, authentication requirements, whether reviews are sorted by recency or relevance, or what happens when the continuation_token is omitted.

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 very short and front-loaded, containing only one sentence. It wastes no words, but the extreme brevity sacrifices necessary detail.

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?

Given the absence of annotations and the tool's complexity (7 parameters including pagination and filters), the description is too sparse. It does not explain the output, the meaning of the continuation token, or how filtering works, leaving the agent to rely solely on parameter names which are cryptic.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter descriptions are provided in the schema. The tool description adds no additional meaning for any of the 7 parameters (e.g., sort, num, filter_rating, continuation_token). The enum values for sort are cryptic (2,3,1) with no explanation.

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 clearly states the tool retrieves user reviews for a specific app with pagination support. It uses a specific verb ('Get') and resource ('user reviews'), and the mention of pagination distinguishes it from sibling tools that handle other things like age filters, rating filters, or app details.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context about when it is appropriate to call this tool over related sibling tools like google-play-search or google-play-app.

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

google-play-searchD

Search for apps in Google Play Store

ParametersJSON Schema

Name	Required	Default
`num`	No
`term`	Yes
`price`	No	all
`country`	Yes
`language`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.8/5.0

Behavior1/5

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

With no annotations provided, the description must disclose behavioral traits, but it only states the purpose without mentioning any side effects, permissions, rate limits, or result formats. No information about search behavior (e.g., pagination, exact vs. fuzzy matching) is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence, but it is under-specified. It does not provide enough information to justify its brevity, as critical details are missing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, many siblings, and an output schema that is not referenced, the description is severely incomplete. It fails to cover basic usage context, parameter constraints, or expected output.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no information about parameters. The schema provides names and defaults but no explanation of valid values (e.g., 'price' default 'all' but no enumeration of allowed values).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search for apps in Google Play Store' clearly states the verb 'search' and resource 'apps', but it is generic and does not differentiate from sibling tools like 'google-play-list' or 'google-play-app', which may also involve searching or retrieving apps.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as 'google-play-list' or 'google-play-suggest'. There are no exclusion criteria or context for optimal usage.

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

google-play-suggestC

Get keywords suggestions for the given keyword in Google Play Store

ParametersJSON Schema

Name	Required	Description	Default
`country`	Yes
`keyword`	Yes
`language`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that the tool is read-only, any authentication requirements, rate limits, or the nature of suggestions (e.g., autocomplete vs related keywords). This lack of transparency could lead to misuse.

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 extremely concise at one sentence, which is efficient. However, it sacrifices important details for brevity. It could be restructured to front-load key information and include essential context without being verbose.

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?

Given that there are three required parameters, no schema descriptions, and no annotations, the description is insufficiently complete. It does not cover the purpose of each parameter or how the tool behaves, leaving the agent with significant ambiguity.

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 0%, so the description should add meaning to parameters. However, it only mentions 'keyword' implicitly and provides no explanation for 'country' or 'language'. The bare parameter names are insufficient for an agent to understand their valid values or formatting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (get suggestions), the resource (keywords suggestions), and the context (Google Play Store). It distinguishes the tool from siblings like google-play-search and google-play-list, though it could be more precise about the type of suggestions.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context that would help an agent decide to invoke this tool over others.

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

google-play-validate-full-descriptionC

Validate full description for Google Play Store

ParametersJSON Schema

Name	Required	Description	Default
`full_description`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`errors`	No
`length`	Yes
`is_valid`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, and the description does not explain what 'validate' entails (e.g., length checks, content rules, or whether it returns errors/boolean). The agent cannot infer side effects or behavior beyond a generic validation operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no extraneous words, but it is too brief and lacks substance. It meets conciseness but sacrifices informativeness.

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?

Given the tool has one parameter and no annotations, the description is insufficient for an agent to understand the validation criteria. Although an output schema exists, the description does not hint at the nature of validation results (e.g., pass/fail, error list), leaving the tool's behavior unclear.

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

Parameters1/5

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

With 0% schema description coverage, the description adds no meaning beyond the parameter name 'full_description'. It does not specify constraints (e.g., max length, required format) or provide examples, leaving the agent guessing about valid input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it validates a full description for Google Play Store, distinguishing it from siblings like 'validate-title' and 'validate-short-description' by specifying 'full description'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings (e.g., google-play-validate-title, google-play-validate-short-description). The description does not help an agent decide which validation tool to invoke.

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

google-play-validate-short-descriptionD

Validate short description for Google Play Store

ParametersJSON Schema

Name	Required	Description	Default
`short_description`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`errors`	No
`length`	Yes
`is_valid`	Yes

TDQS

D1.7/5.0

Behavior1/5

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It fails to mention authentication, side effects, whether it is synchronous, or what happens on validation failure. The return value or output schema is not referenced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is short, it is underspecified and does not earn its place. It repeats the tool name without adding value. A concise description should pack meaningful information; this one sacrifices completeness for brevity.

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?

Given the domain (Google Play Store validation) and the existence of multiple sibling validation tools, the description is incomplete. It does not explain what 'validate' means here (e.g., policy compliance, character count), nor does it hint at the output (e.g., boolean, error list). The output schema exists but is not leveraged.

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

Parameters1/5

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

The sole parameter 'short_description' has no description in the input schema (0% coverage). The tool description adds no constraints, formatting requirements, or accepted ranges, leaving the agent without guidance on valid input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Validate short description for Google Play Store' is essentially a restatement of the tool name. It does not specify what validation entails (e.g., length, content rules) or how it differs from sibling tools like 'validate-title' or 'validate-full-description'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings (e.g., google-play-validate-title, google-play-validate-full-description). The agent is left to infer usage context without explicit direction.

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

google-play-validate-titleC

Validate title for Google Play Store

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`errors`	No
`length`	Yes
`is_valid`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavior. It only says 'validate' without explaining what happens (e.g., returns boolean, throws error, provides suggestions). This significantly limits agent understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but sacrifices necessary detail. It is front-loaded but incomplete for effective tool use.

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?

Despite having an output schema (not provided), the description does not mention what the output represents (e.g., valid/invalid, error messages). For a simple tool with one parameter, the description should at least hint at the return value or validation criteria.

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 coverage is 0%, so the description should compensate. It merely restates 'title' from the parameter name and gives no details about valid formats, maximum length, or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it validates a title for Google Play Store. The tool name includes 'title', distinguishing it from sibling validation tools for descriptions. However, it doesn't specify what validation entails (e.g., length, format, availability).

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

Usage Guidelines2/5

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

No usage guidance is provided. The description does not indicate when to use this tool (e.g., before submitting a title) or mention alternatives among siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

16 tool updatesv0.1.0Jul 28, 2026
- First observedget-google-play-age-filters
- First observedget-google-play-categories
- First observedget-google-play-collections
- First observedget-google-play-countries
- First observedget-google-play-countries-with-languages
- First observedget-google-play-languages
- First observedget-google-play-rating-filters
- First observedget-google-play-sort-orders
- First observedgoogle-play-app
- First observedgoogle-play-list
- First observedgoogle-play-reviews
- First observedgoogle-play-search
- First observedgoogle-play-suggest
- First observedgoogle-play-validate-full-description
- First observedgoogle-play-validate-short-description
- First observedgoogle-play-validate-title

Deploy Server

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

TDQS

B3.2/5.0

Scored 2026-07-28 06:10 across 16 tools

Disambiguation5/5

All tools have distinct purposes: retrieving metadata options (age filters, ratings, languages, etc.), search, listing collections, app details, reviews, suggestions, and validation. No two tools overlap in functionality.

Naming Consistency5/5

Naming follows a consistent pattern: 'get-google-play-*' for metadata retrieval and 'google-play-*' for actions (search, list, app, reviews, suggest, validate). All lowercase with hyphens, making it predictable.

Tool Count4/5

With 16 tools, it is slightly above the typical 3-15 range but still well-scoped. Each tool serves a necessary function for ASO tasks, and the count does not feel excessive.

Completeness5/5

The tool set covers all essential ASO operations: searching, browsing, app details, reviews, suggestions, metadata options, and validation of titles and descriptions. No obvious gaps for querying Google Play data.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

app-data C
io.github.DataLeadsPRO
App intelligence across Google Play and the App Store: details, reviews, and search in one API.
Search Open Data
51
mcp A
com.getappniche
Live App Store & Google Play data for AI agents: app discovery, ASO keywords, reviews.
Marketing Search E-commerce & Retail
72
sonar A
app.trysonar
ASO tools for AI agents: keyword research, rank tracking, competitor analysis (iOS & Android).
Marketing AI & Machine Learning Developer Tools
521
ASO AtlasOAuth
com.asoatlas
App Store keyword research, rank tracking and App Store Connect performance for your iOS apps.
Marketing Research & Data
1

Related MCP Servers

Store Scraper MCP
Web Scraping Search E-commerce & Retail
MiguelAlvRed
F
license
C
quality
D
maintenance
Enables querying and retrieving data from App Store and Google Play Store, including app details, reviews, ratings, rankings, permissions, and search capabilities across both iOS and Android platforms.
Updated 9 months ago (2025-12-14 21:27 UTC)
20
-
play-console-mcp
CI/CD & DevOps Monitoring Customer Support
OrellBuehler
A
license
A
quality
A
maintenance
Enables AI agents to manage Google Play Console reviews and Android app releases, including replying to reviews, promoting releases, managing staged rollouts, and checking crash/ANR vitals.
Updated 21 days ago (2026-09-03 03:45 UTC)
44
20 npm
1
MIT
storelift-mcp
Marketing Search
vom-core
A
license
A
quality
A
maintenance
Enables App Store and Google Play keyword rank tracking, competitor comparisons, and AI visibility checks through natural language, without requiring store credentials.
Updated 10 days ago (2026-09-14 11:56 UTC)
8
209 npm
1
MIT
playstore-release
CI/CD & DevOps Developer Tools
beydemirfurkan
A
license
Not graded
quality
B
maintenance
Enables end-to-end Android app publishing to Google Play via the Developer API, including readiness checks, releases, promotions, reviews, and subscriptions.
Updated a day ago (2026-09-22 19:55 UTC)
MIT