App Store Opportunity Tracker

Estimate a publisher's apps and totals

app_tracker_publisher

Read-onlyIdempotent

Use this when the user asks how many downloads a developer's apps get together, such as "how many downloads do PlaySimple's apps get?". Pass app (any App Store app of the developer) or developer (the App Store developer id). Returns every app of that developer, up to 60 by rating count, each with the same download range as app_tracker_estimate, plus totals that add the ranges. Revenue is off, as in app_tracker_estimate.

Input Schema

Name	Required	Description
`app`	No	Any App Store app of the publisher, as an id or link. Pass this or developer.
`country`	No	Two-letter store country used to list the apps, such as us. The estimates are always worldwide. Default us.
`developer`	No	App Store developer id, the number in an apps.apple.com/developer/.../id<number> link. Pass this or app.

Output Schema

Name	Required	Description
`apps`	Yes
`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.
`count`	Yes
`method`	Yes
`source`	Yes	Who the data comes from, to cite and to check it against.
`totals`	Yes
`readings`	Yes
`warnings`	Yes
`developer`	Yes
`fetchedAt`	Yes
`untrusted_source`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 23, 2026

changedOutput schema / properties / totals / properties / downloads30d / type
```
Previous value: -"object"New value: +[
+  "object",
+  "null"
+]
```
changedOutput schema / properties / totals / properties / revenue30d / type
```
Previous value: -"object"New value: +[
+  "object",
+  "null"
+]
```

addedOutput schema / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "developer",
-  "count",
-  "apps",
-  "totals",
-  "readings",
-  "method",
-  "fetchedAt",
-  "untrusted_source",
-  "note",
-  "as_of",
-  "source"
-]New value: +[
+  "developer",
+  "count",
+  "apps",
+  "totals",
+  "readings",
+  "method",
+  "warnings",
+  "fetchedAt",
+  "untrusted_source",
+  "note",
+  "as_of",
+  "source"
+]

Changed1 schema field changedOct 22, 2026
- addedInput schema / examples
```
Added value: +[
+  {
+    "app": "1197354394"
+  }
+]
```
First observedOct 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, open-world, and non-destructive semantics, and the description adds substantial context beyond them: a 60-app cap ranked by rating count, the fact that totals are sums of ranges rather than point values, and the caveat that revenue is off. These are exactly the behavioral details an agent needs to interpret and present results honestly.

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 tight sentences: trigger first, parameter guidance second, return shape and caveats last. The example query is front-loaded where it aids selection, and no sentence is filler.

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 read-only estimation tool with an output schema and full annotation coverage, the description supplies everything an agent needs: when to call it, how to parameterize it, what it returns, the result cap, and the revenue limitation. Nothing material is missing.

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 app, developer, and country are all documented in the schema itself, including the worldwide-estimates caveat for country. The description only restates the app/developer either-or rule already expressed by the schema's anyOf, adding little new parameter meaning. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb and resource: estimating aggregate downloads for all of a developer's apps, with a concrete user-phrased example. It is clearly distinguished from the sibling app_tracker_estimate, which handles a single app, since the description explicitly says results carry the 'same download range as app_tracker_estimate' plus totals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening sentence gives an explicit trigger condition ('when the user asks how many downloads a developer's apps get together') with a verbatim example query. It also implies the alternative for single-app questions by referencing app_tracker_estimate, so an agent knows which sibling to pick.

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.