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
9 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_content_actionsARead-onlyInspect
Return a content 'playbook' for the site (FD-044): 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 REAL landing revenue so you can tell the user which page to fix next and what to do. Buckets: 'decaying' (clicks fell hard OR rank slid ≥2 positions from within the click zone → refresh/rewrite), '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, and AI-referred sessions/revenue/sources. The deterministic action mapping and all (provisional) thresholds come back in criteria; the model does the narrative interpretation (mcp-first). GSC-driven and Google-search only; data lags 1-2 days so the current window's right edge sits a few days back. 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). 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 | ||
| 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 | |
| assumptions | Yes | |
| limitations | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context: data lags 1-2 days, window comparison, optional site_id when OAuth-authenticated, and detailed action bucket definitions. It does not contradict 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 quite lengthy (multiple paragraphs) and could be more concise. While each sentence adds value, the overall verbosity reduces clarity. However, it is front-loaded with the main purpose.
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 (five buckets, multiple metrics, data lags, output schema), the description covers all necessary aspects: thresholds, site_id optionality, window defaults, and references the criteria object. The presence of an output schema means return format doesn't need explanation, so completeness is high.
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 description coverage is 0%, but the description adds meaning for period (default 7d, options including raw day count 2-365) and site_id (optional when OAuth-authenticated). Limit is not explained but schema provides min/max. This compensates well for the lack of parameter descriptions in the 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 a content playbook classifying pages into five action buckets, ranked by revenue, and tells which page to fix and what to do. It distinguishes from siblings by explicitly naming get_page_trend and get_ai_traffic, so the purpose is specific and unique.
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 says when to use this tool vs alternatives: 'for one page's time series use get_page_trend, and for AI-citation gaps use get_ai_traffic(mode='gaps')'. It also implies it's for cross-page snapshots, providing clear context for tool selection.
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 is a separate last-7d recency signal and may read 'A' even when the period holds spend data. kpis.roas is the SITE-WIDE ROAS (total ad conversion value ÷ total ad spend over the period — same definition as get_breakdown's per-channel ROAS, the spend-weighted aggregate) with value/previous/change; 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.
| 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_last_7d | 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 channels (meta/google/tiktok). site_id is OPTIONAL when the request is OAuth-authenticated. Path B (ad spend connected): precise weight = ROAS × (1 − saturation) with expected ROAS uplift. 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!