Ask an assistant how many ratings an app has and you will get a number. Ask again next week and you may get a different one. Neither is a lookup — both are recall, and a rating count is exactly the kind of fact that moves daily and that a model has no way of knowing it is wrong about.
The fix is not a better prompt. It is giving the model a way to fetch instead of remember.
What the protocol actually does
The Model Context Protocol is a way for a model to call tools that somebody else runs. The client — Claude, Cursor, any MCP-capable app — asks the server what tools exist, and then calls them with arguments when a conversation needs one.
Appstro's MCP server exposes nine:
| Tool | Answers |
|---|---|
search_apps | which apps rank for a term, in a chosen storefront |
get_app | one app's live listing — name, rating, version, size, languages |
top_charts | the current free, paid and grossing charts for a genre |
app_reviews | recent review text for an app, per storefront |
app_estimates | third-party download and revenue estimates |
app_ads | Google Ads Transparency creatives for an advertiser |
search_publishers | developers matching a name |
publisher_apps | a developer's full portfolio |
appstro | the site's own tool index |
The difference in practice is not subtle. "How many ratings does this app have in Germany?" stops being a recalled number and becomes a request that either returns Apple's current figure or fails visibly.
Stateless on purpose
The server is plain JSON-RPC over HTTP POST, with no authentication and no sessions. Every request is self-contained.
That is a deliberate limit rather than an unfinished feature. A tools-only server that reads public App Store data has nothing to authenticate — there is no per-user state, no billing, and nothing private behind it. Adding sessions would add a failure mode and a deployment constraint in exchange for nothing.
The response cache is equally modest and equally honest about itself: in-memory, best-effort, five minutes for most calls and thirty for the chart feeds, which change slowly. Serverless instances are ephemeral, so a cold start wipes it. It softens upstream load on a warm instance handling a burst. It is not a durable cache and the code says so rather than implying a guarantee it cannot make.
What this does not fix
An MCP server changes what a model can look up about an app. It does not change what a model believes about your category, and those are different problems.
If someone asks an assistant "what is a good habit tracker", nothing in a tools list decides the answer. That comes from whatever the model absorbed in training, plus whatever it retrieves at the time — and neither is a surface you can edit or audit.
Appstro's AI visibility check is the honest, limited response to that: it asks discovery-shaped questions of a model and reports whether your app comes back. Three things about it are worth saying out loud, because most tools in this space say none of them:
- It is a sample of one conversation. Ask twice, get two answers.
- It is not a rank. There is no position, no share, no trend, because none of those exist for a generated answer.
- It is not stable. Treat a single run as an anecdote, and repeated runs as weak evidence.
What you can do about the underlying problem is unglamorous and mostly editorial: be readable without JavaScript, state facts early with their sources attached, and say what you do not know. That is the subject of a separate post, and it applies whether or not you ever run an MCP server.
When a tool call is the wrong shape
Worth being clear, since "connect an API" gets pitched as a universal answer.
A tool call is good for a fact that is current, specific and checkable — this app's rating in this storefront today. It is poor for a judgement — whether this app is good, whether this category is worth entering, what price to charge. Handing a model more numbers does not make a judgement more reliable; it makes a wrong judgement better decorated.
The same boundary runs through every tool on this site. Apple's public data supports a lot of arithmetic and almost no verdicts.
What this cannot tell you
- Not what an assistant will say about your app. Retrieval changes what it can look up, not what it concluded during training.
- Not whether you were cited. Assistants mostly send no referrer, so a citation does not appear in your analytics.
- Not private data. Everything here is public App Store data plus third-party estimates. Your downloads, your revenue and your conversion rate are in App Store Connect and reachable by nobody else.
- Not accuracy of the estimates. Download and revenue figures are third-party models, coarsely rounded — a live top-100 chart returned only 24 distinct download values across 100 apps — and fetching one live does not make it a measurement.
The work
Point your MCP client at the server and ask it something checkable — a rating count in a storefront you can verify by opening the App Store. Then run the visibility check a few times and look at the variance rather than the result. Both are more useful as calibration than as answers.