Provides App Store ranking data, including keyword ranks, rivals ranking above your app, rank history, and AI visibility measurements.
Provides Google Play ranking data, including keyword ranks, rivals ranking above your app, rank history, and AI visibility measurements.
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., "@storelift-mcp Who outranks my app 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.
App Store & Google Play ranking data as an MCP server. Ask your assistant which keywords you dropped on, who outranks you, and whether AI assistants mention your app at all — without opening a dashboard.
Backed by Storelift, which measures keyword ranks, rivals and AI visibility nightly. No store credentials required — ranks are read from the public storefront.
A Pro or Studio plan (the Public API is enabled on both)
An API key: Storelift → Settings → API keys → Generate key
Related MCP server: Store Scraper MCP
Claude Code:
claude mcp add storelift -e STORELIFT_API_KEY=sl_live_... -- npx -y storelift-mcpClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"storelift": {
"command": "npx",
"args": ["-y", "storelift-mcp"],
"env": { "STORELIFT_API_KEY": "sl_live_..." }
}
}
}Hosted, with nothing to install — https://storelift.net/mcp over Streamable
HTTP. Clients that support MCP authorization (Claude.ai custom connectors,
Claude Code's /mcp) sign you in to Storelift with OAuth and ask you to approve
access; no key to paste:
claude mcp add --transport http storelift https://storelift.net/mcpClients without OAuth can send the API key as a header instead:
claude mcp add --transport http storelift https://storelift.net/mcp --header "Authorization: Bearer sl_live_..."Tool | Returns |
| tracked apps (id, name, countries, keywords) |
| keyword ranks for one app in one country |
| apps ranking above you, with their rank and yours |
| whether assistants name your app, per engine (Claude / ChatGPT / Gemini) |
| rank history, |
| your own listing signals + the Google Play page, with a dated change timeline |
| recent App Store and Google Play reviews, and how many are new since last measurement |
| App Store chart position per list, with history |
Five ready-made questions, served through prompts/list:
keywords_lost_ground — which US keywords lost ground this week, and who is above you now
leader_listing — title, subtitle and keyword field of the app ranking first on your main keyword
crash_reviews — recent reviews that mention a crash or a bug
category_chart — where your app sits in its category chart in Turkey
ai_visibility — whether assistants name your app for its category (data on the Studio plan)
Keyword results carry three distinct states, and they are not the same thing:
measured: false — the query could not be measured
rank: null (with measured: true) — measured, but absent from the top results
rank: <number> — the rank
Counting an unmeasured day as zero produces a false chart. The tool descriptions repeat this so the model does not flatten the three into one.
A rank move usually has its explanation somewhere other than the rank: a version
that shipped that day, a wave of one-star reviews, a chart drop. get_store_page,
get_reviews and get_charts exist so the model can look there instead of
explaining everything with the one number it can see.
Google Play is absent from get_charts on purpose: Google publishes no chart
list, so there is nothing to read and a number here would be invented.
AI visibility is an observation, not a ranking: a model's knowledge is frozen at a date and the answer is not identical every time. Read the trend, not a single measurement.
Variable | Default | Purpose |
| — | required for tool calls; without it the server still starts and lists its tools, and every call returns an error saying how to get a key |
|
| override the API base |
No dependencies — a single file speaking JSON-RPC over stdio. Runs with
node index.mjs just as well as through npx.
Published to the official MCP Registry as net.storelift/storelift.
The manifest is server.json in this repo.
github.com/vom-core/storelift-mcp — one file, no dependencies. Read it before you run it.
MIT
Whether AI assistants name this app when asked natural questions about its category — reported per engine (Claude / ChatGPT / Gemini), never averaged. This is an OBSERVATION, not a ranking: a model's knowledge is frozen at a date and the answer is not identical every time, so read the trend rather than a single measurement.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | app id from list_apps | |
| country | No | country code, e.g. tr, us |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by explaining that results are per-engine, never averaged, and that the answer is not deterministic ('a model's knowledge is frozen at a date and the answer is not identical every time'). This is valuable behavioral context beyond what the schema shows. It could go further by describing the output format, but the key behavioral traits are disclosed.
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?
The description is two sentences with zero waste. The core purpose is front-loaded, and the important caveat about observation vs. ranking is included without bloat. Every sentence 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?
For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is quite complete. It explains the purpose, the per-engine reporting, and the non-deterministic nature. The only gap is that it doesn't describe the return format, but since there's no output schema, a brief note on what the response looks like would be helpful. Still, the description covers the essential context an agent needs to call it correctly.
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%, so the schema already documents both parameters (appId and country). The description doesn't add much parameter-level detail beyond what the schema provides, but it does imply that appId is the primary input. Baseline 3 is appropriate since the schema does the heavy lifting.
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?
The description clearly states the tool's purpose: it reports whether AI assistants name this app when asked natural questions about its category, per engine. It distinguishes itself from a ranking by explicitly saying 'This is an OBSERVATION, not a ranking.' This is a specific verb+resource with clear scope, and it differentiates from sibling tools like get_charts or get_reviews.
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?
The description provides clear context on when to use this tool: when you want to know AI assistants' visibility for an app, reported per engine. It also gives guidance on how to interpret results ('read the trend rather than a single measurement'). However, it doesn't explicitly name alternative tools or state when NOT to use it, so it doesn't fully reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
App Store chart position for one country: current ranks per list (free / paid / grossing, overall and in category) plus their history. Google Play is absent on purpose — Google publishes no chart list, so there is nothing to read, and a number here would be invented.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | app id from list_apps | |
| country | No | country code, e.g. tr, us |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that Google Play is deliberately excluded and that historical data is included, adding meaningful behavioral context beyond the schema. It does not mention read-only status or error handling, but for a simple read tool this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by a relevant exclusion explanation. No filler or repetition; every sentence 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?
For a 2-parameter read tool with no output schema, it covers the main points: what it returns, scope, and why Google Play is excluded. Minor gap: the schema marks country as optional but the description implies it is needed, which could cause slight confusion.
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 100% for both parameters, each with descriptive text. The description adds no new parameter-level meaning beyond reinforcing that it is per-country, which is already in the schema. 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 (get) and resource (App Store chart position) with clear scope: one country, list types (free/paid/grossing), and category. It explicitly distinguishes from Google Play, which sets it apart from any potential sibling tool. The purpose is unambiguous and actionable.
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 clear context (App Store, one country) and an explicit exclusion (Google Play) explaining why it is absent. However, it does not name alternative tools or state when to prefer siblings like get_history, so the routing guidance is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword rank history for one country. Series points are [day, rank]; a null rank means the app was absent from the top results that day, which is not the same as a bad rank.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | app id from list_apps | |
| country | No | country code, e.g. tr, us |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It meaningfully explains the return format as '[day, rank]' and clarifies the semantic difference between a null rank (absence from top results) and a bad rank, which is valuable non-obvious behavior. However, it does not mention rate limits, authentication, or the safe read-only nature of the operation.
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?
The description is two sentences with no filler. The core purpose is front-loaded, and the second sentence adds a precise, necessary interpretation of null values without extra verbosity.
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?
For a simple two-parameter tool with no output schema, the description covers the essential semantics: what the data represents secret, how the series is structured, and how nulls should be interpreted. Minor gaps such as date range, ordering, or default country behavior exist, but the tool is small enough that the description is largely sufficient for correct invocation.
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%, so both parameters are already documented in the schema. The description adds slight extra meaning by reinforcing the country scope ('for one country'), which helps clarify the optional-looking country parameter arena, but it adds no new detail about appId or formatting. This meets the baseline for schema-covered parameters without exceeding it.
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?
The phrase 'Keyword rank history for one country' clearly identifies the resource and scope, and it differentiates the tool from siblings like get_keywords, which likely lists keywords rather than time series. The description lacks an explicit verb like 'get', but the resource and purpose are unambiguous enough.
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?
The description implies that results are scoped to one country, which hints at the country parameter, but it provides no explicit guidance on when to prefer this tool over sibling tools such as get_keywords or get_charts. No alternatives or exclusions are mentioned, leaving the agent to infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword ranks for one app in one App Store / Google Play country. THREE STATES ARE DISTINCT: measured=false means the query could not be measured, rank=null means it was measured but the app is absent from the top results, rank= is the rank. Never collapse them into one — counting an unmeasured day as zero produces a false answer.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | app id from list_apps | |
| country | No | country code, e.g. tr, us (defaults to the app's first country) | |
| platform | No | defaults to ios |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does an unusually strong job: it explains three distinct output states and warns against collapsing them, which is critical behavioral context for producing correct results. It does not cover every possible behavior like authentication or output shape, but the core interpretational trap is thoroughly disclosed.
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?
The description is compact and front-loaded: the main purpose appears in the first sentence, and the second sentence explains the most important caveat. Every sentence earns its place, and there is no filler or repetition of schema details.
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?
For a three-parameter tool with no output schema, the description covers the central non-obvious behavior that an agent must know: the difference between measured=false, rank=null, and rank=number. It is slightly light on the exact structure of the returned data, but the essential context needed to call and interpret the tool is present.
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%, so the schema already documents appId, country, and platform, including defaults. The description reinforces that the tool is scoped to one app and one country but does not add substantive parameter-level meaning 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?
The description clearly identifies the resource as keyword ranks and states the precise scope: one app, one country, one platform. It distinguishes this from sibling tools like get_charts and get_reviews by using the specific term 'keyword ranks' and naming App Store / Google Play country scoping.
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?
The description clearly implies this is the tool to use for keyword rank data, but it never explicitly explains when to prefer it over siblings or when not to use it. No alternative tools are named, so the usage guidance is mostly inferred from the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent reviews for one country: list is the App Store feed, android the Google Play page (a narrower window, and Play publishes no review title or version). newCount is how many arrived since the previous measurement — null means an older record where the field was never written, which is not zero. android=null means Play was never measured; an empty list means there genuinely are no reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | app id from list_apps | |
| country | No | country code, e.g. tr, us |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full behavioral disclosure and does so well. It explains the App Store vs Google Play differences, the meaning of newCount, and the crucial distinction between null and empty lists. This goes well beyond minimal expectations.
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?
The description is compact and front-loaded with the purpose, then details field semantics in a dense but organized way. Every sentence adds meaningful information, though the density around null handling could be slightly clearer with more structure.
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?
There is no output schema, so the description carries the full burden of explaining response semantics. It covers platform-specific differences, null vs zero, and empty-list meaning, which are exactly the ambiguous cases an agent would face. The information is sufficient to call and interpret the tool correctly.
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%, so the schema already documents appId and country fully. The description adds context by emphasizing 'one country' and clarifying review feed behavior, but it does not add significant parameter-level meaning 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?
The description states the tool returns recent reviews for one country, with appId and country as the relevant inputs. It identifies the resource clearly, though it does not explicitly mention the app dimension beyond the schema and does not distinguish itself from sibling tools.
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?
The description implies this tool is for retrieving recent reviews for a specific app/country, but it gives no explicit when-to-use guidance or exclusions compared with siblings like get_charts or get_store_page. The use case is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apps that rank ABOVE this app in search. For each rival you get the keywords it beats you on, its rank there (theirRank) and yours (ourRank) — ourRank null means the app does not appear for that keyword at all.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | app id from list_apps | |
| country | No | country code, e.g. tr, us | |
| platform | No | defaults to ios |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output structure (keywords, theirRank, ourRank) and the meaning of a null ourRank, which is valuable behavioral context beyond a simple 'gets rivals'. It does not mention pagination or errors, but the core behavior is transparent.
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?
The description is a single, concise sentence that front-loads the core purpose and then explains the returned data efficiently. Every clause adds value, with no filler or redundancy.
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?
For a tool with no output schema and no annotations, the description covers the essential return data and null semantics, which is sufficient for an agent to understand what to expect. It does not explicitly cover edge cases like empty results or default country behavior, but those are minor and likely inferable.
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%, so the schema already documents appId, country, and platform. The description adds minimal parameter context – it references 'this app' but does not elaborate on the parameters or their defaults beyond what the schema provides. Baseline 3 is appropriate.
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?
The description clearly states the tool's purpose: it returns apps ranking above the specified app in search, and details the data for each rival (keywords, their rank, our rank, and null semantics). This is a specific verb-resource pair that distinguishes it from siblings like get_keywords or get_charts, which focus on different aspects.
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?
Usage is implied by the description – it is for seeing competitors ranking above the app – but there is no explicit guidance on when to use it versus alternatives or when not to use it. No sibling alternatives are mentioned, leaving the agent to infer its place among the listed tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The app's own store listing signals for one country: name, subtitle, version, in-app events, editorial placements, similar-apps shelves and the screenshot set (iOS), plus the Google Play page (exact install count, rating histogram, ad/IAP flags, chart badge). timeline lists the dated changes we detected on the listing — the cheapest explanation for a rank move. measured=false means the page was never read; it is not the same as an empty page.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | app id from list_apps | |
| country | No | country code, e.g. tr, us |
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 clarifies a key nuance: `measured=false` means the page was never read, not that it is empty, which prevents misinterpretation. It also implicitly indicates read-only behavior by describing the data retrieved. However, it does not disclose error handling, rate limits, or authorization requirements, which are common behavioral aspects. The `measured` clarification is a significant positive.
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?
The description is well-structured, starting with the main content list, then the timeline explanation, and finally the `measured` flag clarification. Each sentence adds value and is not redundant. It is concise enough for the amount of information conveyed, and the most critical usage hint (timeline for rank moves) is placed in the second sentence, which is acceptable.
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?
Given no output schema and no annotations, the description is fairly complete. It enumerates the expected data fields, explains the `timeline` and `measured` semantics, and implies both iOS and Google Play data. It does not specify default behavior for the optional `country` parameter or error cases, but these are minor gaps. An agent has enough context to call the tool correctly.
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?
The input schema already describes both parameters with 100% coverage (appId from list_apps, country code example). The description adds the context that the tool retrieves signals 'for one country', reinforcing the purpose of the country parameter, but provides no additional semantic detail beyond the schema. Since the schema covers the parameters well, a baseline of 3 is appropriate.
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?
The description clearly states the tool retrieves the app's own store listing signals for a country, enumerating specific data points (name, subtitle, version, in-app events, editorial placements, similar-apps shelves, screenshot set, Google Play page details). This distinguishes it from siblings like get_charts, get_reviews, and get_history, which focus on different data domains. The verb 'get' and resource 'store page' are specific and unambiguous.
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?
The description offers a contextual hint by noting that `timeline` lists dated changes as 'the cheapest explanation for a rank move', implying the tool is useful for investigating rank changes. However, it does not explicitly state when to use this tool over alternatives like get_history or get_charts, nor does it mention exclusions or when not to use it. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the apps tracked in this Storelift account (id, name, countries, keywords). Call this first — every other tool needs an appId from here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It implicitly indicates a read-only listing behavior and adds the useful dependency context that returned appIds are prerequisites for other tools. While it does not mention pagination or rate limits, these are not critical for a simple list operation, and the description adequately conveys what the tool returns and its role.
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 sentences, no wasted words. The first sentence states the core functionality and the fields returned, front-loading the most critical information. The second sentence adds a precise usage directive. Every phrase 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?
For a zero-parameter listing tool with no output schema, the description fully equips an agent: it names the resource, enumerates the returned fields, and explains why and when to call it. There is nothing additional an agent needs to invoke it correctly.
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?
The tool has zero parameters and the schema is empty, so there is nothing for the description to add. Per the baseline rule for 0-param tools, a score of 4 is appropriate since the description contributes no redundant information and does not need to compensate for schema gaps.
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'), a clear resource ('apps tracked in this Storelift account'), and enumerates the fields returned (id, name, countries, keywords). This distinguishes it from the sibling get_* tools, which all retrieve specific attribute data for a single app rather than listing all apps.
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?
Explicitly states the intended invocation order ('Call this first') and the reason ('every other tool needs an appId from here'). This leaves no ambiguity about when to use this tool versus the siblings and establishes a dependency relationship.
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.
v1.1.1get_ai_visibilityget_chartsget_historyget_keywordsget_reviewsget_rivalsget_store_pagelist_appsScored across 8 tools
Each tool targets a distinct data resource: apps, AI visibility, keyword ranks, rivals, rank history, store listing, reviews, and charts. Even the two ranking-related tools are clearly separated as current vs historical, and get_rivals vs get_charts have unique purposes.
Seven tools use get_<resource> and one uses list_apps, a natural exception for enumerating all apps. All names are snake_case verb_noun pairs that are consistent and predictable.
8 tools is well-scoped for an app store analytics server; each tool covers a distinct measurable signal and none feels redundant. The set is neither too thin nor overloaded.
The surface covers the core Storelift workflow: enumerate apps, then inspect keyword ranks, history, rivals, store page, reviews, charts, and AI visibility. As a read-only analytics server, the lack of create/update/delete operations is not a gap.
ASO tools for AI agents: keyword research, rank tracking, competitor analysis (iOS & Android).
Access to your Apple App Store and Google Play Store rankings, competitors and chart moves.
Track app-store rankings, history, listing metadata, reviews and competitors across four stores.
Live App Store & Google Play data for AI agents: app discovery, ASO keywords, reviews.
