Skip to main content
Glama
Sign In

sonar

by app.trysonar
OverviewDiscussionsAdmin

Discovered Keywords

sonar_discovered_keywords
Read-onlyIdempotent

Keywords Sonar's discovery engine surfaced for one of your tracked apps but that aren't tracked yet — ranked finds (the app already ranks, unnoticed), competitor gaps, and AI/autocomplete-sourced ideas — each with popularity, difficulty, AI relevance, and an opportunity score (0-100, best first). This is Sonar's "what should I track next" answer; rows can be tracked with sonar_track_keywords (by keyword text + country). Compact by default (no discovered-row id, store or timestamps; keyword_id stays; fields: "full" adds them). Requires an Indie plan (trial counts). popularity (5-100) is the value Sonar's dashboard shows: Apple's Search Popularity when Apple has a real reading; when Apple reports a keyword below its threshold (popularity_apple 5, about 20) it is Sonar's estimate (at most 18). popularity_source says which (apple | proxy), popularity_apple is Apple's own reading (null on Android), popularity_proxy is Sonar's estimate beside a floored reading.

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows to return (1-500). Default 200.
app_idYesSonar app UUID of one of your tracked apps — the `id` returned by sonar_list_apps or sonar_create_product. NOT a store id.
bucketNoFilter by classification: "ranked" = the app already ranks for it, "gap" = a competitor ranks but the app does not, "idea" = verified research suggestion with no rank evidence yet. Omit for all.
fieldsNo"compact" (default): keyword_id, keyword, country, rank, source, status, bucket, the four popularity fields, difficulty, ai_relevance, opportunity, competitor_rank, competitor_name. "full": adds the discovered-row id, store, discovered_at and ranks_checked_at.compact
sourceNoFilter by how the keyword was discovered. Omit for all sources.
statusNoFilter by row status. Default "new" — the still-actionable suggestions; "all" includes rows already tracked or hidden.
countryNoFilter to one market (ISO country code). Omit for all markets.
min_relevanceNoOnly rows with AI relevance at or above this value (0-100).
min_opportunityNoOnly rows with an opportunity score at or above this value (0-100).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / fields
      Added value: +{
+  "default": "compact",
+  "description": "\"compact\" (default): keyword_id, keyword, country, rank, source, status, bucket, the four popularity fields, difficulty, ai_relevance, opportunity, competitor_rank, competitor_name. \"full\": adds the discovered-row id, store, discovered_at and ranks_checked_at.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds real context on top: an Indie-plan prerequisite, a default status filter of "new" that hides already-tracked/hidden rows, opportunity-ranked ordering (best first), and a compact-vs-full payload default. It doesn't discuss result-size behavior or what happens when the app has no discovered rows, which keeps it below a 5.

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 purpose is front-loaded in the first clause, and the popularity explanation is dense but genuinely non-obvious. However, the parenthetical restating the compact/full field lists duplicates the schema's `fields` description, and the popularity paragraph is a single sprawling sentence that could be split.

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 nine parameters, no output schema, and no nested objects, the description does the work the schema cannot: it explains what a row contains, how results are ordered, how popularity is derived when Apple's reading is floored, the default filtering, and the plan gate. An agent has everything needed to call it correctly and interpret the response.

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%, including enum definitions and defaults, so the schema carries the parameter burden. The description restates the compact/full field lists almost verbatim from the schema and adds meaning mainly for output fields (popularity, popularity_source, popularity_apple, popularity_proxy) rather than inputs, 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?

The description names a specific resource with precise scope: keywords the discovery engine surfaced for a tracked app that aren't tracked yet, split into ranked finds, competitor gaps, and AI/autocomplete ideas. It explicitly frames itself as Sonar's "what should I track next" answer, which distinguishes it from siblings like sonar_app_keywords (already-tracked) and sonar_competitor_keywords.

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 the use case clearly and gives the follow-up path: rows can be tracked with sonar_track_keywords by keyword text + country. It also notes the Indie plan requirement. It does not explicitly contrast with the nearest alternatives (sonar_keyword_suggestions, sonar_app_extract_keywords), so the agent must infer when those are preferable.

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