App Store Opportunity Tracker

App Store search results (off)

app_tracker_keywords

Read-onlyIdempotent

Off: always answers source_off. App Store search results and suggestions sit under robots.txt Disallow lines on apps.apple.com, search.itunes.apple.com and itunes.apple.com, so they are not read. Say that search results are not available from an allowed source, and offer app_tracker_charts instead.

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": {
      "term": "habit tracker"
    },
    "name": "app_tracker_keywords"
  }
}

Input Schema

Name	Required	Description	Default
`term`	Yes	The words a person types in the App Store search box.
`country`	No	Two-letter store country, such as us, gb or jp. Default us.

Output Schema

Name	Required	Description
`note`	Yes
`serp`	Yes
`term`	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.
`hints`	Yes
`source`	Yes	Who the data comes from, to cite and to check it against.
`country`	Yes
`fetchedAt`	No
`difficulty`	Yes
`exactMatches`	No
`medianRatings`	No
`weakIncumbents`	No
`untrusted_source`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026
- changedInput schema / properties / term / maxLength
```
Previous value: -100New value: +300
```
First observedOct 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only say readOnly/openWorld/idempotent, which would mislead an agent into expecting real results. The description discloses the actual behavior (fixed source_off response) and the reason (robots.txt Disallow on apps.apple.com, search.itunes.apple.com, itunes.apple.com) — exactly the kind of context annotations cannot convey.

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 short clauses, front-loaded with the decisive fact ('Off: always answers source_off'), then the justification, then the corrective instruction. No sentence 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?

The tool is trivial and an output schema exists, so nothing about return values is needed. The description supplies the rationale, the scripted response, and the escalation path to app_tracker_charts — everything an agent needs to handle this call correctly.

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

Parameters4/5

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

Schema coverage is 100%, so term and country are already documented; the baseline is 3. The description adds useful semantics by saying the tool 'always answers source_off', which implies the parameters have no effect on the outcome and prevents an agent from retrying with other terms or countries.

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 states a concrete, unusual behavior: 'Off: always answers source_off.' An agent immediately knows this is a disabled stub, not a real search tool, and is told the resource scope (App Store search results/suggestions on the three Apple hosts). It also names the sibling app_tracker_charts, so it is distinguishable from alternatives without opening any schema.

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?

It gives explicit instructions for both branches: say search results are not available from an allowed source, and offer app_tracker_charts instead. That is a when-to-use plus a concrete redirect to the correct sibling, leaving nothing 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.