Daily ranks of consumer AI apps across the App Store and Google Play. Read-only, ranks only.
Scored across 3 tools
app_rank is a name-based lookup, top_apps is a ranked list, and movers is a change feed — three clearly different query intents. The only mild overlap is that movers and top_apps both return ranked app rows, but the change-focused framing of movers keeps them separable.
All names are snake_case, so the surface is visually uniform, but the grammatical patterns diverge: app_rank is noun_verb, top_apps is adjective_noun, and movers is a bare noun with no object. Readable and thematically coherent, yet no predictable verb_noun convention.
Three tools is on the lean side but fits a narrow leaderboard domain: one lookup, one list, one change feed. Nothing is redundant, though an agent may wish for one more angle (e.g. category or platform filters).
Coverage of the core leaderboard questions (rank of an app, top N, who moved) is solid across both live and weekly scopes. However, there's no way to enumerate all apps, fetch app details beyond rank/page, or query arbitrary historical windows, which limits deeper analysis.
Find an app by name (fuzzy: "gemini", "claude", "chat gpt" all work) and return its rank on the live board and in the latest frozen week, with its ascension.fyi page.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | App name, or part of it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context beyond that: matching is fuzzy rather than exact, and the result spans two time views (live board and latest frozen week) plus an external page link.
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?
A single sentence that front-loads the action, then the matching behavior, then the returned fields. No redundant restatement of the name or title.
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 one-parameter read tool with full annotations this is nearly complete, and the description compensates for the missing output schema by enumerating the returned fields. The one gap is behavior on a failed or ambiguous fuzzy match (no result, multiple candidates), which an agent would want to know.
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%, so the baseline is 3, but the description genuinely extends the schema's 'App name, or part of it' by demonstrating that loose, multi-word, spaced queries are accepted. That is meaningful semantics an agent would not infer from the schema alone.
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 (find) and resource (app) plus exactly what is returned: rank on the live board, rank in the latest frozen week, and the ascension.fyi page. It is clearly a single-app lookup and thus implicitly distinct from the list-style siblings, but it never names movers or top_apps to make the distinction explicit.
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 fuzzy-match examples ('gemini', 'claude', 'chat gpt') tell the agent how to call it, but there is no guidance on when to prefer this over top_apps or movers, nor on prerequisites or failure behavior when the name matches nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apps that climbed, dropped, joined, or left the board. week is "latest" (the newest frozen week vs the week before), a Monday date like "2026-10-19", or "live" (today vs the previous day).
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Max apps per list, 1 to 25 | |
| week | No | "latest", "live", or a Monday date YYYY-MM-DD | latest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent operation. The description adds meaningful behavioral context beyond annotations by defining what movements are included and clarifying the comparison windows for 'latest' and 'live', though it does not describe the return shape or ordering.
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, front-loaded with the core concept and followed by the key parameter semantics. Every sentence earns its place with no filler.
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 read-only tool with full schema coverage and annotations covering safety, the description is nearly complete. The main minor gap is not clarifying that results are returned as multiple lists or how the n limit applies across those lists, though the schema's 'per list' wording hints at it.
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%, so the baseline is 3. The description still adds value by explaining that 'latest' means newest frozen week vs the prior week and 'live' means today vs the previous day, which is semantic meaning beyond the schema's regex and short description.
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 a specific resource and scope: apps that climbed, dropped, joined, or left the board, which is a clear movers/delta concept. It does not explicitly name siblings like top_apps or app_rank, but the movement framing distinguishes it well enough in practice.
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: call this when you need weekly gainers, losers, entries, and exits. It explains the week modes but gives no explicit when-to-use versus top_apps or app_rank, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The top n consumer AI apps on Ascension. scope "live" is today's blended board (updates daily around 6 AM ET); "week" is the latest frozen week (freezes Thursdays). Returns rank, app, platform, change, date, and each app's ascension.fyi page.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | How many apps, 1 to 100 | |
| scope | No | "live" for today's board, "week" for the latest frozen week | live |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, idempotent read operation. The description adds useful behavioral context beyond annotations: the live board updates around 6 AM ET daily, the week scope freezes Thursdays, and the exact returned fields are listed.
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 are front-loaded with the core purpose, followed by scope timing and return fields. There is no wasted text, and the key information appears early.
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?
The description covers purpose, scope behavior, update cadence, and return fields, which is sufficient for a simple read-only ranking tool without an output schema. Its main omission is explicit sibling differentiation, which would help distinguish it from app_rank and movers.
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%, so the parameters are already documented. The description still adds meaning, especially by clarifying that live is today's blended board with a daily update cadence and week is the latest frozen week with Thursday freezes.
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 a specific ranked resource: the top n consumer AI apps on Ascension. It is easy to tell what the tool returns, but it does not explicitly distinguish itself from siblings such as app_rank or movers.
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 scope options are explained with concrete timing details, which helps an agent choose between live and week. However, there is no explicit guidance on when to use this tool instead of app_rank or movers.
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.
app_rankmoverstop_appsApp Store keyword rankings, competitors, markets, reviews and analytics for iOS apps, from your AI.
App Store Optimization data for AI agents: keyword ranks, scores, competitors, charts
App Store & Google Play keyword ranks, rivals, reviews and AI visibility. Free plan included.
Access to your Apple App Store and Google Play Store rankings, competitors and chart moves.
Add one secure layer between your agents and this server.
