Skip to main content
Glama

RevenueScope: revenue-first analytics for your EC site

Revenue breakdown by dimension

get_breakdown
Read-only

Consolidated breakdown tool. Pick dimension: 'channel' returns per-channel sessions/revenue/RPS plus engagement (visitors, avg dwell seconds, bounce rate) and bot_excluded_count (bot sessions removed from human metrics; a channel with sessions=0 but bot_excluded_count>0 is bot-only traffic, kept so it is not mistaken for 'no traffic') and — when ad spend is connected (Path B) — spend/ROAS/saturation; plus an 'Unattributed' row (is_unattributed=true) for purchase revenue not tied to any channel, with a revenue_breakdown summary (total_event_jpy/attributed_jpy/unattributed_jpy); pass attribution_model ('last_touch' default / 'first_touch' / 'linear' / 'time_decay') to switch how purchase revenue and orders are attributed across channels — same models as the dashboard's attribution selector; revenue_jpy/rps_jpy/orders/aov_jpy/cvr change, while sessions/engagement/bot/spend/ROAS are model-independent, so compare models to see e.g. how much an awareness channel gains under first_touch vs last_touch. each channel row also carries orders (purchase orders counted by our own tracker), aov_jpy and cvr derived from it — withheld as null below 10 orders, and always null on ad-platform / Unattributed rows; do NOT divide revenue_jpy by conversions to rebuild AOV, conversions is the ad platform's self-reported count, a different denominator. pass filter.channel to drill into that channel's campaigns (utm_campaign) with RPS/AOV/CVR — the value must be a channel name exactly as this tool returns it, case included (e.g. 'Google Ads', 'Meta', 'Criteo', 'Google検索'), since the match is exact and a lowercase slug returns nothing. 'page' returns per-page pageviews/unique visitors/avg time/bounce plus the page title (what the page IS, so a row reads as an article name rather than a slug; null for pages with no visit since 2026-08-21 — it does not backfill) ranked by pageviews (limit default 20, max 200; query strings stripped, bots excluded; each row also carries GSC Google-search impressions/clicks/ctr/avg_position merged by normalized path — null when the page has no GSC row, and a DIFFERENT denominator from pageviews, see notes). 'session_attribute' returns the device / time-of-day (4h JST) / day-of-week (ISO) / new-vs-returning (with AOV) / country (top-15 by sessions + 'Other', ISO2 code, share_pct; from first-party session geo, 'Unknown' when IP unresolved) breakdowns in one call. site_id is OPTIONAL when OAuth-authenticated. Default period is the last 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). filter only applies to dimension='channel'; limit only applies to dimension='page'. Pass optional country (ISO2, e.g. 'JP') and/or device ('mobile'/'desktop'/'tablet') to scope session-derived metrics across any dimension (omit = all). For dimension='channel' you can also pass visitor_type ('new'/'returning') to split the channel table by first-time vs returning visits — the split uses the DATE-based rule (no visit by the same visitor on an earlier JST day = new), the same rule the dashboard's KPI card uses, NOT the tracker's stored is_new_visitor flag; under it engagement fields, bot counts, ad-platform aggregate rows, Unattributed, and revenue_breakdown are omitted because their sources have no visitor_type dimension. Session rows keep ad_platform mapping metadata. Combining visitor_type with filter.channel is rejected with InvalidParams because campaign drill-down has no visitor-type axis. dimension='page' rows include pageviews_change (period-over-period % vs the previous equal-length window, null = new page).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
deviceNo
filterNo
periodNo30d
countryNo
site_idNo
dimensionYes
visitor_typeNo
attribution_modelNolast_touch

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
rowsNo
basisNo
notesNo
filterNo
periodYes
site_idYes
dimensionYes
truncatedNo
assumptionsNo
limitationsNo
total_pagesNo
total_pageviewsNo
attribution_modelNo
revenue_breakdownNo
presentation_hintsYes
session_attributesNo

TDQS

A4.6/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint and openWorldHint annotations. It discloses edge cases and internal behavior: bot_excluded_count semantics, null handling for orders below 10 and for ad-platform/Unattributed rows, the page title backfill limitation ('null for pages with no visit since 2026-08-21 — it does not backfill'), GSC denominator differences, the date-based visitor_type rule vs tracker flag, rejection behavior for invalid combinations, and the caution against dividing by `conversions`. It even explains the attribution model's effect on specific metrics. This is exhaustive and prevents misuse.

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

Conciseness3/5

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

The description is a single, very dense paragraph (over 2000 characters) that mixes multiple topics with semicolons, parentheses, and clauses. While every sentence carries substantive information, the lack of visual structure (headers, bullets, or clear separation by dimension) makes it harder to scan. It is not redundant, but it is not concise in the sense of being quickly parseable. Given the high complexity, the length is justified, but the structure could be improved to earn a higher score.

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?

Given the tool has 9 parameters, nested objects, 4 enums, and an output schema, the description covers everything an agent needs to call it correctly: parameter semantics, defaults, restrictions, edge cases, error behavior, and common pitfalls. It even explains what to do when comparing attribution models. There is no apparent gap; the description is a complete usage manual. The presence of an output schema further reduces the need to describe return values, but the description already covers key return fields (e.g., revenue_breakdown, pageviews_change).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% — the schema only lists types/enums/defaults with no descriptions. The description compensates fully by explaining every parameter's meaning and behavior: dimension options, period defaults and allowed values, filter structure and exact-match requirement, limit scope, site_id optionality, country/device scoping, visitor_type split rule, and attribution_model semantics with examples. It also clarifies how parameters interact (e.g., filter+visitor_type rejection). This is a model of parameter documentation.

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 opens with 'Consolidated breakdown tool' and then enumerates exactly what each dimension returns ('channel' returns per-channel sessions/revenue/RPS plus engagement..., 'page' returns per-page pageviews/unique visitors/avg time/bounce..., 'session_attribute' returns the device / time-of-day / day-of-week...'). It clearly states the resource (breakdowns) and the verb (get). It distinguishes itself from siblings by covering three distinct dimensions in one tool, while siblings like get_page_trend or get_ai_traffic are more specialized. The purpose is unambiguous and actionable.

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 provides extensive guidance on when and how to use the tool: it explains which parameters apply to which dimensions ('filter only applies to dimension='channel'; limit only applies to dimension='page''), when site_id is optional, how to combine country/device/visitor_type, and when combinations are rejected ('Combining visitor_type with filter.channel is rejected with InvalidParams'). It doesn't explicitly name alternatives among siblings, but it gives clear context on scope and restrictions, leaving little ambiguity about when this tool is appropriate. Lacks explicit 'use this instead of X' statements, so not a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct purpose: AI traffic analysis, multi-dimensional breakdown, competitor SEO snapshot, content playbook, keyword performance, page trend, priority insights, summary, site listing, and budget allocation. Overlapping domains like search performance are clearly separated by focus (query-level vs page-level vs competitor).

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., get_ai_traffic, get_breakdown, list_sites). The verbs are uniformly descriptive ('get', 'list', 'suggest'), and the naming style is predictable and clean.

Tool Count5/5

With 10 tools, the server is well-scoped for a comprehensive analytics platform. Each tool covers a critical area (summary, traffic sources, breakdowns, search performance, competitor analysis, content actions, budget allocation) without unnecessary bloat.

Completeness5/5

The tool surface covers all major aspects of revenue-first e-commerce analytics: overall KPIs, AI traffic, channel/page/session breakdowns, search keyword and content performance, competitor insights, trend analysis, priority diagnoses, and budget recommendations. No obvious gaps for the stated purpose.

Resources