Ask AI about your EC site's revenue by channel, RPS/AOV/CVR, search & AI traffic, budget split.
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.
Average 4.8/5 across 10 of 10 tools scored.
Each tool targets a distinct analytical dimension—overall KPIs, breakdowns, search queries, page trends, content actions, AI traffic, competitors, insights, budget, and site listing—with explicit cross-references to clarify boundaries. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case: get_ for retrieval, list_ for site listing, and suggest_ for recommendation. This predictability helps agents infer behavior from names.
With 10 tools, the server is well-scoped for revenue analytics, covering macro KPIs, detailed breakdowns, SEO, content, AI traffic, competitors, and budget planning without unnecessary bloat. Each tool serves a distinct purpose.
The tool set covers the full analytics workflow from site discovery and KPI summaries to drill-downs and recommendations. Minor gaps exist—such as product-level revenue or cohort analysis—but these can be inferred from page-level data, so agents can work around them.
get_ai_trafficAI assistant trafficAReturn 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true and openWorldHint=false, but the description adds substantial behavioral context: the bounce rate is always computed and reliability should be judged via sessions count, default limits are specified, site_id is optional under OAuth, and the scope is explicitly limited to 'clicked citations only.' No contradictions 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 dense but well-organized, front-loading the core purpose and then expanding into modes and parameters. It is longer than a simple one-liner, but every clause provides essential detail. Minor room for improvement in scannability (e.g., bullets), but it remains appropriately sized for a tool with two distinct modes.
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 modes, output schema, multiple parameters) and existing annotations, the description covers the key contextual aspects: mode meanings, default limits, OAuth site_id condition, and scope limitation. The output schema handles return-value detail, so the description does not need to. It is complete enough for effective selection and invocation, though it omits potential error handling or edge cases.
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 coverage, the description explains every parameter: mode with its two values and meanings, limit with mode-specific defaults, period with allowed formats and default, and site_id with its OAuth-dependent optionality. It adds defaults and constraints not present in the schema, fully compensating for the schema's lack of descriptions.
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: 'Return AI-assistant (ChatGPT/Claude/Perplexity/Gemini/Copilot) traffic for the given period.' It uses specific verbs ('Return') and resources ('AI-assistant traffic'), and distinguishes itself from siblings by focusing exclusively on AI traffic. It also explicitly notes it provides 'a view GA4/GSC cannot produce,' making its niche unmistakable.
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 when-to-use guidance for each mode: mode='referred' for landing pages with clicked AI traffic, and mode='gaps' for missed citation and under-monetization opportunities. It also contrasts with alternatives by stating GA4/GSC cannot produce this view. This satisfies the 'when/when-not/alternatives' criterion thoroughly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_breakdownRevenue breakdown by dimensionAConsolidated 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as safe, but the description adds substantial behavioral detail beyond that: bot_excluded_count semantics, Unattributed rows, model-dependent vs model-independent fields, GSC null handling, different denominators, and country 'Unknown' for unresolved IPs. This goes well beyond the annotation.
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 core purpose and every sentence adds specific detail, but it is written as one dense, sprawling block with many parentheticals and semicolons, making it harder to parse quickly. It is appropriately sized for a complex tool but could benefit from clearer structure.
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?
For a tool with 8 parameters, nested filters, and three distinct modes, the description covers output semantics, parameter interactions, edge cases, and caveats thoroughly. Since an output schema exists, the lack of explicit return-value listing is not a gap.
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 zero property descriptions, so the description carries the full burden and succeeds. It explains each parameter: dimension values and their output shapes, filter.channel drilling, limit defaults/max, period options, optional site_id, attribution_model values, and country/device scoping.
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 identifies the tool as a consolidated breakdown with three dimensions ('channel', 'page', 'session_attribute') and enumerates the returned metrics. It is specific about what it does, but it does not explicitly contrast it with sibling tools such as get_summary or get_page_trend, so it lacks sibling differentiation.
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 gives clear usage context: choose a dimension, pass filters only for channel, limit only for page, and use attribution_model to switch attribution methods. It does not explicitly state when this tool should be preferred over alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_competitor_keywordsCompetitor keywords (external SEO snapshot)AReturn 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though readOnlyHint annotation already indicates safety, the description adds substantial context: the tool never costs money, is summary-first and token-aware, explains that rank is a position where negative delta means improvement, and discloses that lost keywords are never dropped silently. This goes well beyond the annotation and clarifies behavior in edge cases like no completed research.
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 each sentence adds value: purpose, read-only guarantee, response format, rank semantics, lost keywords, edge case, parameter guidance, and sibling differentiation. It is information-dense with no fluff, though the single block of text could benefit from slight restructuring for scanability.
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 (5 parameters, response variations, edge cases), the description covers all necessary context: full response behavior, optional parameters, authentication nuance, and the no-research case. It even explains the `researched:false` response with guidance. The presence of an output schema doesn't reduce the need for this interpretive context, which is thoroughly provided.
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 explains every parameter in context: `sort` with default 'etv' and options, `limit` default 10 max 100, `domain`, `min_volume`, and `site_id` optional when OAuth-authenticated. It also explains the `truncated` block and `lost_keywords`, giving semantic meaning beyond raw schema 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 opens with a specific action and resource: 'Return the latest competitor SEO snapshot for the site (FD-041)' and details exactly what data is included (keywords, positions, search_volume, cpc, etv, rank changes). It explicitly distinguishes itself from sibling tools by saying 'This is the external competitor lens... for YOUR OWN search performance use get_keyword_performance, and for your content playbook use get_content_actions.'
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 gives clear usage direction: use it to see competitor rankings, pass `domain` to focus on one competitor, `min_volume` to filter. It explicitly warns that the tool cannot trigger research ('this tool never runs a research... it only reads what was already fetched') and provides an alternative ('must be triggered from the dashboard first'). It also names sibling tools as alternatives for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_content_actionsContent actions (classify pages + playbook)AReturn 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses data lag (1-2 days), window inclusivity semantics, inclusive date bounds, sorting rules within buckets, confidence caveats, truncation behavior, and non-obvious disclaimers (e.g., 'decaying' does not mean the page is failing overall). It also warns about 'geo_winning_suspect' and other caveats that require human verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with its core purpose and is exceptionally detailed, but it is very long. While nearly every sentence adds substantive guidance, the density approaches the limit of conciseness; a slight restructuring into bullet points would improve scannability without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (five buckets, sorting nuances, caveats, response structure, period behavior), the description is impressively complete. It covers bucket semantics, sort criteria, expected metrics, window comparison rules, caveat flags, and notes return fields like bucket_summary and truncated. The output schema existence further reduces the need to document return types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description carries full burden. It compensates thoroughly: explains all five bucket values, period options ('7d', '30d', '90d' or raw day count 2-365), inclusive date interpretation, limit default/max values, and site_id optionality with OAuth. This is far beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return a content playbook for the site: every content page classified into ONE of five action buckets' – a specific verb and resource. It explicitly addresses scope ('cross-page action snapshot') and distinguishes from sibling tools by naming get_page_trend and get_ai_traffic as alternatives for different needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to use this tool (cross-page prioritization, telling the user which page to grow) and explicitly names alternatives for one-page time series and AI-citation gaps. It also provides clear exclusions, e.g., 'NOT CVR' and the instruction to cross-check landing metrics before calling a bucket a problem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_keyword_performanceSearch keyword performanceAReturn 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnlyHint annotation: revenue estimation formula (search-organic RPS × clicks), period-over-period change semantics with null meaning new query, site_id optionality under OAuth, and fixed methodology for striking band. It even explains how to interpret the change metrics with an example. No contradictions 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 dense but every sentence carries substantive information. It is a single block without paragraph breaks, which makes it harder to scan, but it is not verbose or redundant. The front-loading of the main purpose is effective.
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?
With four parameters, an output schema, and annotations, the description covers all necessary context: default periods, limits, auth-related site_id, metric definitions, change semantics, and the 'Google-search only' scope. It leaves no obvious gaps for a complex tool.
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%, so the description bears the full burden for parameter semantics. It explains band values and their behaviors, limit defaults (100 for all, 10 for striking), period accepted formats, and site_id optionality. This fully compensates for the schema's lack of descriptions.
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 search-query performance from Google Search Console for a period, and distinguishes between the 'all' and 'striking' bands. It is specific about the verb and resource, but does not explicitly differentiate from sibling tools like get_ai_traffic or get_breakdown, so it stops short of a 5.
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 for when to use each band (e.g., 'striking' returns the SEO action list for queries near the top) and gives an example of the insight from comparing metric changes. However, it does not explicitly state when to use this tool over alternatives or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_page_trendPage search trend over timeAReturn 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 |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| basis | Yes | |
| period | Yes | |
| series | Yes | |
| site_id | Yes | |
| summary | Yes | |
| warning | No | |
| assumptions | Yes | |
| granularity | Yes | |
| limitations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=true; the description adds substantial behavioral context: avg_position is a rank (smaller better), negative delta means improvement, omitted buckets for pages not appearing in search, data lag of 1-2 days, granularity default behavior, and OAuth-dependent site_id optionality. This far exceeds the annotation baseline.
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?
Though ~150 words, the description is tightly structured: main function first, then parameter specs, then behavioral nuances, then sibling disambiguation. No redundant or filler sentences; every clause adds value, even the 'FD-040' reference hints at internal taxonomy without being misleading.
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 output schema exists, the description need not detail return fields, but it still mentions the series/summary shape and key fields. It covers all operational contexts: Google-search scope, default period, granularity override, OAuth behavior, and data gaps. No important usage aspect is left unaddressed.
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 explains every parameter in prose: page accepts normalized path or full URL, period defaults to '30d' with accepted values, granularity default and override rationale, and site_id optional under OAuth. This fully compensates for the missing schema descriptions.
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 opens with a specific verb+resource: 'Return how ONE page's Google Search performance changed over time' and explicitly positions it as the 'time-axis drill-down' relative to get_breakdown(dimension='page'). It also distinguishes from get_keyword_performance for query trends, making sibling differentiation crystal clear.
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 states exactly when to use this tool: 'Use this to verify whether SEO work on a page paid off (rank rose / clicks grew) or slipped.' It also gives explicit alternatives: 'for the cross-page snapshot use get_breakdown(dimension='page'), and for per-query (keyword) trends use get_keyword_performance.' No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_priority_insightsTop priority insightsAReturn 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 |
| Name | Required | Description |
|---|---|---|
| basis | Yes | |
| period | Yes | |
| site_id | Yes | |
| insights | Yes | |
| assumptions | Yes | |
| limitations | Yes | |
| rules_evaluated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=true, the description goes further: it reveals the tool is pre-computed, deterministic, and rule-based ('The priority judgment is fixed in code (not LLM-generated)'), and returns a variable number of results ('Returns fewer than 3 when fewer rules fire'). This manages expectations beyond the read-only flag.
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 but every sentence adds unique value: purpose, differentiation, behavioral traits, parameter semantics, and edge case behavior. It is organized into clear sentences, making it easy to scan while remaining thorough.
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?
The tool is complex (rule engine, multiple factors, output with severity/numbers/action). The description covers purpose, logic, output format, parameters, defaults, and edge cases. With an output schema present, the description doesn't need to specify exact structures, so it is complete for an agent to invoke it correctly.
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 compensates fully: it explains the site_id is 'OPTIONAL when OAuth-authenticated' and details the period values, including the default of 30 days, named presets, and integer range. This adds practical meaning that the schema alone doesn't convey.
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 opens with 'Return the top 3 prioritized, pre-computed DIAGNOSES...' which clearly states the action and output. It then explicitly contrasts with siblings by saying 'Unlike get_site_summary / get_kpi_summary / get_channel_breakdown (which return data), this applies a deterministic rule engine...' demonstrating a specific purpose distinct from related tools.
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 'Unlike' clause explains when not to use this tool (when raw data is needed) and when to use it ('what should I act on this week'). It also covers parameter usage with site_id optional under OAuth and default period, providing clear contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_summarySite KPI summaryAReturn 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavior beyond the readOnlyHint annotation: it explains period='today' compares against the same elapsed window yesterday, so 'previous' can read below yesterday's full-day total. It also details ROAS being null on Path A or when no ad spend, roas.previous/change being null when the prior window has no spend, and the mixed change format (percentage vs percentage-point delta) for different KPIs.
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 well-structured: the first sentence front-loads the full contents, followed by short paragraphs targeting engagement, parameter scoping, period special cases, and ROAS null semantics. Every sentence adds actionable detail, but the length could be slightly tightened without losing value; still, the complexity justifies the 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?
The description is exceptionally complete for the tool's complexity, covering edge cases (period='today', ROAS null, previous-window null, change deltas) and aligning with sibling tool definitions. Even though an output schema exists, the description explains return structure and semantic nuances, making it self-contained for an agent to correctly interpret and render data.
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 compensates by thoroughly explaining every parameter: country (ISO2, e.g., 'JP'), device enum, period (presets or raw 1-365 day count), and site_id (optional under OAuth). It also clarifies scoping behavior—country/device affect session-derived KPIs and trend but ROAS stays site-wide—and explains the period default and special 'today' handling.
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 the full headline summary for a site and period in ONE call, enumerating the 5 KPIs, engagement KPIs, trend, ad-spend availability, and Path A/B recommendation. This specific verb+resource+scope distinguishes it from sibling tools, especially by explicitly referencing consistency with get_channel_breakdown and positioning it as the dashboard's main 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?
The description explicitly says to 'Call this first when a user asks how is my site doing?' and notes avg_duration/bounce_rate are useful for sites with no revenue yet (engagement view). It aligns ad-spend semantics with get_channel_breakdown, providing clear context on when to use this summary versus channel-level tools; however, it does not explicitly state exclusions or alternatives beyond implied breakdown comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sitesList available sitesAList 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 | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| my_sites | Yes | |
| demo_sites | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, the description discloses key behaviors: returns two groups, my_sites is empty when not signed in, demo_sites are fictional sample data, and OAuth context. This adds substantial value over annotations and gives the agent full understanding of the tool's runtime behavior.
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 but every sentence carries distinct, useful information: the grouping logic, signed-in vs. signed-out behavior, demo data caveat, and default-site guidance. It is front-loaded with the core purpose and remains appropriately sized for the complexity covered.
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?
Despite having no parameters and a simple schema, the tool's behavior in different auth states is fully explained. The output schema exists so return-value details are not required. The description covers all edge cases and context needed for an agent to use the tool correctly.
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 tool has zero parameters, so the input schema is trivially fully covered. The description adds indirect parameter guidance for other tools (defaulting site_id to primary), but for this tool itself, no parameter explanation is needed. Baseline 4 for zero-parameter tools is appropriate.
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 opens with a specific verb+resource ('List the sites this caller can analyze') and immediately distinguishes the tool from analytics siblings by clarifying it returns two groups (my_sites and demo_sites). This clearly separates it from the other tools that analyze specific site metrics.
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 when-to-use guidance: prefer my_sites when signed in, use demo_sites when not signed in, and default to is_primary=true when site_id is omitted. It also instructs to inform users when demo data is used, covering both usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_budget_allocationSuggest budget allocationAReturn 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=true, the description adds extensive behavioral context: the two computation paths, the ROAS definition link to dashboard vs platform-reported conversion_value, the saturation caveat, and the hardcoded honest axis with verbatim pass-through requirements. This goes far beyond the annotation.
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 technical, but every sentence carries useful information about paths, caveats, parameters, or output handling. It is front-loaded with the core purpose. Some internal references (e.g., 'FD-030 A-1', 'W17+') may be jargon, but they are relevant for precision.
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 output schema exists and the three input parameters are fully explained through the description and schema, the tool is thoroughly specified. It covers auth context, period overrides, computation formulas, limitations, and required pass-through fields, leaving no major gaps for an agent to invoke it correctly.
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 schema provides bare property definitions, but the description adds essential semantic context: site_id becomes optional when OAuth-authenticated, period accepts named values or a raw day count to override the 30-day default, and monthly_budget_jpy is the budget being split. This meaningfully enhances understanding beyond 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 starts with a specific verb+resource: 'Return a proposed monthly budget split across paid ad channels', which clearly states the tool's function. It also distinguishes itself from the sibling get_* tools by focusing on budget suggestion rather than data retrieval.
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 detailed guidance on when to use Path A vs Path B based on ad spend connectivity, explains the optional site_id under OAuth, and shows how to override the default period. It does not explicitly name alternative sibling tools, but the distinct purpose and path logic give strong contextual usage cues.
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.
No comments yet. Be the first to start the discussion!
