Skip to main content
Glama

sonar

by app.trysonar

Portfolio Rollup (Agency)

sonar_portfolio
Read-only

The whole portfolio's health in one call — for orgs managing many apps: per-app KPIs (visibility + 7-day delta, ranked/top-10 counts, net rank movement, rating, review count), org-wide totals, the biggest keyword movers in both directions, a needs-attention triage list (visibility drops, rating drops, not-ranked apps), and the best discovered-keyword opportunities across all apps. Same numbers as the /portfolio page. Requires an Agency plan (403 on other plans).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.3/5.0
Behavior4/5

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

Given the readOnlyHint annotation, the description adds valuable context: it is a read-only aggregation call, and it explicitly mentions the 403 error for non-Agency plans. It also mentions it mirrors the /portfolio page, providing a reference for expected output. No contradictions.

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 description is a single but long paragraph; it is front-loaded with the key idea ('whole portfolio's health in one call') and then lists the contents efficiently. Every sentence adds value, though the enumeration is long but warranted given the breadth.

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?

Given the tool's complexity (it aggregates many types of data), the description is fairly complete: it enumerates the key output sections, states the audience, and alerts to plan restrictions. Without an output schema, the enumeration is helpful. It could mention that results are not paginated or any size limits, but overall sufficient.

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?

The tool has zero parameters, and the schema provides full coverage. The description adds meaning by detailing the content and scope of the result, which is the primary semantic value since there are no parameters to explain.

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 clearly states it provides a portfolio rollup for agencies, listing specific content (per-app KPIs, totals, keyword movers, triage, opportunities). It is distinct from sibling tools by aggregating across the entire portfolio, unlike per-app tools like sonar_app_overview.

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?

The description implies when to use it: for organizations managing many apps, and when a comprehensive portfolio-level view is needed. It also notes the requirement for an Agency plan, but does not explicitly contrast with alternatives like individual app tools.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct action or data aspect within the ASO domain. Keyword-related tools are clearly separated by purpose (tracked keywords vs. research vs. suggestions vs. metrics), and competitive tools differentiate between reading landscape and generating new analysis. No two tools have overlapping functionality that would confuse an agent.

Naming Consistency3/5

Naming is a mix of verb-first (e.g., sonar_add_screenshot, sonar_create_product) and noun-first patterns (e.g., sonar_app_keywords, sonar_competitor_landscape). While all use snake_case and the 'sonar_' prefix is consistent, the lack of a uniform verb_noun structure makes it harder to predict tool names. The pattern is readable but inconsistent.

Tool Count2/5

With 47 tools, the server is over-scoped for a typical MCP server. Although the ASO domain is broad, many tools are granular (e.g., 10 screenshot tools, 10 keyword tools). This quantity exceeds the 25+ threshold for 'too many' as defined in the calibration, making it heavy for an agent to navigate comprehensively.

Completeness5/5

The tool surface covers the full ASO lifecycle: app discovery, keyword research, tracking and ranking, competitor analysis, revenue estimation, screenshot creation and export, alerts, and product management. There are no obvious gaps—every necessary operation for monitoring and optimizing app store presence is present, including both read and write actions.

Resources