Skip to main content
Glama
mambalabsdev

App Store and Google Play Review Monitor MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

App Store and Google Play Review Monitor MCP Server

Smithery Glama score MCP Registry npm version npm downloads license mcpservers.org

An MCP server for the Mamba Labs App Store and Google Play Review Monitor actor on Apify. Give it apps. It returns their reviews by country store, newest first, and on a schedule only the reviews posted since the last run.

What's Inside

Related MCP server: weekly-pulse MCP server

What it does

  • Reviews: Apple App Store and Google Play, in one row layout: stars, title, text, author, app version, date, helpful votes, and the developer reply where Google Play shows one.

  • Only new reviews: with a state_key, each run skips the reviews an earlier run returned, per app and country.

  • Rating trend: one app_summary row per app and country store with the app rating, rating count, the change since the last run, and the star split of the new reviews.

  • Developer domain: every row carries the developer name, website, and domain.

Input with no app comes back as one free row whose error_reason starts with input_invalid:.

All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-app-store-google-play-review-monitor": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-app-store-google-play-review-monitor"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The monitor_app_reviews tool appears.

Prerequisites

Example prompts

  • "Pull the 50 newest App Store and Google Play reviews for Slack in the US."

  • "Which 1 and 2 star reviews did Notion get in the UK App Store in the last 30 days?"

  • "Check my competitors' apps every morning and tell me what new reviews came in and whether their rating moved."

Tool

monitor_app_reviews. One tool. Example arguments:

{
  "apps": [
    "https://apps.apple.com/us/app/slack/id618783545",
    "com.Slack"
  ],
  "countries": [
    "us"
  ],
  "max_reviews_per_app": "50",
  "state_key": "slack-reviews-daily"
}

Inputs

Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and booleans are sent as strings.

Input

Type

Description

apps

array

One per line: an App Store URL (https://apps.apple.com/us/app/slack/id618783545), an App Store id (id618783545), a Google Play URL, or a Google Play package name (com.Slack). Up to 100 apps per run

countries

array

Two letter store codes, one per line, for example us, gb, de. Default us. Up to 10. App Store reviews are separate per country. Google Play shows the same reviews in every country for one language, so its reviews are returned once, under the first country, and each other country gets its own rating row

max_reviews_per_app

string

Most reviews returned per app and country store in one run, newest first. Default 100. The App Store feed serves at most 500 per country; Google Play up to 2000

since

string

Optional. Only reviews on or after this date (YYYY-MM-DD), or within this many days (30)

star_ratings

array

Optional. Only return reviews with these star ratings, for example 1 and 2 for complaints. Empty returns all

only_new

string

Default true. Each run remembers the reviews it returned, per app and country, under the state key

state_key

string

Names the saved state. Use one key per schedule, for example competitor-apps-daily

reset_state

string

true forgets the reviews returned before, so this run starts over

include_summary

string

Default true: one row per app and country store with the rating, rating count, change since the last run, and the stars of the new reviews

language

string

Language code for Google Play reviews and pages. Default en

max_charge_usd

string

Optional. The run stops before it would charge more than this

proxy_mode

string

A reliability choice. Default auto

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

review-row, one App Store or Google Play review returned

$0.0001

$9.5e-05

$9e-05

$8.5e-05

app-summary, one app and country store checked: the app rating, rating count, change since the last run, and the stars of the new reviews. Off when include_summary is false

$0.001

$0.00095

$0.0009

$0.00085

apify-actor-start, per run start

$0.0006563

$0.0006563

$0.0006563

$0.0006563

Rows for an app or input that could not be read are free.

Your keys

The actor needs no key. It reads Apple's public iTunes lookup service and reviews feed, and the public Google Play pages, and holds no key of any kind. Proxy traffic adds nothing to your price: Mamba Labs pays the platform costs of the run. proxy_mode is a reliability setting.

Full actor documentation

apify.com/mambalabs/app-store-google-play-review-monitor

License

MIT. See LICENSE.

Available Tools

1 tool
monitor_app_reviewsMonitor App Store and Google Play reviewsA
Read-only

Return App Store and Google Play reviews for the apps you give, by country store, newest first. Give apps as App Store URLs or ids (id618783545) or Google Play URLs or package names (com.Slack). With a state_key, each run returns only reviews not returned by an earlier run with that key. Every review row carries stars, title, text, author, app version, date, helpful votes, the Google Play developer reply, and the developer name, website, and domain. One app_summary row per app and country store gives the app rating, rating count, change since the last run, and the star split of the new reviews. Google Play reviews are per language, so they come back once under the first country. Input with no app comes back as one free row with error_reason input_invalid. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per review row and per app trend row.

NameRequiredDescriptionDefault
appsNoOne per line: an App Store URL (https://apps.apple.com/us/app/slack/id618783545), an App Store id (id618783545), a Google Play URL, or a Google Play package name (com.Slack). Up to 100 apps per run
sinceNoOptional. Only reviews on or after this date (YYYY-MM-DD), or within this many days (30)
languageNoLanguage code for Google Play reviews and pages. Default en
only_newNoDefault true. Each run remembers the reviews it returned, per app and country, under the state key
countriesNoTwo letter store codes, one per line, for example us, gb, de. Default us. Up to 10. App Store reviews are separate per country. Google Play shows the same reviews in every country for one language, so its reviews are returned once, under the first country, and each other country gets its own rating row
state_keyNoNames the saved state. Use one key per schedule, for example competitor-apps-daily
proxy_modeNoA reliability choice. Default auto
reset_stateNotrue forgets the reviews returned before, so this run starts over
star_ratingsNoOptional. Only return reviews with these star ratings, for example 1 and 2 for complaints. Empty returns all
max_charge_usdNoOptional. The run stops before it would charge more than this
include_summaryNoDefault true: one row per app and country store with the rating, rating count, change since the last run, and the stars of the new reviews
max_reviews_per_appNoMost reviews returned per app and country store in one run, newest first. Default 100. The App Store feed serves at most 500 per country; Google Play up to 2000

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, and the description adds substantial context beyond them: it requires an APIFY_TOKEN, describes per-row Apify charges, explains state persistence via state_key, and documents failure/error behavior including invalid input returning an error_reason row.

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 dense but appropriately front-loaded, leading with what is returned and the accepted app identifier formats. It is longer than typical, but nearly every sentence carries operational meaning for a 12-parameter tool; minor tightening is possible around return-field enumeration.

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?

Although there is no output schema, the description explains the review row fields, the app_summary row, Google Play language/country nuances, error returns, authentication needs, and cost implications. This is complete enough for an agent to invoke the tool correctly and interpret its output shape.

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 100%, so parameter definitions are already strong. The description still adds meaningful semantics beyond the schema, especially the Google Play per-language/per-country return behavior, the purpose of state_key across scheduled runs, and the fact that only_new remembers prior returned reviews per app and country.

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 states a specific verb and resource: returning App Store and Google Play reviews for given apps, by country store, newest first. It also distinguishes the accepted app identifier formats and the incremental state behavior, so an agent can immediately understand what the tool does.

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 gives clear usage context: provide apps as URLs or ids, use a state_key per schedule to get only new reviews, use reset_state to start over, and expect charges per review and trend row. There are no sibling tools to differentiate against, and no explicit 'when not to use' guidance, but the operational conditions are well covered.

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.

  1. 1 tool updatev1.0.0
    • First observedmonitor_app_reviews
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

A4.6/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of confusing it with another. Its description clearly frames it as a read-only review retrieval operation for two named app stores.

Naming Consistency5/5

The single name monitor_app_reviews follows a clean verb_noun snake_case convention that reads predictably and matches the domain. No competing conventions exist to clash with it.

Tool Count4/5

A single, purpose-built tool is appropriate for a narrowly scoped review-monitoring service, and this one is feature-dense (both stores, incremental state, summaries). It falls just short of the ideal 3-15 range, though adding tools here would likely be artificial.

Completeness4/5

The tool covers the full read path: fetch reviews, track new-vs-seen via state_key, and return per-app/country trend summaries with rich row fields. Minor gaps exist — no way to inspect or reset a state_key, no app lookup/metadata, and read-only by design — but core monitoring workflows are covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers