Ask AI about your EC site's revenue by channel, RPS/AOV/CVR, search & AI traffic, budget split.
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 (last_cited_at is JST ISO8601 with a +09:00 offset — the same basis as the dashboard, so dates line up when compared) (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?
The description discloses all relevant behavioral traits: return fields (sessions, bounce rate with reliability caveat, revenue, last_cited_at with timezone), default limits per mode, scope (clicked citations only), and that methodology is fixed in code. The readOnlyHint annotation is consistent with the read-only nature described. 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 primary purpose and then details each mode. It is dense but efficient; every sentence adds value. A slight reduction in length or use of bullet points could improve scannability, but it remains well-structured and avoids 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?
Given the tool's complexity (two modes, four parameters, output schema present), the description covers all necessary aspects: input parameters, return values for each mode, methodology notes, timezone info, and scope. The presence of an output schema does not reduce the need for explanation, and the description exceeds expectations.
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 (enum values and defaults), limit (defaults per mode), period (string shortcuts and integer range), and site_id (optional when OAuth). It also explains the format of the last_cited_at field in the output, aiding understanding of the data.
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, with two distinct modes ('referred' and 'gaps') that are each explained in detail. It lists the specific AI sources (ChatGPT, Claude, etc.) and contrasts with GA4/GSC, making the purpose unambiguous and distinguished from general analytics 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 description explains when to use each mode: 'referred' for listing landing pages with AI traffic and 'gaps' for identifying missed opportunities. It also notes that the view cannot be produced by GA4/GSC, implying it's the only tool for this purpose. However, it does not explicitly compare to sibling tools like get_breakdown or get_keyword_performance, leaving some ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consolidated breakdown tool. Pick dimension: 'channel' returns per-channel sessions/revenue/RPS plus engagement (visitors, avg dwell seconds, bounce rate) and bot_excluded_count (bot sessions removed from human metrics; a channel with sessions=0 but bot_excluded_count>0 is bot-only traffic, kept so it is not mistaken for 'no traffic') and — when ad spend is connected (Path B) — spend/ROAS/saturation; plus an 'Unattributed' row (is_unattributed=true) for purchase revenue not tied to any channel, with a revenue_breakdown summary (total_event_jpy/attributed_jpy/unattributed_jpy); pass attribution_model ('last_touch' default / 'first_touch' / 'linear' / 'time_decay') to switch how purchase revenue and orders are attributed across channels — same models as the dashboard's attribution selector; revenue_jpy/rps_jpy/orders/aov_jpy/cvr change, while sessions/engagement/bot/spend/ROAS are model-independent, so compare models to see e.g. how much an awareness channel gains under first_touch vs last_touch. each channel row also carries orders (purchase orders counted by our own tracker), aov_jpy and cvr derived from it — withheld as null below 10 orders, and always null on ad-platform / Unattributed rows; do NOT divide revenue_jpy by conversions to rebuild AOV, conversions is the ad platform's self-reported count, a different denominator. pass filter.channel to drill into that channel's campaigns (utm_campaign) with RPS/AOV/CVR — the value must be a channel name exactly as this tool returns it, case included (e.g. 'Google Ads', 'Meta', 'Criteo', 'Google検索'), since the match is exact and a lowercase slug returns nothing. 'page' returns per-page pageviews/unique visitors/avg time/bounce plus the page title (what the page IS, so a row reads as an article name rather than a slug; null for pages with no visit since 2026-08-21 — it does not backfill) ranked by pageviews (limit default 20, max 200; query strings stripped, bots excluded; each row also carries GSC Google-search impressions/clicks/ctr/avg_position merged by normalized path — null when the page has no GSC row, and a DIFFERENT denominator from pageviews, see notes). 'session_attribute' returns the device / time-of-day (4h JST) / day-of-week (ISO) / new-vs-returning (with AOV) / country (top-15 by sessions + 'Other', ISO2 code, share_pct; from first-party session geo, 'Unknown' when IP unresolved) breakdowns in one call. site_id is OPTIONAL when OAuth-authenticated. Default period is the last 30 days; pass period='today'/'7d'/'90d' or a raw day count (1-365). filter only applies to dimension='channel'; limit only applies to dimension='page'. Pass optional country (ISO2, e.g. 'JP') and/or device ('mobile'/'desktop'/'tablet') to scope session-derived metrics across any dimension (omit = all). For dimension='channel' you can also pass visitor_type ('new'/'returning') to split the channel table by first-time vs returning visits — the split uses the DATE-based rule (no visit by the same visitor on an earlier JST day = new), the same rule the dashboard's KPI card uses, NOT the tracker's stored is_new_visitor flag; under it engagement fields, bot counts, ad-platform aggregate rows, Unattributed, and revenue_breakdown are omitted because their sources have no visitor_type dimension. Session rows keep ad_platform mapping metadata. Combining visitor_type with filter.channel is rejected with InvalidParams because campaign drill-down has no visitor-type axis. dimension='page' rows include pageviews_change (period-over-period % vs the previous equal-length window, null = new page).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| device | No | ||
| filter | No | ||
| period | No | 30d | |
| country | No | ||
| site_id | No | ||
| dimension | Yes | ||
| visitor_type | No | ||
| 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 | |
| presentation_hints | Yes | |
| session_attributes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint and openWorldHint annotations. It discloses edge cases and internal behavior: bot_excluded_count semantics, null handling for orders below 10 and for ad-platform/Unattributed rows, the page title backfill limitation ('null for pages with no visit since 2026-08-21 — it does not backfill'), GSC denominator differences, the date-based visitor_type rule vs tracker flag, rejection behavior for invalid combinations, and the caution against dividing by `conversions`. It even explains the attribution model's effect on specific metrics. This is exhaustive and prevents misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, very dense paragraph (over 2000 characters) that mixes multiple topics with semicolons, parentheses, and clauses. While every sentence carries substantive information, the lack of visual structure (headers, bullets, or clear separation by dimension) makes it harder to scan. It is not redundant, but it is not concise in the sense of being quickly parseable. Given the high complexity, the length is justified, but the structure could be improved to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, nested objects, 4 enums, and an output schema, the description covers everything an agent needs to call it correctly: parameter semantics, defaults, restrictions, edge cases, error behavior, and common pitfalls. It even explains what to do when comparing attribution models. There is no apparent gap; the description is a complete usage manual. The presence of an output schema further reduces the need to describe return values, but the description already covers key return fields (e.g., revenue_breakdown, pageviews_change).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% — the schema only lists types/enums/defaults with no descriptions. The description compensates fully by explaining every parameter's meaning and behavior: dimension options, period defaults and allowed values, filter structure and exact-match requirement, limit scope, site_id optionality, country/device scoping, visitor_type split rule, and attribution_model semantics with examples. It also clarifies how parameters interact (e.g., filter+visitor_type rejection). This is a model of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Consolidated breakdown tool' and then enumerates exactly what each dimension returns ('channel' returns per-channel sessions/revenue/RPS plus engagement..., 'page' returns per-page pageviews/unique visitors/avg time/bounce..., 'session_attribute' returns the device / time-of-day / day-of-week...'). It clearly states the resource (breakdowns) and the verb (get). It distinguishes itself from siblings by covering three distinct dimensions in one tool, while siblings like get_page_trend or get_ai_traffic are more specialized. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when and how to use the tool: it explains which parameters apply to which dimensions ('filter only applies to dimension='channel'; limit only applies to dimension='page''), when site_id is optional, how to combine country/device/visitor_type, and when combinations are rejected ('Combining visitor_type with filter.channel is rejected with InvalidParams'). It doesn't explicitly name alternatives among siblings, but it gives clear context on scope and restrictions, leaving little ambiguity about when this tool is appropriate. Lacks explicit 'use this instead of X' statements, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the latest competitor SEO snapshot for the site (FD-041): which keywords each tracked competitor DOMAIN ranks for on Google (Japan/ja), at what position, with monthly search_volume, cpc and etv (estimated monthly traffic — a visit estimate, not a monetary value), plus how each rank moved vs the previous snapshot. READ-ONLY — this tool never runs a research (that costs money and is triggered separately from the dashboard, the competitor-research Edge Function); it only reads what was already fetched. The response is summary-first (token-aware): each domain carries a constant-size summary (total_keywords, total_etv, volume_bands and rank_bands histograms, and vs_previous new/lost/improved/declined/same counts) that always reflects the FULL keyword set, while keywords returns only the top rows ranked by sort (etv default | volume | rank; default limit 10 per domain, max 100) with a truncated block (shown/matching_total/lost_total). rank is a POSITION: smaller is better, so a NEGATIVE rank_delta means the competitor's ranking IMPROVED (change ∈ new/improved/declined/same/unknown). Keywords the competitor ranked for before but lost are disclosed in lost_keywords (top 10 by previous etv), never dropped silently. Pass domain to focus one competitor, min_volume to drop low-volume keywords. When the site has NO completed research yet the response is { researched:false } with a guidance string explaining a research must be triggered from the dashboard first — this tool cannot start one. site_id is OPTIONAL when OAuth-authenticated. This is the external competitor lens (third-party SERP data); for YOUR OWN search performance use get_keyword_performance, and for your content playbook use get_content_actions.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| domain | No | ||
| site_id | No | ||
| min_volume | No |
| 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.
Return a content 'playbook' for the site: every content page classified into ONE of five action buckets over a weekly-style window comparison (current window vs the immediately preceding window of equal length), ranked by search-opportunity × session gain so you can tell the user which page to GROW next and what to do: within the 'striking' bucket rows are ordered by expected_sessions_gain DESC (the band-CTR headroom that is the actionable lever there), while the other buckets keep real landing revenue DESC (largest revenue at stake first). This surfaces search intent to add sessions (grow the traffic denominator), NOT CVR — a page already winning on sessions/revenue but with zero clicks still shows up. Buckets: 'decaying' (search clicks actually fell, OR the page had real traffic (previous clicks ≥3) and its rank slid ≥2 positions from within the click zone while clicks did NOT grow → refresh/rewrite; a rank slide alone with growing/negligible clicks is NOT decay — search clicks are the primary signal, position only a leading indicator), 'striking' (has striking-distance queries at positions 4-20 with click upside but clicks still low → push those queries up; top 3 listed in striking_queries), 'rising' (clicks grew significantly → produce more of this, strengthen CTA), 'dormant' (has impressions but ~0 clicks and its main query is far below the click zone → big rewrite or consolidate; zero-pageview pure-rank pages surface here), 'stable' (none of the above → watch). Each page also carries current/previous clicks·impressions·avg_position, is_new, landing sessions/engaged/revenue_jpy, AI-referred sessions/revenue/sources, expected_sessions_gain (the window's expected incremental sessions from striking-band queries — a search click is ~1 session, so it is NOT re-converted via CTR; normalize to a monthly figure with the window length), and expected_revenue_gain (expected_sessions_gain × page RPS, returned ONLY when revenue>0 and sessions>=5 — display-only projection, never a sort key). The deterministic action mapping and all (provisional) thresholds come back in criteria; the model does the narrative interpretation (mcp-first). Rows with confidence='low' carry caveats — 'geo_winning_suspect' (AI Overview/citations likely substitute the click: a GEO win, don't break the page; cross-check get_ai_traffic), 'zero_click_suspect' (SERP-feature occupation or intent-mismatch/polysemous query: verify the live SERP first), 'ai_cited' (decaying but the AI citation is alive) — verify before acting on low-confidence rows; definitions in criteria.caveat_flags. The response is summary-first (token-aware): bucket_summary always holds the FULL pre-limit distribution (per-bucket count/revenue/clicks) plus total_pages, while pages returns only the top rows in priority order (default limit 15, max 200); pass bucket='striking' etc. to drill into one bucket, and check truncated — when present it tells how many rows were cut and how to fetch them. GSC-driven and Google-search only; data lags 1-2 days so the current window's right edge sits a few days back. When narrating a bucket to the user, scope it to Google search — say 'search traffic to this page is declining', NOT 'this page is declining'; the classification is a search-trend diagnosis, not overall page health, so a page labeled 'decaying' can be thriving on Direct/social/AI. Before calling a negative bucket (decaying/dormant) a problem, cross-check the row's landing sessions/revenue_jpy and ai_sessions. site_id is OPTIONAL when OAuth-authenticated. Default window is the last 7 days vs the prior 7; pass period='30d'/'90d' or a raw day count (2-365). Window date bounds are INCLUSIVE on both ends, so period=Nd actually spans N+1 calendar dates (the real range is in window); both windows share the same length, so the comparison stays symmetric. This is the cross-page action snapshot; for one page's time series use get_page_trend, and for AI-citation gaps use get_ai_traffic(mode='gaps').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| bucket | No | ||
| period | No | 7d | |
| site_id | No |
| 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.
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 |
| 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.
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 |
| 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.
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_summary / get_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 | |
| presentation_hints | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, but the description adds substantial behavioral detail: the rule engine is deterministic and not LLM-generated, the output includes severity/number/action, and it may return fewer than 3 results. 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 efficiently packed with every sentence adding value: purpose, differentiation, rule engine, output structure, parameter semantics, and edge-case behavior. It is front-loaded with the core purpose and avoids redundancy.
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 an output schema present (providing return structure), the description covers all necessary aspects: what, when, how, parameter behavior, and limitations. It is complete for an agent to correctly select and invoke the 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 coverage is 0%, but the description compensates fully: it explains that site_id is optional with OAuth, and that period accepts specific string values or a raw day count 1-365 with a default of 30d. This adds meaning far beyond the raw 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 states the exact action ('Return the top 3 prioritized, pre-computed DIAGNOSES') and the resource (site insights). It also distinguishes itself from siblings by explicitly contrasting with get_summary/get_breakdown and describing the deterministic rule engine, making the tool's unique purpose 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?
It provides clear when-to-use context ('what should I act on this week'), explicitly names alternatives (get_summary / get_breakdown) and explains why they differ. It also details the optional site_id and period formats, leaving no ambiguity about invocation conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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). scroll_depth is the average scroll depth (%), taken per session as its deepest point then averaged; its change is a percentage-point delta. IMPORTANT: its denominator differs from avg_duration/bounce_rate — depth only covers sessions whose exit beacon landed, and sessions without one are excluded rather than counted as 0. scroll_depth is null when the window holds no depth signal at all (0% would read as 'read shallowly' when the truth is 'not measured'); depth has only been collected since 2026-06-15, so longer windows are partial. 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 | |
| presentation_hints | 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?
Despite readOnlyHint=true being declared, the description adds substantial behavioral nuance: the different denominator for scroll_depth, null handling when no depth signal exists, ROAS null on Path A, and the expected lower previous value for period='today'. These are exactly the kind of edge cases that prevent misuse and are not derivable from annotations alone.
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 every sentence adds necessary detail for correct invocation, given the tool's complexity. It front-loads the primary return payload, then progressively covers edge cases and parameter semantics in a logical order. No redundant or filler sentences were found.
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 covers all operational aspects: what is returned, how each metric is computed, null/edge-case behavior, parameter scoping, period semantics, and cross-tool consistency. With an output schema present, it appropriately focuses on behavior rather than return structure, and nothing an agent needs to call it correctly is missing.
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 carries the full burden for all four parameters. It explains the meaning and valid values for country (ISO2), device (enum with examples), period (default 30d, accepted strings and integer range), and site_id (optional with OAuth fallback). This goes well beyond the schema's structural 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 precise statement of what the tool returns — the full headline summary for a site and period — and enumerates the exact KPIs, trends, and ad-spend fields. It clearly distinguishes itself from siblings by naming specific outputs (e.g., ROAS definition, engagement metrics) that other tools like get_breakdown or get_page_trend would not provide in one call.
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?
Explicitly instructs to call this tool first when a user asks 'how is my site doing?', giving a clear trigger. It also explains when the tool's behavior changes (e.g., period='today' comparison, ROAS null cases) and references get_channel_breakdown for consistency. However, it does not explicitly contrast with alternatives like 'use get_breakdown for per-channel details', so the when-not-to-use guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
| 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.
Return a proposed monthly budget split across paid ad channels (Google Ads / Meta / TikTok Ads / Yahoo! Ads / LINE Ads etc.). site_id is OPTIONAL when the request is OAuth-authenticated. Path B (ad spend connected — any channel with spend>0 in the period): weight = ROAS × (1 − saturation) where ROAS is RS-measured revenue ÷ spend (FD-030 A-1, same as the dashboard — NOT platform-reported conversion_value). saturation は RS 自身では推定せず、広告データとして供給された場合のみ使用する (推定エンジンは W17+)。値が無いチャネルは ROAS のみで加重し効率投下上限をかけない — limitations に明記する。⚠ 配分候補は広告プラットフォーム単位 (Meta / Google Ads …) で、Instagram と Facebook のようにセッション側の粒度が細かいチャネルは所属プラットフォームへ畳んで扱う (FD-055)。 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?
The description discloses internal weighting logic (ROAS × saturation), handling of saturation (only used if supplied), channel aggregation rules, and the requirement to pass certain fields verbatim. Annotations (readOnlyHint=true) are consistent with the read-only proposal nature. No contradictions, but the technical depth could be simplified for broader agent understanding.
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 but not concise. It mixes purpose, algorithmic formulas, constraints, and LLM instructions in a single block. Japanese text and technical references (FD-030, FD-055) add verbosity. Front-loading the purpose is good, but overall structure could be cleaner.
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, the description covers default behavior, overrides, two usage paths, and channel aggregation. It references an output schema (not shown) and explains key constraints. Missing explicit return format details, but the output schema likely covers that. Sibling tools are all data-retrieval, so this recommendation tool stands out well.
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 must add meaning. It clarifies that site_id is optional for OAuth requests, explains period options beyond the schema const values, and notes the default. However, the 'monthly_budget_jpy' parameter receives no additional context beyond its schema definition, leaving a gap.
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 'Return a proposed monthly budget split across paid ad channels', specifying the exact outcome. It distinguishes itself from sibling tools like get_breakdown or get_summary by focusing on budget allocation suggestion.
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 context for use, explaining the two paths (Path A and Path B) based on ad spend connectivity, period overrides, and site_id optionality. However, it does not explicitly state when NOT to use the tool relative to siblings, and the algorithmic details may obscure the core usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Ask questions across Shopify, Klaviyo, GA4 and 20+ e-commerce sources in plain English.
Ask AI about your ads — query Meta, TikTok, and Google Ads performance in natural language.
Access Google & Meta Ads data via AI. Analyse campaign performance in seconds.
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: AI traffic analysis, multi-dimensional breakdown, competitor SEO snapshot, content playbook, keyword performance, page trend, priority insights, summary, site listing, and budget allocation. Overlapping domains like search performance are clearly separated by focus (query-level vs page-level vs competitor).
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_ai_traffic, get_breakdown, list_sites). The verbs are uniformly descriptive ('get', 'list', 'suggest'), and the naming style is predictable and clean.
With 10 tools, the server is well-scoped for a comprehensive analytics platform. Each tool covers a critical area (summary, traffic sources, breakdowns, search performance, competitor analysis, content actions, budget allocation) without unnecessary bloat.
The tool surface covers all major aspects of revenue-first e-commerce analytics: overall KPIs, AI traffic, channel/page/session breakdowns, search keyword and content performance, competitor insights, trend analysis, priority diagnoses, and budget recommendations. No obvious gaps for the stated purpose.
