App Store Opportunity Tracker

Score a chart for Stale Winners

app_tracker_opportunities

Read-onlyIdempotent

Use this when the user wants app ideas or weak incumbents on a top chart, such as "which popular apps on the top free chart are badly rated or abandoned?". Pass the chart inputs and min_score. Scans all 100 chart apps and returns each with a Stale Winner score (0 to 100, 75 or more is high), its reasons, flags (low_rating, stale) and a download and revenue estimate range. Scores rank opportunities; they do not prove a market.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "limit": 2,
      "country": "us",
      "min_score": 0
    },
    "name": "app_tracker_opportunities"
  }
}

Input Schema

Name	Required	Description
`chart`	No	Which top chart: free (default) or paid. grossing answers source_off: no allowed source publishes it.
`genre`	No	Omit for the overall chart. A genre answers source_off: no allowed source publishes genre charts.
`limit`	No	How many rows to return, 1 to 100. Default 25. The whole chart is always scanned.
`store`	No	apple (App Store, default). play answers source_off: Google Play charts load only through a path its robots.txt disallows.
`country`	No	Two-letter store country, such as us, gb or jp. Default us.
`min_score`	No	Only apps scoring at least this much. 75 or more is a high opportunity. Default 0.

Output Schema

Name	Required	Description
`note`	Yes
`as_of`	Yes	ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.
`chart`	Yes
`genre`	No
`stale`	No	Present only when Apple's feed failed and the newest stored copy of the chart, up to 3 days old, was served instead. fetchedAt is that copy's time.
`store`	Yes
`source`	Yes	Who the data comes from, to cite and to check it against.
`country`	Yes
`scanned`	Yes
`fetchedAt`	No
`highCount`	Yes
`opportunities`	Yes
`untrusted_source`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedOutput schema / properties / stale

Added value: +{
+  "description": "Present only when Apple's feed failed and the newest stored copy of the chart, up to 3 days old, was served instead. fetchedAt is that copy's time.",
+  "properties": {
+    "reason": {
+      "type": "string"
+    },
+    "takenAt": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed4 schema fields changedOct 23, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "country": "us",
-    "genre": "6007",
-    "limit": 2,
-    "min_score": 0
-  }
-]New value: +[
+  {
+    "country": "us",
+    "limit": 2,
+    "min_score": 0
+  }
+]

changedInput schema / properties / chart / description

Previous value: -"Which top chart. Default free."New value: +"Which top chart: free (default) or paid. grossing answers source_off: no allowed source publishes it."

changedInput schema / properties / genre / description

Previous value: -"Apple genre id such as 6007 (Productivity) or 6013 (Health & Fitness), a Google Play category such as PRODUCTIVITY, or a genre name. Omit for all apps."New value: +"Omit for the overall chart. A genre answers source_off: no allowed source publishes genre charts."

changedInput schema / properties / store / description

Previous value: -"apple (App Store, default) or play (Google Play)."New value: +"apple (App Store, default). play answers source_off: Google Play charts load only through a path its robots.txt disallows."

First observedOct 21, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely useful behavior: the whole 100-app chart is always scanned regardless of the returned row count, the score range and high-opportunity threshold, and the caveat that scores rank opportunities rather than proving a market. It does not address rate limits or auth, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each doing distinct work: trigger, mechanics, and result shape plus caveat. The trigger is front-loaded and nothing is padding.

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?

For a six-parameter, fully defaulted read tool with an output schema, the description covers when to call it, what it scans, what comes back at a high level, and the interpretation caveat. An agent has everything needed to invoke it correctly without duplicating the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the enum values, defaults and 0-100 min_score band are already documented in the schema. The description only echoes 'pass the chart inputs and min_score' and repeats the 75 threshold, adding no syntax or format detail beyond structured fields. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: it scores every app on a top chart for 'Stale Winner' opportunity and returns score, reasons, flags and estimates. That is much more concrete than the title alone. It never names the adjacent siblings (app_tracker_abandoned, app_tracker_charts), so an agent must infer which neighbor to prefer.

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?

It states the trigger clearly — 'when the user wants app ideas or weak incumbents on a top chart' — and supplies a sample user question that maps directly onto this tool. There are no explicit when-not conditions or named alternatives (e.g., versus app_tracker_abandoned), so routing above the immediate case is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All App Store Opportunity Tracker tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.