AppmanAi

Keywords shared by several apps

keyword_app_overlap

Read-only

Given a set of apps, list the keywords they compete on, each with its popularity (SAP) and every app's rank for it. Use it to compare a whole competitor set head-to-head on one keyword list; keyword_app_competitors starts from a single app instead. Costs 7 credits.

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": {
      "store": "<store>",
      "country": "<country>",
      "packages": "<packages>"
    },
    "name": "keyword_app_overlap"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many rows to return, up to 200.
`store`	Yes	Which app store: "android" (Google Play) or "ios" (App Store).
`country`	Yes	Two-letter ISO country code, e.g. "US", "GB", "DE".
`min_sap`	No	Only keywords with at least this search-ads popularity (5-100).
`min_apps`	No	Only keywords at least this many of the apps rank for (2 or more).
`min_rank`	No	Only keywords an app ranks at least this high for.
`packages`	Yes	App package / bundle ids, up to 20, e.g. ["com.discord", "com.spotify.music"].

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 9, 2026

changedInput schema / properties / min_apps / description

Previous value: -"Only keywords at least this many of the apps rank for."New value: +"Only keywords at least this many of the apps rank for (2 or more)."

removedInput schema / properties / min_apps / exclusiveMinimum
```
Removed value: -0
```
addedInput schema / properties / min_apps / minimum
```
Added value: +2
```

changedInput schema / properties / min_sap / description

Previous value: -"Only keywords with at least this search-ads popularity (0-100)."New value: +"Only keywords with at least this search-ads popularity (5-100)."

changedInput schema / properties / min_sap / maximum

Previous value: -9007199254740991New value: +100

changedInput schema / properties / min_sap / minimum
```
Previous value: --9007199254740991New value: +5
```

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description still adds real value by disclosing the 7-credit cost, which matters for an agent budgeting calls in a large tool family. It also outlines the return content (SAP plus per-app ranks), though it says nothing about pagination or truncation behavior beyond the limit parameter.

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 sentences with zero waste: capability, routing decision, then cost. The most decision-relevant information (what it returns and how it differs from the sibling) is front-loaded before the price note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-output-schema tool the description covers what is returned (keyword, SAP, per-app ranks), which is the main thing an agent cannot get elsewhere. The credit cost is a useful addition. Minor gap: no mention of ordering or what happens when the package set is empty, but nothing essential to correct invocation 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 every parameter including limit, min_sap, min_apps, and min_rank is already documented in the schema. The description adds conceptual grounding by explaining that keywords carry a SAP popularity score and per-app ranks, which clarifies intent behind min_sap and min_rank, but it adds no syntax or format detail beyond the schema. Baseline 3 applies.

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 ('list the keywords they compete on') plus the shape of each row (popularity SAP, every app's rank). It names the near-sibling keyword_app_competitors and the axis that separates them (multi-app set vs single app), so an agent can distinguish the two without opening either 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?

Gives an explicit use case ('compare a whole competitor set head-to-head on one keyword list') and an explicit alternative with its triggering condition ('keyword_app_competitors starts from a single app instead'). The choice between the two tools is fully determined.

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

All AppmanAi 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.