Mines public Apple App Store reviews: fetches top charts by category (free/paid/grossing) per country, searches for apps to resolve their IDs, and pulls recent reviews with rating mix, rating per version, top complaint phrases, and most helpful review texts, plus side-by-side comparisons of 2-8 apps.
Mines public Steam reviews and store data: fetches weekly top sellers, most played, and new releases, and retrieves recent reviews for a game filtered by language, with rating breakdowns and top complaint phrases; Steam games can be compared against App Store apps.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@review-miner Compare the reviews of the top 5 finance apps in Turkey. What does every one of them get wrong?"
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.
Find out what users hate about your competitors. An MCP server that mines public App Store and Steam reviews so Claude (or any MCP client) can turn thousands of complaints into product opportunities.
No API keys. No scraping. One line to install.
You: What do users hate about the top health & fitness apps in Turkey?
Claude: [review_top_apps → review_compare_apps]
• Strava: the most upvoted complaints ask for Turkish. "I was going to buy
Premium but I'm deleting it because there is no Turkish support."
• OKOK (smart scale): 61% of recent reviews are negative. You have to watch
ads before the app shows your own weight.
• MAC+: login and verification-code errors ("hata veriyor") dominate.
• HUAWEI Health: can't log in after switching phones or after updates.Summarized from real tool output: Turkish App Store, 1 Oct 2026, 150 recent reviews per app.
You want to know | Without it | With review-miner |
Why an app's rating dropped | Scroll reviews by hand |
|
What a whole category fails at | Read 5 apps × 500 reviews | One call compares them side by side |
Whether an idea has demand | Guess | Real complaints, with quotes and counts |
Related MCP server: partnerlens-mcp
flowchart LR
C[Claude / MCP client] -->|tool call| S[review-miner-mcp]
S --> A[Apple iTunes Search + RSS]
S --> T[Steam Store + Web API]
S --> X[Stats: rating mix, per-version rating,<br/>top complaint phrases]
X -->|compact summary + best review samples| CThe server does the cheap, deterministic part (fetching, counting, phrase extraction). The model does the interpretation. Only the most helpful review texts are returned, so your context window is not flooded.
Requires uv.
Claude Code
claude mcp add review-miner -- uvx review-miner-mcpClaude Desktop / Cursor (claude_desktop_config.json / .cursor/mcp.json)
{
"mcpServers": {
"review-miner": {
"command": "uvx",
"args": ["review-miner-mcp"]
}
}
}Tool | What it does |
| Current top charts: App Store by category (free / paid / grossing) or Steam weekly top sellers / most played / new releases |
| Find an app or game and get its ID |
| Recent reviews for one app: rating mix, rating per version, top complaint phrases, most helpful texts |
| 2–8 competitors side by side, App Store and Steam mixed |
Prompts: find_opportunities (category → product gaps), competitor_teardown (one app, love vs hate).
Every tool supports country (e.g. tr, de, us) and response_format (markdown / json).
"Compare the reviews of the top 5 finance apps in Turkey. What does every one of them get wrong?"
"Did Duolingo's latest version lower its rating? Show rating by version."
"What do negative Steam reviewers of Cyberpunk 2077 complain about, and how many hours had they played?"
"Run find_opportunities for health-fitness in Germany."
App Store: most recent ~500 reviews per country (Apple's feed limit).
App Store: Apple's review feed is sometimes empty for an app/country for a while. The server retries equivalent feed URLs automatically; if all are empty it tells you so instead of reporting "no reviews". Retrying a few minutes later or trying another country usually works.
Steam: most recent reviews, filtered by language (english, turkish, all...).
Results are cached for 15 minutes; concurrency is capped to stay polite.
uv sync --extra dev
uv run pytest # offline tests with mocked APIs
uv run python scripts/smoke_live.py # live check against Apple and Steam
npx @modelcontextprotocol/inspector uv run review-miner-mcp # click-through UI
uv run --with rich python scripts/demo.py finance tr # terminal demo (vhs docs/demo.tape records the GIF)MIT © Ali Altunar
Compare recent reviews of 2-8 competitors side by side: rating, negative share and top complaint terms per app, plus a few negative samples each. Use it to find gaps that every competitor fails at (= product opportunity).
| Name | Required | Description | Default |
|---|---|---|---|
| apps | Yes | IDs as 'appstore:123' or 'steam:456'. Mix allowed. | |
| country | No | 2-letter store country, e.g. 'us', 'tr', 'de'. | us |
| language | No | Steam only. | english |
| response_format | No | 'markdown' (default) or 'json'. | markdown |
| samples_per_app | No | ||
| max_reviews_per_app | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds useful scope context ('recent reviews', 2-8 apps, sampled negatives), but does not disclose how far back 'recent' reaches or any rate/coverage limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads what is compared and what comes back, the second states the payoff. No filler, no repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the description still summarizes them, and it caps the app range. Only the meaning of 'recent' and any result-size caveats are left unstated, which is a minor gap for a read-only analytical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description reinforces the 2-8 app bound implied by minItems/maxItems. It adds no syntax or format guidance for country, language, samples_per_app or max_reviews_per_app beyond what the schema already states, so it sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('compare recent reviews of 2-8 competitors side by side') and enumerates the compared dimensions (rating, negative share, complaint terms, samples). It is distinguishable from siblings like review_fetch and review_top_apps, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage motive ('Use it to find gaps that every competitor fails at = product opportunity'), which implies the comparison context. However, it gives no when-not guidance and does not name alternatives such as review_top_apps or review_search_apps for single-app or discovery needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch recent reviews for one app/game and return stats (rating mix, rating per version, top complaint terms) plus the most helpful review texts. Best for 'why do users hate X?'.
| Name | Required | Description | Default |
|---|---|---|---|
| only | No | Which review texts to return. 'negative' = 1-2★ / thumbs down. | negative |
| store | No | 'appstore' or 'steam'. Ignored if app_id has a 'store:' prefix. | appstore |
| app_id | Yes | Numeric ID from a search/top tool, e.g. '570060911' or 'appstore:570060911'. | |
| country | No | 2-letter store country, e.g. 'us', 'tr', 'de'. | us |
| language | No | Steam only: 'english', 'turkish', 'all', ... | english |
| max_reviews | No | How many recent reviews to analyze. App Store caps near 500. | |
| sample_size | No | How many review texts to include in the output. | |
| response_format | No | 'markdown' (default) or 'json'. | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that output includes aggregate stats plus helpful review texts, but discloses no rate limits, auth needs, or pagination behavior beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences that front-load the verb and resource, then the return content and use case. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still summarizes them helpfully. Combined with full schema coverage and safety annotations, the definition is nearly complete; only explicit sibling routing guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter is self-documented, so the schema carries the load. The description only echoes the return content (stats + review texts) without adding syntax, defaults, or interaction detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Fetch recent reviews'), scopes it to 'one app/game', and enumerates what it returns (rating mix, rating per version, complaint terms, review texts). The 'one app' scope implicitly contrasts with review_compare_apps and review_search_apps, so the agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a named scenario ('why do users hate X?'), which implies when the tool is appropriate. However, it never names the alternatives (search/top/compare) or states when-not to use it, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find an app/game and its ID by name. Returns IDs in 'store:id' form for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | App or game name, e.g. 'Duolingo' or 'Cyberpunk'. | |
| store | No | 'appstore' or 'steam'. | appstore |
| country | No | 2-letter store country, e.g. 'us', 'tr', 'de'. | us |
| response_format | No | 'markdown' (default) or 'json'. | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description only adds the store:id return convention, which is useful chaining context but not rich behavioral detail (no result-count or fallback behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler, and the primary purpose plus the return-format note are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and annotations carry the safety profile. The description supplies the key inter-tool contract (store:id for other tools); only explicit sibling routing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% and the schema itself documents query, store, country and response_format with examples. The description adds no parameter meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find an app/game and its ID by name') and clarifies the return shape ('store:id'). It implies search-vs-listing differentiation from review_top_apps via 'by name', but never names or contrasts the siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Returns IDs in store:id form for the other tools' implies this is a prerequisite lookup step feeding review_fetch/review_compare_apps, but there is no explicit when-to-use clause or exclusion versus review_top_apps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the current top charts (App Store by category, or Steam top sellers / most played / new releases). Use this to pick competitors before fetching their reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| chart | No | App Store: 'free' | 'paid' | 'grossing'. Steam: 'top_sellers' | 'most_played' | 'new_releases'. | free |
| limit | No | ||
| store | No | 'appstore' or 'steam'. | appstore |
| country | No | 2-letter store country, e.g. 'us', 'tr', 'de'. | us |
| category | No | App Store only, e.g. 'health-fitness', 'finance', 'games', 'productivity'. Omit for all. | |
| response_format | No | 'markdown' (default) or 'json'. | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine workflow context by positioning the call as the competitor-discovery step preceding review_fetch, though it says nothing about rate limits or result volume beyond the schema's limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, the capability statement front-loaded and the usage hint second, with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and rich annotations, the description need not explain returns, and the schema documents the six optional params. Nothing an agent needs to invoke the tool correctly is missing, though it could clarify category/country applicability more directly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, well above the threshold where the schema carries the load. The description restates the chart and store options but adds no syntax or defaulting guidance beyond what the schema already documents, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (current top charts) and enumerates the chart variants for both App Store and Steam, so an agent immediately knows what comes back. It is clearly distinct from review_search_apps/review_fetch by being a chart-listing rather than a lookup, but it does not name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directs the agent to use it to pick competitors before fetching reviews, giving a concrete discovery-then-detail workflow. It lacks an explicit 'when not to use / use X instead' clause, so the routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0review_compare_appsreview_fetchreview_search_appsreview_top_appsScored across 4 tools
Each tool targets a distinct step or scope: chart discovery, app lookup, single-app review fetching, and multi-app comparison. There is no meaningful overlap in purpose, and the descriptions clearly distinguish when to use each.
All tools use the review_ prefix and mostly follow an action-oriented pattern. The only minor deviation is review_fetch, which omits an explicit object noun like the others, but the convention remains readable and predictable.
Four tools are well-scoped for a review-mining workflow: discover apps, resolve IDs, fetch reviews, and compare competitors. Each tool earns its place without redundancy.
The core lifecycle is covered: finding apps, retrieving reviews with stats, and comparing multiple apps. Minor gaps exist around filtering by time range or exporting raw reviews, but the surface supports the primary use cases.
Analyze App Store and Google Play reviews: themes that cost stars, regressions, feature requests.
App intelligence across Google Play and the App Store: details, reviews, and search in one API.
Analyze product reviews: pain points, feature requests, sentiment and competitive gaps for sellers.
Analyze customer feedback at scale — reviews, surveys, calls. AI-powered themes and sentiment.
