AppTail – ASO & Keyword Research

Get Competitors

get_competitors

List tracked competitor apps for one of your apps, with how many more the plan allows — and suggested: up to ten rivals the account does not track yet, ranked by how many of the app's own search terms they sit in the top ten for. Works on an app with no keywords: its listing is read for terms and the store is crawled for them. Read suggested_basis.terms_pending before calling a short list complete. Suggestions can persist shared keyword records and queue background crawls. Suggested apps are not added to your competitor watchlist.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`app_id`	Yes	Apptail app id for one of YOUR apps — get it from get_account. Not the numeric id in an App Store URL (that is apple_app_id).

Output Schema

TableJSON Schema

Name	Required	Description
`count`	Yes	Number of competitors returned.
`limit`	Yes	How many competitors this plan allows per app. -1 means unlimited.
`app_id`	Yes	The app these rivals are tracked against.
`remaining`	No	Slots left before add_competitors is refused. Null when the plan is unlimited.
`suggested`	Yes	Rivals worth tracking that are not on the list, strongest evidence first: apps in the top ten of the terms this app competes on (tracked, already ranked for, or read off its listing when it has neither), never the account's own apps, never one already tracked, never one hidden from the Landscape. Offer them with their `sample_terms`; add with add_competitors only when asked. Empty when the app has nothing to derive from — say that rather than "no competitors exist".
`competitors`	Yes	Apps tracked as competitors of the given app. Empty if none are tracked yet.
`suggested_basis`	No	What the suggestions were derived from. Null when the app is not one of the account's own — a suggestion needs your terms to read.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With readOnlyHint=false, the description proactively discloses the non-obvious write side effects: suggestions can persist shared keyword records and queue background crawls. It also explains the crawl/listing fallback for apps without keywords — real behavioral context beyond the annotations.

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

Conciseness4/5

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

The core purpose is front-loaded in the first clause, followed by the suggested-rivals explanation and the persistence/watchlist caveats. Dense but each sentence carries information; the opening sentence is long and stacks a secondary clause, costing a little clarity.

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?

An output schema exists, yet the description still points at the specific field (suggested_basis.terms_pending) needed to interpret completeness, and covers side effects and watchlist behavior. 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% and the single app_id parameter is fully documented in the schema, including the get_account source and the apple_app_id distinction. The description adds no parameter-level detail, so the 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+resource (list tracked competitor apps) plus the secondary output (suggested untracked rivals) and the ranking basis. An agent can distinguish this from add_competitors/remove_competitors 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 Guidelines4/5

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

Gives clear operational context: it works on apps with no keywords, tells you to read suggested_basis.terms_pending before treating a short list as complete, and clarifies that suggestions are not added to the watchlist. It does not explicitly name alternative siblings or state when-not to call it, so not a full 5.

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

All AppTail – ASO & Keyword Research 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?