AppSkyline App Rankings

Get downloads and installs

get_app_engagement_summary

Read-onlyIdempotent

Use this when someone asks how many downloads, installs, uninstalls or crashes their app had over a period. Returns store-reported totals, the latest 30 daily rows and top countries for one app and store; metric names differ by store. Not for keyword rankings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "appId": "<appId>",
      "store": "<store>"
    },
    "name": "get_app_engagement_summary"
  }
}

Input Schema

Name	Required	Description
`days`	No	Rolling window of the last 1 to 365 days, used when no dates are given; omit dates and days for every synced day
`appId`	Yes	AppSkyline app id (uuid)
`store`	Yes	Store to summarize: ios-app-store, macos-app-store, google-play or microsoft-store
`endDate`	No	Last day of the window as YYYY-MM-DD; applies only together with startDate
`startDate`	No	First day of the window as YYYY-MM-DD; applies only together with endDate

Output Schema

Name	Required	Description
`appId`	Yes
`store`	Yes
`status`	Yes
`totals`	Yes	Store-reported totals for the window; metric names differ by store
`dailySeries`	Yes	The most recent 30 days of one daily metric series
`dataThrough`	Yes
`lastSyncedAt`	Yes
`topTerritories`	Yes	Up to 8 leading countries or territories by downloads or installs
`totalsTruncated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 28, 2026

changedInput schema / properties / appId / description

Previous value: -"Appskyline app id"New value: +"AppSkyline app id (uuid)"

changedInput schema / properties / days / description

Previous value: -"Rolling window size in days when no explicit dates are given"New value: +"Rolling window of the last 1 to 365 days, used when no dates are given; omit dates and days for every synced day"

changedInput schema / properties / endDate / description

Previous value: -"End of the window as YYYY-MM-DD"New value: +"Last day of the window as YYYY-MM-DD; applies only together with startDate"

changedInput schema / properties / startDate / description

Previous value: -"Start of the window as YYYY-MM-DD"New value: +"First day of the window as YYYY-MM-DD; applies only together with endDate"

changedInput schema / properties / store / description

Previous value: -"Which store to summarize"New value: +"Store to summarize: ios-app-store, macos-app-store, google-play or microsoft-store"

addedOutput schema / properties / dailySeries / description

Added value: +"The most recent 30 days of one daily metric series"

addedOutput schema / properties / topTerritories / description

Added value: +"Up to 8 leading countries or territories by downloads or installs"

addedOutput schema / properties / totals / description

Added value: +"Store-reported totals for the window; metric names differ by store"

First observedAug 25, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's value is in the result shape it discloses: store-reported totals, the latest 30 daily rows, top countries, and the caveat that metric names differ by store. That last point is a genuine gotcha an agent could not infer from annotations, though the return contract is partly redundant with the output schema.

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, front-loaded with the invocation trigger, then the return shape, then the exclusion. No filler and every clause carries information.

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?

With a full schema, an output schema, and annotations present, the description needs only to add trigger, scope, and caveats — which it does. An agent has enough to pick this tool and call it correctly.

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 description coverage is 100%, including the days/startDate/endDate interaction and the store enum, so the schema carries the parameter burden. The description only restates scoping at a high level ('for one app and store', 'over a period') without adding format or precedence detail beyond what the schema already documents.

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?

The description opens with a concrete trigger and names the exact resources it reports on (downloads, installs, uninstalls, crashes) over a period, which is more specific than the title's 'downloads and installs'. It also explicitly carves itself away from sibling territory with 'Not for keyword rankings.'

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 a clear when-to-use condition ('when someone asks how many downloads, installs, uninstalls or crashes their app had over a period') and one negative exclusion. It stops short of naming the positive alternative for a broader app picture (e.g. show_app_overview or get_app), so the routing is implied rather than complete.

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

All AppSkyline App Rankings 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.

Resources

Need Help?