RevenueScope: Japanese EC RPS Benchmarks
Server Details
Ask AI for verified Japan EC RPS benchmarks (5 industries, growing). For non-analytics users.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 9 of 9 tools scored. Lowest: 4.1/5.
Each tool has a clearly distinct purpose: summary KPIs, detailed breakdowns, AI traffic analysis, content playbook, keyword performance, page trends, priority insights, site listing, and budget allocation. No overlap in functionality.
All tool names follow the verb_noun pattern (mostly 'get_...'), with 'list_sites' and 'suggest_budget_allocation' as minor exceptions but still consistent in style.
9 tools cover the full scope of EC analytics (KPIs, breakdowns, SEO, AI, budget) without being excessive or sparse. Each tool earns its place.
Covers all major analytics areas: high-level summary, granular breakdowns, keyword and page performance, content actions, AI insights, priority diagnoses, and budget suggestions. No obvious gaps.
Available Tools
10 toolsget_ai_trafficARead-onlyInspect
Return AI-assistant (ChatGPT/Claude/Perplexity/Gemini/Copilot) traffic for the given period. mode='referred' (default) lists landing pages that received clicked AI traffic — per page × AI source: sessions, bounce rate (%, always computed; judge reliability via the sessions count), summed revenue, and last citation date (default limit 100); a view GA4/GSC cannot produce (GSC is Google-search only; GA4 lacks an AI-source breakdown). mode='gaps' returns where the site leaves AI value on the table as a ranked action list: (1) missed_citation_pages — content articles with real audience but ~0 AI traffic (push for AI citation / GEO), ranked by engagement-weighted reach; (2) under_monetized_ai_pages — pages WITH AI traffic engaging below the site's own AI norm (improve landing/CTA), ranked by AI arrivals lost below benchmark (default limit 10/list); methodology fixed in code. 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). Scope is clicked citations only.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | referred | |
| limit | No | ||
| period | No | 30d | |
| site_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| rows | No | |
| basis | Yes | |
| notes | No | |
| period | Yes | |
| site_id | Yes | |
| criteria | No | |
| ai_sources | No | |
| assumptions | No | |
| limitations | No | |
| total_ai_sessions | No | |
| missed_citation_pages | No | |
| under_monetized_ai_pages | No | |
| site_benchmark_engaged_rate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description confirms it's a read operation. It discloses that bounce rate is always computed but reliability depends on sessions, and describes the methodology for 'gaps' mode. Adds significant behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence adds value. It is front-loaded with the main purpose. Minor redundancy could be trimmed, but overall it is well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (two modes, varied parameters), 0% schema coverage, and presence of an output schema, the description is comprehensive. It covers all parameters, use cases, and behavioral notes, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: mode options and defaults, limit default=100, period default='30d' and acceptable values, and that site_id is optional when authenticated. Adds meaning beyond the schema's enum/type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns AI-assistant traffic for a given period, distinguishes between 'referred' and 'gaps' modes, and names specific AI sources. It differentiates from GA4/GSC, a key sibling capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (e.g., 'referred' for landing pages, 'gaps' for missed opportunities) and contrasts with GA4/GSC. It does not explicitly discuss when not to use this tool versus specific siblings, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_breakdownARead-onlyInspect
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 is attributed across channels — same models as the dashboard's attribution selector; only revenue_jpy/rps_jpy change (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. pass filter.channel (e.g. 'google','meta','organic_search') to drill into that channel's campaigns (utm_campaign) with RPS/AOV/CVR. 'page' returns per-page pageviews/unique visitors/avg time/bounce 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). Under such a filter, dimension='channel' keeps ad spend/ROAS site-wide (no country/device dimension) and omits the Unattributed row + revenue_breakdown (see notes); dimension='page' rows include pageviews_change (period-over-period % vs the previous equal-length window, null = new page).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| device | No | ||
| filter | No | ||
| period | No | 30d | |
| country | No | ||
| site_id | No | ||
| dimension | Yes | ||
| attribution_model | No | last_touch |
Output Schema
| Name | Required | Description |
|---|---|---|
| path | No | |
| rows | No | |
| basis | No | |
| notes | No | |
| filter | No | |
| period | Yes | |
| site_id | Yes | |
| dimension | Yes | |
| truncated | No | |
| assumptions | No | |
| limitations | No | |
| total_pages | No | |
| total_pageviews | No | |
| attribution_model | No | |
| revenue_breakdown | No | |
| session_attributes | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description covers extensive behavioral details beyond the readOnlyHint annotation, including filter scoping, limit application, period defaults, bot_excluded_count semantics, unattributed rows, and model-independence for certain metrics. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured, front-loading the core purpose and grouping related details. While not overly concise, every sentence adds necessary context for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, multiple dimensions) and the presence of an output schema, the description covers all essential aspects: dimension-specific return values, filter interactions, edge cases, and parameter defaults. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, constraints, defaults, and interdependencies (e.g., filter only for channel, limit only for page). This provides essential semantics the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a consolidated breakdown tool for three dimensions (channel, page, session_attribute) with specific metrics for each, differentiating it from siblings like get_keyword_performance or get_page_trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implicitly tells when to use it (for breakdowns by dimension), it lacks explicit when-not-to-use or direct comparison with alternatives. However, the detailed per-dimension explanation makes usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_competitor_keywordsARead-onlyInspect
Return the latest competitor SEO snapshot for the site (FD-041): which keywords each tracked competitor DOMAIN ranks for on Google (Japan/ja), at what position, with monthly search_volume, cpc and etv (estimated monthly traffic — a visit estimate, not a monetary value), plus how each rank moved vs the previous snapshot. READ-ONLY — this tool never runs a research (that costs money and is triggered separately from the dashboard, the competitor-research Edge Function); it only reads what was already fetched. The response is summary-first (token-aware): each domain carries a constant-size summary (total_keywords, total_etv, volume_bands and rank_bands histograms, and vs_previous new/lost/improved/declined/same counts) that always reflects the FULL keyword set, while keywords returns only the top rows ranked by sort (etv default | volume | rank; default limit 10 per domain, max 100) with a truncated block (shown/matching_total/lost_total). rank is a POSITION: smaller is better, so a NEGATIVE rank_delta means the competitor's ranking IMPROVED (change ∈ new/improved/declined/same/unknown). Keywords the competitor ranked for before but lost are disclosed in lost_keywords (top 10 by previous etv), never dropped silently. Pass domain to focus one competitor, min_volume to drop low-volume keywords. When the site has NO completed research yet the response is { researched:false } with a guidance string explaining a research must be triggered from the dashboard first — this tool cannot start one. site_id is OPTIONAL when OAuth-authenticated. This is the external competitor lens (third-party SERP data); for YOUR OWN search performance use get_keyword_performance, and for your content playbook use get_content_actions.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| domain | No | ||
| site_id | No | ||
| min_volume | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| sort | No | |
| basis | Yes | |
| limit | No | |
| domains | No | |
| guidance | No | |
| fetched_at | No | |
| min_volume | No | |
| researched | Yes | |
| assumptions | Yes | |
| limitations | Yes | |
| research_id | No | |
| keyword_count | No | |
| language_code | No | |
| location_code | No | |
| available_domains | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reinforces readOnlyHint with 'READ-ONLY' and explains it never runs a research that costs money. Describes response structure (summary-first, truncated, lost_keywords) and clarifies rank delta semantics (negative means improved).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is detailed and front-loaded with core purpose. While every sentence adds value, the length could be slightly trimmed without losing clarity. Still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (5 parameters, output schema exists), description covers response structure (summary, keywords, truncated, lost_keywords, researched flag) and key details like rank_delta meaning. Very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains all parameters: sort (enum, default etv), limit (default 10, max 100), domain (focus), min_volume (filter low-volume), site_id (optional when OAuth). Adds meaning beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the latest competitor SEO snapshot with keywords, positions, volume, cpc, etv, and rank movement. It distinguishes from sibling tools like get_keyword_performance (own performance) and get_content_actions (content playbook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (external competitor lens) and when not (for own performance or content playbook use other tools). Also clarifies that research must be triggered from dashboard; this tool cannot start one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_content_actionsARead-onlyInspect
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').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| bucket | No | ||
| period | No | 7d | |
| site_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| basis | Yes | |
| pages | Yes | |
| period | Yes | |
| window | Yes | |
| site_id | Yes | |
| warning | No | |
| criteria | Yes | |
| truncated | No | |
| assumptions | Yes | |
| limitations | Yes | |
| total_pages | Yes | |
| bucket_summary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond the annotations (which already indicate readOnlyHint=true): data lag of 1-2 days, deterministic action mapping with provisional thresholds, confidence levels with caveats (geo_winning_suspect, zero_click_suspect, ai_cited), summary-first token-aware response, truncated handling, and scope limitations (Google search only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence adds value, given the tool's complexity. It is front-loaded with the main purpose and bucket definitions, then covers ordering, caveats, data lags, and cross-references. Some redundancy exists (e.g., multiple mentions of bucket definitions), but overall it is well-structured for the information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's intricacy (five buckets, specific ordering, confidence levels, caveats, truncated handling, data lag, cross-references to siblings), the description is remarkably complete. It covers return format (bucket_summary, pages, truncated), interpretation guidance, and scope limitations. The existence of an output schema reduces the need to detail every field, but the description already mentions many relevant fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all parameters: limit (max 200, default 15), bucket (enum values and their meanings), period (default 7d, options 30d/90d or raw day count 2-365), and site_id (optional when OAuth-authenticated). It adds meaning beyond the schema's type constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a content 'playbook' classifying pages into five action buckets with specific ordering and ranking criteria. It distinguishes from siblings by explicitly mentioning alternatives like get_page_trend and get_ai_traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('cross-page action snapshot') and when to use alternatives (e.g., get_page_trend for time series, get_ai_traffic for AI-citation gaps). It also includes cautionary notes like cross-checking negative buckets with landing sessions and AI traffic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_keyword_performanceARead-onlyInspect
Return search-query performance from Google Search Console for the given period. band='all' (default) returns per-query metrics — clicks/impressions/CTR/avg position/top landing page plus an estimated revenue per query (= 検索 organic RPS × clicks, a conservative estimate, 0 until the site has 検索 organic revenue), ranked by clicks (default limit 100). Each row also carries the period-over-period change vs the previous equal-length window: clicks_change (traffic) and est_revenue_change (money), both % deltas (null = the query is NEW, i.e. had no clicks/revenue last period — render as '新規', not 0%). Comparing the two surfaces RS's signature insight — e.g. clicks +74% but est_revenue −21% means traffic grew while money fell, something GA4/GSC cannot show side by side. band='striking' returns the SEO action list: queries 'striking distance' from the top (ranking ~4-20 with real impressions) where improving a few positions yields the biggest click/revenue gain, ranked by estimated revenue opportunity (incremental clicks × search-organic RPS, default limit 10); the methodology is fixed in code. 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). Google-search only.
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | all | |
| limit | No | ||
| period | No | 30d | |
| site_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| band | Yes | |
| rows | Yes | |
| basis | No | |
| period | Yes | |
| site_id | Yes | |
| warning | No | |
| criteria | No | |
| assumptions | No | |
| limitations | No | |
| rps_search_jpy | No | |
| revenue_estimate_basis | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true. The description adds rich behavioral details: period-over-period changes, estimated revenue methodology, handling of null values, and fixed methodology for 'striking' band. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is detailed but well-structured: purpose first, then bands, then period and site_id. Some sentences are lengthy (e.g., estimated revenue explanation), but all information is relevant. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (two bands, multiple metrics, period options, site_id optionality) and presence of output schema, the description covers all necessary aspects for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the tool description thoroughly explains each parameter: band (all/striking), limit (default 100/10), period (options: today/7d/30d/90d or raw days), and site_id (optional with OAuth). Adds meaning beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns search-query performance from Google Search Console. Distinguishes between 'all' band (general per-query metrics) and 'striking' band (SEO actionable list). Differentiates from sibling tools like get_ai_traffic by focusing on Google-search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use each band and explains default period and optional site_id. Does not explicitly list when not to use or compare to alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_page_trendARead-onlyInspect
Return how ONE page's Google Search performance changed over time (FD-040) — the time-axis drill-down for a page surfaced by get_breakdown(dimension='page'). Given a page (a normalized path like '/news/rps-revenue-per-session-guide' or a full URL — both resolve), returns a series of day or week buckets, each with clicks, impressions, and impression-weighted avg_position, plus a summary (first/last/best/worst position, position_delta, click & impression totals). avg_position is a RANK: smaller is better, so a NEGATIVE position_delta means the page's ranking IMPROVED over the window (e.g. 12.0 → 9.0 = delta −3.0). Use this to verify whether SEO work on a page paid off (rank rose / clicks grew) or slipped. Buckets where the page never appeared in search are omitted (gaps), so the series can be shorter than the period. granularity defaults to 'day' for windows up to ~35 days and 'week' for longer (weekly smooths daily noise); pass it to override. 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). Google-search only; data lags 1-2 days. This is per-page; for the cross-page snapshot use get_breakdown(dimension='page'), and for per-query (keyword) trends use get_keyword_performance.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| period | No | 30d | |
| site_id | No | ||
| granularity | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| basis | Yes | |
| period | Yes | |
| series | Yes | |
| site_id | Yes | |
| summary | Yes | |
| warning | No | |
| assumptions | Yes | |
| granularity | Yes | |
| limitations | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true), the description discloses data lag (1-2 days), omitted buckets (gaps), interpretation of avg_position as rank (smaller better), and the meaning of negative position_delta (improvement). This adds significant behavioral context that annotations alone don't provide, enabling correct interpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the core function. Every sentence adds value, but slight redundancy exists (e.g., mentioning bucket omission both in explanation and examples). It is well-organized but could be tightened slightly for even greater conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema, sibling context), the description is complete. It covers period defaults, granularity behavior, authentication, data lag, gaps, rank semantics, and links to sibling tools. The presence of an output schema reduces the need to detail return values, but the description still does so briefly, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all 4 parameters: page (accepts normalized path or full URL), period (presets 'today', '7d', etc. or integer), site_id (optional with OAuth), and granularity (auto-switches based on window length; can override). This fully compensates for the missing schema descriptions and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return'), resource ('ONE page's Google Search performance'), and scope ('over time'). It specifies it's the time-axis drill-down for get_breakdown, and further distinguishes from sibling tools like get_breakdown and get_keyword_performance. This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use ('verify whether SEO work on a page paid off') and when not ('for cross-page snapshot use get_breakdown', 'for per-query trends use get_keyword_performance'). It also covers defaults, optionality of site_id with OAuth, period options, and granularity override, providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_priority_insightsARead-onlyInspect
Return the top 3 prioritized, pre-computed DIAGNOSES for the site over the given period — 'what should I act on this week', ranked by revenue impact. Unlike get_site_summary / get_kpi_summary / get_channel_breakdown (which return data), this applies a deterministic rule engine over KPI period-over-period changes, per-channel RPS/ROAS/saturation, and AI-assistant referral growth, and returns ranked findings (revenue-trend swings, high-efficiency channels to scale, over-allocated low-efficiency channels, loss-making/saturated ad channels, revenue concentration risk, emerging AI traffic) — each with a severity (risk/opportunity/watch), the numbers, and a recommended action. The priority judgment is fixed in code (not LLM-generated). site_id is OPTIONAL when OAuth-authenticated. Default period is 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). Returns fewer than 3 when fewer rules fire (no padding).
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 30d | |
| site_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| basis | Yes | |
| period | Yes | |
| site_id | Yes | |
| insights | Yes | |
| assumptions | Yes | |
| limitations | Yes | |
| rules_evaluated | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds extensive behavioral context beyond annotations, such as the deterministic rule engine, fixed-in-code logic, and types of findings. No contradiction with readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose and packs many details efficiently. While not broken into paragraphs, it is concise and adds minimal fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers tool output format, number of results, rule engine nature, parameter behaviors, and edge cases (fewer than 3 results). No gaps given the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description thoroughly explains both parameters: period (default, accepted values) and site_id (optional when OAuth), adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning the top 3 prioritized diagnoses ranked by revenue impact, and explicitly distinguishes it from sibling tools like get_site_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides good context (e.g., 'what should I act on this week'), differentiates from sibling tools, and explains parameter defaults, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_summaryARead-onlyInspect
Return the full headline summary for a site and period in ONE call: the 5 KPIs (revenue, sessions, RPS, AOV, CVR) PLUS two engagement KPIs (avg_duration = average dwell time in seconds, bounce_rate = % single-page-exit sessions) each with value AND the period-over-period change vs the previous equal-length window, PLUS a daily revenue/sessions/conversions trend, PLUS ad-spend availability (connected_channels, ad_spend_data_status, ad_spend_channels_in_period) and the Path A/B recommendation. avg_duration/bounce_rate are useful for sites with no revenue yet (engagement view). Pass optional country (ISO2, e.g. 'JP') and/or device ('mobile'/'desktop'/'tablet') to scope the session-derived KPIs and trend to that segment (omit = all); ROAS stays site-wide (ad spend has no country/device dimension). This is what the dashboard's KPI cards + revenue-trend chart show, merged with the site's ad-spend context. Call this first when a user asks 'how is my site doing?'. site_id is OPTIONAL when OAuth-authenticated (server falls back to the primary site). Default period is the last 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). change is a percentage for revenue/sessions/RPS/AOV/avg_duration and an absolute percentage-point delta for CVR and bounce_rate. For period='today' the comparison is today-so-far vs the SAME elapsed window yesterday (e.g. midnight→now vs midnight→same-time-yesterday), so 'previous' can read below yesterday's full-day total — that is expected, not a discrepancy. ad_spend_data_status / ad_spend_channels_in_period reflect spend data ACTUALLY present in the period (consistent with get_channel_breakdown); path_recommendation reflects whether the requested period holds any channel with spend>0 (Path B = ad spend connected), the same definition the other tools use. kpis.roas is the SITE-WIDE ROAS (RS-measured revenue ÷ ad spend over channels that have spend — Σrevenue ÷ Σspend, the same definition as the dashboard's overall ROAS and FD-030 A-1; the spend-weighted aggregate of get_breakdown's per-channel ROAS) with value/previous/change (前期比 from a current + previous 2-window computation); it is null on Path A / when the period has no ad spend (ROAS is undefined with zero spend), so render it only when present. When the PREVIOUS window has no spend, roas.previous and roas.change are null (unknown baseline, not 0.00x) — treat that as 'no prior-period comparison', never as a drop from zero.
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | ||
| period | No | 30d | |
| country | No | ||
| site_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| kpis | Yes | |
| basis | Yes | |
| trend | Yes | |
| period | Yes | |
| site_id | Yes | |
| previous_period | Yes | |
| connected_channels | Yes | |
| path_recommendation | Yes | |
| ad_spend_data_status | Yes | |
| ad_spend_rows_in_period | Yes | |
| ad_spend_channels_in_period | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses extensive behavioral details beyond annotations, such as the change type (percentage vs absolute points for different KPIs), the 'today' comparison logic, when ROAS is null, the separate recency signal for path_recommendation, and the scope of country/device filtering. Annotations only indicate readOnlyHint=true, which the description does not contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose and enumerates all components clearly. Every sentence adds value, including edge cases and parameter behavior. Slightly verbose but justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool and the existence of an output schema, the description covers return structure (KPIs with value/previous/change, trend, ad-spend data, recommendation), parameter behavior, default values, edge cases (today period, ROAS null), and cross-tool consistency (with get_breakdown). It leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by explaining each parameter's meaning, optionality, default values, and scoping behavior (e.g., country/device affect session-derived KPIs but not ROAS). It also clarifies site_id is optional with OAuth and period variants including day counts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns the full headline summary for a site and period in one call, listing all KPIs, trends, ad-spend, and recommendation. It distinguishes itself as the top-level summary to call first when a user asks 'how is my site doing?', clearly differentiating from sibling tools like get_breakdown or get_ai_traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'Call this first when a user asks how is my site doing?' It also explains the behavior of parameters and the 'today' period edge case, but does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sitesARead-onlyInspect
List the sites this caller can analyze, in two groups. my_sites = the sites connected to the signed-in account (each with its display name + domain, so you can match phrases like "the production site" or "revenuescope.jp" without the user pasting a UUID); empty when the caller is not signed in. demo_sites = ready-made sample sites for trying RevenueScope before connecting your own — each is a fictional site with sample data, not a real customer. When signed in (OAuth), prefer my_sites and, if site_id is omitted, default analytics tools to the is_primary=true site. When NOT signed in, my_sites is empty: use a demo_sites site_id and tell the user the numbers come from a sample site, not their own.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| my_sites | Yes | |
| demo_sites | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, which is consistent. The description adds valuable behavioral context: my_sites empty when not signed in, demo_sites are fictional, and default analytics behavior. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and logically structured. It is somewhat lengthy but every sentence adds value; slight room for tighter phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input parameters and an existing output schema, the description provides complete context: explains the two result groups, auth-dependent behavior, and default selection. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds significant meaning by detailing the two groups in the return structure and their constituents, which goes beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sites the caller can analyze, broken into my_sites and demo_sites. It distinguishes from sibling tools by being the only list-focused tool, and provides specific details on each group's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use my_sites vs demo_sites, behavior when signed in vs not, and default selection. It effectively tells when-not and alternatives without naming sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_budget_allocationARead-onlyInspect
Return a proposed monthly budget split across paid ad channels (Google Ads / Meta / TikTok Ads / Yahoo! Ads / LINE Ads etc.). site_id is OPTIONAL when the request is OAuth-authenticated. Path B (ad spend connected — any channel with spend>0 in the period): weight = ROAS × (1 − saturation) where ROAS is RS-measured revenue ÷ spend (FD-030 A-1, same as the dashboard — NOT platform-reported conversion_value). saturation is not derived yet (W17+), so channels without it are weighted by ROAS alone with no efficiency cap — stated in limitations. Path A (no ad spend): RPS-weighted proportional split with explicit ±20-30% caveats and a connect_incentive_message. Default period for the underlying ROAS/RPS data is 30 days; pass period='today' / '7d' / '90d' or a raw day count (1-365) to override. LLMs should pass assumptions, limitations, and connect_incentive_message through verbatim — they are hardcoded honest axis.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 30d | |
| site_id | No | ||
| monthly_budget_jpy | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| site_id | Yes | |
| allocation | Yes | |
| assumptions | Yes | |
| limitations | Yes | |
| next_action | Yes | |
| unallocated_jpy | Yes | |
| monthly_budget_jpy | Yes | |
| expected_roas_current | Yes | |
| expected_roas_proposed | Yes | |
| expected_roas_uplift_pct | Yes | |
| connect_incentive_message | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral details beyond the annotations: two computational paths (Path A and B), default period, and that certain fields must be passed verbatim. Annotations already indicate readOnlyHint=true, which is consistent. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and informative, about five sentences, with the purpose front-loaded. Every sentence adds value. Slightly more conciseness could be achieved, but overall structure is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two paths, optional parameter, period customization, verbatim fields) and the presence of an output schema, the description covers key aspects: the two paths and their caveats, default behavior, and required verbatim pass-through. It is nearly complete, though it omits explicit mention of the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the period parameter well (default '30d' and override options) and notes site_id is optional for OAuth. However, it does not explicitly state what monthly_budget_jpy represents (the total budget to allocate), though implied by context. Additional detail would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a proposed monthly budget split across paid channels (meta/google/tiktok). It distinguishes itself from sibling tools (e.g., get_ai_traffic, get_breakdown) by focusing on budget allocation, and it differentiates two algorithmic paths based on ad spend connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (return a budget split) and explains two paths depending on ad spend connection. It also mentions site_id optionality for OAuth and default period. However, it does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!