Skip to main content
Glama
Sign In

sonar

by app.trysonar
OverviewDiscussionsAdmin

App Rank History

sonar_app_rankings
Read-onlyIdempotent

Rank history for an app's tracked keywords over the requested window. Compact by default: each keyword's current rank and status, best rank, positions gained and a newest-first daily ranks list (a rank, "unranked" = checked but not found, null = no check that day). Pass fields: "full" for the per-day observations grid: ranked has a numeric rank; not_found means a completed search did not return the app (results_count is the returned search size); not_observed means no confirmed check, including legacy gaps. Never interpret an absent rank as a collection failure or assign a numeric rank to it. The legacy history array contains positive ranks only. Use this to check how rankings moved after a metadata change or to find keywords trending up or down. Cursor-paginated over keywords (default 50 per page). Requires an Indie plan (trial counts).

Input Schema

NameRequiredDescriptionDefault
daysNoHistory window in days (1-365). Default 30.
limitNoPage size (1-200). Server default applies when omitted.
app_idYesSonar app UUID — the `id` returned by sonar_list_apps or sonar_create_product. NOT a store id.
cursorNoPagination cursor from a previous call's `next_cursor`. Omit for the first page.
fieldsNo"compact" (default): per keyword: rank + status + measured_at (latest day with a completed check or recorded rank), best_rank, positions_gained (oldest ranked day in the window minus the current rank; positive = moved up), and ranks — one entry per day, newest first starting at ranks_end: a number = the rank, "unranked" = a completed check did not find the app, null = no check that day (never report a null day as not ranked). About 7× smaller. "full": per keyword: the `history` array (positive ranks only) and the daily `observations` grid with status (ranked / not_found / not_observed) and results_count per day.compact
keyword_idNoRestrict to one keyword — a keyword_id from sonar_app_keywords. Omit for all tracked keywords.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / fields
      Added value: +{
+  "default": "compact",
+  "description": "\"compact\" (default): per keyword: rank + status + measured_at (latest day with a completed check or recorded rank), best_rank, positions_gained (oldest ranked day in the window minus the current rank; positive = moved up), and ranks — one entry per day, newest first starting at ranks_end: a number = the rank, \"unranked\" = a completed check did not find the app, null = no check that day (never report a null day as not ranked). About 7× smaller. \"full\": per keyword: the `history` array (positive ranks only) and the daily `observations` grid with status (ranked / not_found / not_observed) and results_count per day.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds substantial behavior: compact-by-default output shape, a roughly 7x size difference for `full`, cursor pagination at 50 keywords per page, plan gating, and explicit interpretive rules (null ≠ not ranked, absent rank ≠ collection failure, legacy history holds positive ranks only). Those warning-level semantics go well beyond anything in 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?

Front-loaded with purpose, then output shape, then semantics, then usage and constraints — a sensible order with no filler sentences. It is dense and somewhat long, and the rank/unranked/null encoding is explained in the body in a way that duplicates the `fields` schema text, but nothing is purely decorative.

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?

With no output schema and six parameters, the description carries the return-value burden and discharges it well: default shape, alternate shape, pagination, and ambiguity rules are all covered. It stops short of stating the response envelope (next_cursor handling, total counts) or behavior when the app has no tracked keywords.

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% and the `fields` enum already documents compact vs full, the `ranks` list encoding, positions_gained sign convention, and the observations statuses in comparable detail. The description largely restates that material, adding only the pagination default of 50 per page and the implicit cue that `full` is for day-by-day observation grids.

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

Purpose4/5

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

Opens with a specific verb-plus-resource statement: rank history for an app's tracked keywords over a requested window. The app-scoped framing implicitly separates it from sonar_keyword_rankings, but it never names that sibling explicitly, so the differentiation is inferred rather than stated.

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?

"Use this to check how rankings moved after a metadata change or to find keywords trending up or down" gives concrete decision context, and "Requires an Indie plan (trial counts)" is a useful prerequisite. There is no explicit when-not guidance or named alternative (e.g., sonar_keyword_rankings or sonar_app_keywords).

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

All sonar toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources