Skip to main content
Glama

RevenueScope: revenue-first analytics for your EC site

Content actions (classify pages + playbook)

get_content_actions
Read-only

Return a content 'playbook' for the site: every content page classified into ONE of five action buckets over a weekly-style window comparison (current window vs the immediately preceding window of equal length), ranked by search-opportunity × session gain so you can tell the user which page to GROW next and what to do: within the 'striking' bucket rows are ordered by expected_sessions_gain DESC (the band-CTR headroom that is the actionable lever there), while the other buckets keep real landing revenue DESC (largest revenue at stake first). This surfaces search intent to add sessions (grow the traffic denominator), NOT CVR — a page already winning on sessions/revenue but with zero clicks still shows up. Buckets: 'decaying' (search clicks actually fell, OR the page had real traffic (previous clicks ≥3) and its rank slid ≥2 positions from within the click zone while clicks did NOT grow → refresh/rewrite; a rank slide alone with growing/negligible clicks is NOT decay — search clicks are the primary signal, position only a leading indicator), 'striking' (has striking-distance queries at positions 4-20 with click upside but clicks still low → push those queries up; top 3 listed in striking_queries), 'rising' (clicks grew significantly → produce more of this, strengthen CTA), 'dormant' (has impressions but ~0 clicks and its main query is far below the click zone → big rewrite or consolidate; zero-pageview pure-rank pages surface here), 'stable' (none of the above → watch). Each page also carries current/previous clicks·impressions·avg_position, is_new, landing sessions/engaged/revenue_jpy, AI-referred sessions/revenue/sources, expected_sessions_gain (the window's expected incremental sessions from striking-band queries — a search click is ~1 session, so it is NOT re-converted via CTR; normalize to a monthly figure with the window length), and expected_revenue_gain (expected_sessions_gain × page RPS, returned ONLY when revenue>0 and sessions>=5 — display-only projection, never a sort key). The deterministic action mapping and all (provisional) thresholds come back in criteria; the model does the narrative interpretation (mcp-first). Rows with confidence='low' carry caveats — 'geo_winning_suspect' (AI Overview/citations likely substitute the click: a GEO win, don't break the page; cross-check get_ai_traffic), 'zero_click_suspect' (SERP-feature occupation or intent-mismatch/polysemous query: verify the live SERP first), 'ai_cited' (decaying but the AI citation is alive) — verify before acting on low-confidence rows; definitions in criteria.caveat_flags. The response is summary-first (token-aware): bucket_summary always holds the FULL pre-limit distribution (per-bucket count/revenue/clicks) plus total_pages, while pages returns only the top rows in priority order (default limit 15, max 200); pass bucket='striking' etc. to drill into one bucket, and check truncated — when present it tells how many rows were cut and how to fetch them. GSC-driven and Google-search only; data lags 1-2 days so the current window's right edge sits a few days back. When narrating a bucket to the user, scope it to Google search — say 'search traffic to this page is declining', NOT 'this page is declining'; the classification is a search-trend diagnosis, not overall page health, so a page labeled 'decaying' can be thriving on Direct/social/AI. Before calling a negative bucket (decaying/dormant) a problem, cross-check the row's landing sessions/revenue_jpy and ai_sessions. site_id is OPTIONAL when OAuth-authenticated. Default window is the last 7 days vs the prior 7; pass period='30d'/'90d' or a raw day count (2-365). Window date bounds are INCLUSIVE on both ends, so period=Nd actually spans N+1 calendar dates (the real range is in window); both windows share the same length, so the comparison stays symmetric. This is the cross-page action snapshot; for one page's time series use get_page_trend, and for AI-citation gaps use get_ai_traffic(mode='gaps').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
bucketNo
periodNo7d
site_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
basisYes
pagesYes
periodYes
windowYes
site_idYes
warningNo
criteriaYes
truncatedNo
assumptionsYes
limitationsYes
total_pagesYes
bucket_summaryYes

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses data lag (1-2 days), window inclusivity semantics, inclusive date bounds, sorting rules within buckets, confidence caveats, truncation behavior, and non-obvious disclaimers (e.g., 'decaying' does not mean the page is failing overall). It also warns about 'geo_winning_suspect' and other caveats that require human verification.

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 front-loaded with its core purpose and is exceptionally detailed, but it is very long. While nearly every sentence adds substantive guidance, the density approaches the limit of conciseness; a slight restructuring into bullet points would improve scannability without losing content.

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's complexity (five buckets, sorting nuances, caveats, response structure, period behavior), the description is impressively complete. It covers bucket semantics, sort criteria, expected metrics, window comparison rules, caveat flags, and notes return fields like bucket_summary and truncated. The output schema existence further reduces the need to document return types.

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 descriptions are absent (0% coverage), so the description carries full burden. It compensates thoroughly: explains all five bucket values, period options ('7d', '30d', '90d' or raw day count 2-365), inclusive date interpretation, limit default/max values, and site_id optionality with OAuth. This is far beyond what the schema alone provides.

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 'Return a content playbook for the site: every content page classified into ONE of five action buckets' – a specific verb and resource. It explicitly addresses scope ('cross-page action snapshot') and distinguishes from sibling tools by naming get_page_trend and get_ai_traffic as alternatives for different needs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description states exactly when to use this tool (cross-page prioritization, telling the user which page to grow) and explicitly names alternatives for one-page time series and AI-citation gaps. It also provides clear exclusions, e.g., 'NOT CVR' and the instruction to cross-check landing metrics before calling a bucket a problem.

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