Ask AI about your EC site's revenue by channel, RPS/AOV/CVR, search & AI traffic, budget split.
Scored across 10 tools
Each tool targets a distinct analytical lens: KPIs (get_summary), drill-downs (get_breakdown), AI traffic (get_ai_traffic), search queries (get_keyword_performance), content actions (get_content_actions), competitor data (get_competitor_keywords), page trends (get_page_trend), diagnoses (get_priority_insights), budget (suggest_budget_allocation), and site discovery (list_sites). Even where surfaces could overlap (e.g. keyword vs content vs page), the descriptions explicitly cross-reference each other and define their boundaries (GSC-only, Google-search-only, per-page vs per-query), eliminating misselection risk.
Nine of ten tools follow a clean get_<descriptive-noun> pattern (get_summary, get_keyword_performance, get_page_trend, etc.), creating a predictable read-oriented analytics verb. list_sites and suggest_budget_allocation use different verbs, but they are semantically standard for listing and recommendation operations and do not feel out of place. Minor, defensible deviation from an otherwise consistent convention.
Ten tools is squarely within the ideal 3-15 range for an analytics server. Each tool earns its place by covering a distinct analytical axis (KPIs, breakdowns, SEO keywords, content strategy, AI traffic, competitors, budget, insights, page trends, site access), and the count reflects the breadth of a revenue-analytics domain without padding or redundancy.
As a read-only analytics server, the surface is remarkably thorough: headline KPIs, multi-dimensional breakdowns, search query performance, per-page time series, content action playbooks, AI traffic gaps, competitor snapshots, prioritized diagnoses, and budget allocation are all covered, with clear cross-referencing between layers. Minor gaps exist—no campaign-level revenue detail outside the breakdown drill-down, no session-level export, and nothing for annotation/commentary—but these are edge cases agents can work around and do not create dead ends for the stated analytics purpose.
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 [ad-platform rows, is_ad_platform=true, are entirely model-independent, revenue_jpy and rps_jpy included — they are the spend-basis view, so on them revenue_jpy ÷ spend_jpy always equals roas, up to the rounding of roas to 2 decimals; under a non-default model their revenue_jpy/rps_jpy keep the database_statement_time_window boundary shown for roas rather than the reference_timestamp_window that presentation_hints lists for rows[*].revenue_jpy], 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 | |
| data_freshness | Yes | |
| previous_period | No | |
| total_pageviews | No | |
| attribution_model | No | |
| revenue_breakdown | No | |
| presentation_hints | Yes | |
| session_attributes | No | |
| period_boundary_definitions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnlyHint/openWorldHint annotations, disclosing subtle behaviors: bot_excluded_count semantics, the Unattributed row, ROAS rounding to 2 decimals, the database_statement_time_window vs reference_timestamp_window boundary, AOV/CVR nulled below 10 orders, case-sensitive exact channel matching, the DATE-based visitor_type rule, InvalidParams rejection for visitor_type+filter.channel, and non-backfilled titles. This is exemplary behavioral disclosure.
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?
Every sentence earns its place — there is no fluff — and the length is defensible given 9 parameters and 3 dimensions. However, the entire description is one dense, deeply nested wall of text with parentheticals inside parentheticals, which undermines reliable parsing; per-dimension or per-parameter structure would make the same information materially more usable.
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 an output schema exists, the description correctly focuses on call semantics rather than return shape, and it covers defaults, constraints, parameter interactions, edge cases, and rejection conditions comprehensively. The closed-world annotation (openWorldHint=false) is well-served: an agent has everything needed to invoke this tool correctly across all three dimensions.
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 carries the full burden for all 9 parameters — and it succeeds. Every parameter gets meaningful semantics: dimension values are each explained, attribution_model lists all four options with default, filter.channel gets exact-match/case rules, limit gets default 20/max 200, visitor_type gets the split rule and its exclusions, and site_id gets authentication context. No parameter is left semantically bare.
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?
Opens with 'Consolidated breakdown tool' and immediately enumerates the three dimensions ('channel', 'page', 'session_attribute') with what each returns, giving a specific verb+resource that matches the title 'Revenue breakdown by dimension'. The consolidated, multi-dimension scope clearly differentiates it from narrower siblings like get_keyword_performance or get_page_trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive internal routing: which dimension to pick, that filter only applies to dimension='channel', limit only to 'page', and which metrics are model-dependent vs model-independent. However, it never names sibling tools or states when an agent should prefer get_page_trend or get_keyword_performance instead, so external alternatives are left to inference.
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). period and previous_period describe the KPI engine's current and previous windows; each returned insight carries source_boundaries because channel, ad-spend, and AI signals can use different source windows. 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 | |
| data_freshness | Yes | |
| previous_period | Yes | |
| rules_evaluated | Yes | |
| presentation_hints | Yes | |
| period_boundary_definitions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds substantial behavioral detail beyond that: the judgment is deterministic and fixed in code, it returns fewer than 3 when fewer rules fire with no padding, and insights carry source_boundaries because signal windows can differ. There is no contradiction with the 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?
Though long, every sentence earns its place. The core purpose is front-loaded, sibling differentiation comes immediately after, and the remaining sentences compactly cover output semantics, period behavior, and source windows without 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?
For a complex insights tool, the description is nearly complete: it covers return shape, severity, recommended action, no-padding behavior, period semantics, and source boundaries. The main gap is the exact handling of site_id across authentication modes; otherwise, an agent has enough 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 description coverage is 0%, so the description must carry parameter meaning. It does: period presets ('today'/'7d'/'30d'/'90d'), raw day count 1-365, default 30 days, and site_id optionality under OAuth. It loses a point for a slight ambiguity around whether site_id is required when not OAuth-authenticated, and for mentioning previous_period without clarifying it is not a directly settable input.
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 and resource: 'Return the top 3 prioritized, pre-computed DIAGNOSES... ranked by revenue impact.' It also explicitly contrasts with get_summary / get_breakdown, which helps an agent distinguish this from its main data-returning siblings.
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 frames the tool as 'what should I act on this week', directly stating the decision-oriented use case. It also gives an explicit when-not: 'Unlike get_summary / get_breakdown (which return data)', this applies a rule engine and returns ranked findings, so the agent can route to the right sibling.
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. EXCEPTION: kpis.roas.previous uses the full prior JST calendar day because spend is daily-grained; previous_period.source_boundaries and period_boundary_definitions disclose that different window. 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; 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 | |
| data_freshness | 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 | |
| period_boundary_definitions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=false annotations already covering safety and closed-world semantics, the description adds exceptional behavioral context: scroll_depth's different denominator and null-when-unmeasured semantics, change as percentage vs percentage-point delta, the period='today' same-elapsed-window comparison, ROAS null on Path A / zero-spend periods, and previous/change null when the prior window has no spend. It even discloses data-coverage caveats ('depth has only been collected since 2026-06-15').
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 the tool is genuinely complex with many KPIs, edge cases, and null semantics that need explanation. It is front-loaded with the core purpose, then layers details sensibly. Minor redundancy exists: Path A/B definitions are restated in both the ad-spend context paragraph and the ROAS paragraph, and the parenthetical '前期比' is an odd inclusion. Every sentence mostly earns its place.
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 high-complexity tool, the description is remarkably complete: return payload, param semantics, defaults, auth behavior, comparison-window definitions, null-handling rules, data-coverage caveats, and consistency with sibling tools are all covered. An output schema exists, so the description correctly focuses on meaning and edge cases rather than restating return structure. Nothing needed to invoke this tool 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?
Schema description coverage is 0%, so the description carries the full burden and delivers: country is explained as ISO2 with the example 'JP' and scoping semantics, device is mapped to the enum values with segmentation behavior, period is fully documented (defaults to last 30 days, valid values 'today'/'7d'/'90d'/1-365), and site_id's OAuth-dependent optionality with primary-site fallback is spelled out. It also clarifies that ROAS ignores 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 opening line 'Return the full headline summary for a site and period in ONE call' states a specific verb and resource, then enumerates the exact payload (5 KPIs, 2 engagement KPIs, trend, ad-spend context, Path recommendation). The 'ONE call' framing plus 'This is what the dashboard's KPI cards + revenue-trend chart show' distinguishes it from the more granular sibling tools like get_breakdown and get_page_trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this first when a user asks "how is my site doing?"', giving clear entry-point guidance. It also notes definitional consistency with get_channel_breakdown and get_breakdown, which signals when results can be cross-referenced. However, it never names an alternative tool or states a when-not-to-use condition, leaving some routing to inference.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_breakdown14 fields changedOutput schema / properties / data_freshnessAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bot_classification_delay_definitions": {
+ "additionalProperties": false,
+ "properties": {
+ "burst_cluster_fallback": {
+ "type": "string"
+ },
+ "burst_cluster_primary": {
+ "type": "string"
+ },
+ "single_page_zero_dwell": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "burst_cluster_primary",
+ "burst_cluster_fallback",
+ "single_page_zero_dwell"
+ ],
+ "type": "object"
+ },
+ "bot_classification_delay_minutes_max_by_rule": {
+ "additionalProperties": false,
+ "properties": {
+ "burst_cluster_fallback": {
+ "const": 480,
+ "type": "number"
+ },
+ "burst_cluster_primary": {
+ "const": 20,
+ "type": "number"
+ },
+ "single_page_zero_dwell": {
+ "const": 480,
+ "type": "number"
+ }
+ },
+ "required": [
+ "burst_cluster_primary",
+ "burst_cluster_fallback",
+ "single_page_zero_dwell"
+ ],
+ "type": "object"
+ },
+ "delay_bounds_assume_scheduled_jobs_operational": {
+ "const": true,
+ "type": "boolean"
+ },
+ "generated_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "may_change_because": {
+ "items": {
+ "enum": [
+ "live_ingestion",
+ "open_window",
+ "moving_window",
+ "delayed_bot_classification"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "provisional": {
+ "const": true,
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "generated_at",
+ "provisional",
+ "may_change_because",
+ "bot_classification_delay_minutes_max_by_rule",
+ "bot_classification_delay_definitions",
+ "delay_bounds_assume_scheduled_jobs_operational"
+ ],
+ "type": "object"
+}Output schema / properties / period / properties / calendar_dates_touchedAdded value: +{
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / period / properties / duration_hoursAdded value: +{
+ "type": "number"
+}Output schema / properties / period / properties / reference_boundsAdded value: +{
+ "const": "start_inclusive_end_exclusive",
+ "type": "string"
+}Output schema / properties / period / properties / reference_end_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / period / properties / reference_start_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / period / properties / source_alignmentAdded value: +{
+ "enum": [
+ "exact",
+ "mixed"
+ ],
+ "type": "string"
+}Output schema / properties / period / properties / source_boundariesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "applies_to": {
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "boundary": {
+ "enum": [
+ "reference_timestamp_window",
+ "database_statement_time_window",
+ "jst_calendar_dates_from_reference_start",
+ "jst_calendar_dates_from_database_window_start",
+ "jst_calendar_dates_inclusive",
+ "account_registry_not_period_scoped",
+ "derived_previous_daily_window",
+ "derived_from_current_and_previous",
+ "defined_per_output_item"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "applies_to",
+ "boundary"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / period / properties / timezoneAdded value: +{
+ "const": "Asia/Tokyo",
+ "type": "string"
+}Output schema / properties / period / properties / window_typeAdded value: +{
+ "enum": [
+ "rolling",
+ "calendar_to_date",
+ "comparison"
+ ],
+ "type": "string"
+}Output schema / properties / period / requiredPrevious value: -[
- "start",
- "end",
- "days"
-]New value: +[
+ "start",
+ "end",
+ "days",
+ "reference_start_at",
+ "reference_end_at",
+ "window_type",
+ "reference_bounds",
+ "timezone",
+ "duration_hours",
+ "calendar_dates_touched",
+ "source_alignment",
+ "source_boundaries"
+]Output schema / properties / period_boundary_definitionsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "account_registry_not_period_scoped": {
+ "type": "string"
+ },
+ "database_statement_time_window": {
+ "type": "string"
+ },
+ "defined_per_output_item": {
+ "type": "string"
+ },
+ "derived_from_current_and_previous": {
+ "type": "string"
+ },
+ "derived_previous_daily_window": {
+ "type": "string"
+ },
+ "jst_calendar_dates_from_database_window_start": {
+ "type": "string"
+ },
+ "jst_calendar_dates_from_reference_start": {
+ "type": "string"
+ },
+ "jst_calendar_dates_inclusive": {
+ "type": "string"
+ },
+ "path_syntax": {
+ "const": "dot_path_with_array_wildcard",
+ "type": "string"
+ },
+ "reference_timestamp_window": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path_syntax",
+ "reference_timestamp_window",
+ "database_statement_time_window",
+ "jst_calendar_dates_from_reference_start",
+ "jst_calendar_dates_from_database_window_start",
+ "jst_calendar_dates_inclusive",
+ "account_registry_not_period_scoped",
+ "derived_previous_daily_window",
+ "derived_from_current_and_previous",
+ "defined_per_output_item"
+ ],
+ "type": "object"
+}Output schema / properties / previous_periodAdded value: +{
+ "$ref": "#/properties/period"
+}Output schema / requiredPrevious value: -[
- "site_id",
- "dimension",
- "period",
- "presentation_hints"
-]New value: +[
+ "site_id",
+ "dimension",
+ "period",
+ "data_freshness",
+ "period_boundary_definitions",
+ "presentation_hints"
+]get_priority_insights16 fields changedOutput schema / properties / data_freshnessAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bot_classification_delay_definitions": {
+ "additionalProperties": false,
+ "properties": {
+ "burst_cluster_fallback": {
+ "type": "string"
+ },
+ "burst_cluster_primary": {
+ "type": "string"
+ },
+ "single_page_zero_dwell": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "burst_cluster_primary",
+ "burst_cluster_fallback",
+ "single_page_zero_dwell"
+ ],
+ "type": "object"
+ },
+ "bot_classification_delay_minutes_max_by_rule": {
+ "additionalProperties": false,
+ "properties": {
+ "burst_cluster_fallback": {
+ "const": 480,
+ "type": "number"
+ },
+ "burst_cluster_primary": {
+ "const": 20,
+ "type": "number"
+ },
+ "single_page_zero_dwell": {
+ "const": 480,
+ "type": "number"
+ }
+ },
+ "required": [
+ "burst_cluster_primary",
+ "burst_cluster_fallback",
+ "single_page_zero_dwell"
+ ],
+ "type": "object"
+ },
+ "delay_bounds_assume_scheduled_jobs_operational": {
+ "const": true,
+ "type": "boolean"
+ },
+ "generated_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "may_change_because": {
+ "items": {
+ "enum": [
+ "live_ingestion",
+ "open_window",
+ "moving_window",
+ "delayed_bot_classification"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "provisional": {
+ "const": true,
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "generated_at",
+ "provisional",
+ "may_change_because",
+ "bot_classification_delay_minutes_max_by_rule",
+ "bot_classification_delay_definitions",
+ "delay_bounds_assume_scheduled_jobs_operational"
+ ],
+ "type": "object"
+}Output schema / properties / insights / items / properties / source_boundariesAdded value: +{
+ "items": {
+ "$ref": "#/properties/period/properties/source_boundaries/items"
+ },
+ "type": "array"
+}Output schema / properties / insights / items / requiredPrevious value: -[
- "id",
- "severity",
- "title",
- "detail",
- "metric",
- "value",
- "change",
- "recommended_action",
- "impact_score",
- "rank"
-]New value: +[
+ "id",
+ "severity",
+ "title",
+ "detail",
+ "metric",
+ "value",
+ "change",
+ "recommended_action",
+ "impact_score",
+ "rank",
+ "source_boundaries"
+]Output schema / properties / period / properties / calendar_dates_touchedAdded value: +{
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / period / properties / duration_hoursAdded value: +{
+ "type": "number"
+}Output schema / properties / period / properties / reference_boundsAdded value: +{
+ "const": "start_inclusive_end_exclusive",
+ "type": "string"
+}Output schema / properties / period / properties / reference_end_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / period / properties / reference_start_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / period / properties / source_alignmentAdded value: +{
+ "enum": [
+ "exact",
+ "mixed"
+ ],
+ "type": "string"
+}Output schema / properties / period / properties / source_boundariesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "applies_to": {
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "boundary": {
+ "enum": [
+ "reference_timestamp_window",
+ "database_statement_time_window",
+ "jst_calendar_dates_from_reference_start",
+ "jst_calendar_dates_from_database_window_start",
+ "jst_calendar_dates_inclusive",
+ "account_registry_not_period_scoped",
+ "derived_previous_daily_window",
+ "derived_from_current_and_previous",
+ "defined_per_output_item"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "applies_to",
+ "boundary"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / period / properties / timezoneAdded value: +{
+ "const": "Asia/Tokyo",
+ "type": "string"
+}Output schema / properties / period / properties / window_typeAdded value: +{
+ "enum": [
+ "rolling",
+ "calendar_to_date",
+ "comparison"
+ ],
+ "type": "string"
+}Output schema / properties / period / requiredPrevious value: -[
- "start",
- "end",
- "days"
-]New value: +[
+ "start",
+ "end",
+ "days",
+ "reference_start_at",
+ "reference_end_at",
+ "window_type",
+ "reference_bounds",
+ "timezone",
+ "duration_hours",
+ "calendar_dates_touched",
+ "source_alignment",
+ "source_boundaries"
+]Output schema / properties / period_boundary_definitionsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "account_registry_not_period_scoped": {
+ "type": "string"
+ },
+ "database_statement_time_window": {
+ "type": "string"
+ },
+ "defined_per_output_item": {
+ "type": "string"
+ },
+ "derived_from_current_and_previous": {
+ "type": "string"
+ },
+ "derived_previous_daily_window": {
+ "type": "string"
+ },
+ "jst_calendar_dates_from_database_window_start": {
+ "type": "string"
+ },
+ "jst_calendar_dates_from_reference_start": {
+ "type": "string"
+ },
+ "jst_calendar_dates_inclusive": {
+ "type": "string"
+ },
+ "path_syntax": {
+ "const": "dot_path_with_array_wildcard",
+ "type": "string"
+ },
+ "reference_timestamp_window": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path_syntax",
+ "reference_timestamp_window",
+ "database_statement_time_window",
+ "jst_calendar_dates_from_reference_start",
+ "jst_calendar_dates_from_database_window_start",
+ "jst_calendar_dates_inclusive",
+ "account_registry_not_period_scoped",
+ "derived_previous_daily_window",
+ "derived_from_current_and_previous",
+ "defined_per_output_item"
+ ],
+ "type": "object"
+}Output schema / properties / previous_periodAdded value: +{
+ "$ref": "#/properties/period"
+}Output schema / requiredPrevious value: -[
- "site_id",
- "period",
- "basis",
- "assumptions",
- "limitations",
- "rules_evaluated",
- "insights",
- "presentation_hints"
-]New value: +[
+ "site_id",
+ "period",
+ "previous_period",
+ "data_freshness",
+ "period_boundary_definitions",
+ "basis",
+ "assumptions",
+ "limitations",
+ "rules_evaluated",
+ "insights",
+ "presentation_hints"
+]get_summary18 fields changedOutput schema / properties / data_freshnessAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "bot_classification_delay_definitions": {
+ "additionalProperties": false,
+ "properties": {
+ "burst_cluster_fallback": {
+ "type": "string"
+ },
+ "burst_cluster_primary": {
+ "type": "string"
+ },
+ "single_page_zero_dwell": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "burst_cluster_primary",
+ "burst_cluster_fallback",
+ "single_page_zero_dwell"
+ ],
+ "type": "object"
+ },
+ "bot_classification_delay_minutes_max_by_rule": {
+ "additionalProperties": false,
+ "properties": {
+ "burst_cluster_fallback": {
+ "const": 480,
+ "type": "number"
+ },
+ "burst_cluster_primary": {
+ "const": 20,
+ "type": "number"
+ },
+ "single_page_zero_dwell": {
+ "const": 480,
+ "type": "number"
+ }
+ },
+ "required": [
+ "burst_cluster_primary",
+ "burst_cluster_fallback",
+ "single_page_zero_dwell"
+ ],
+ "type": "object"
+ },
+ "delay_bounds_assume_scheduled_jobs_operational": {
+ "const": true,
+ "type": "boolean"
+ },
+ "generated_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "may_change_because": {
+ "items": {
+ "enum": [
+ "live_ingestion",
+ "open_window",
+ "moving_window",
+ "delayed_bot_classification"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "provisional": {
+ "const": true,
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "generated_at",
+ "provisional",
+ "may_change_because",
+ "bot_classification_delay_minutes_max_by_rule",
+ "bot_classification_delay_definitions",
+ "delay_bounds_assume_scheduled_jobs_operational"
+ ],
+ "type": "object"
+}Output schema / properties / period / properties / calendar_dates_touchedAdded value: +{
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / period / properties / duration_hoursAdded value: +{
+ "type": "number"
+}Output schema / properties / period / properties / reference_boundsAdded value: +{
+ "const": "start_inclusive_end_exclusive",
+ "type": "string"
+}Output schema / properties / period / properties / reference_end_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / period / properties / reference_start_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / period / properties / source_alignmentAdded value: +{
+ "enum": [
+ "exact",
+ "mixed"
+ ],
+ "type": "string"
+}Output schema / properties / period / properties / source_boundariesAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "applies_to": {
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "boundary": {
+ "enum": [
+ "reference_timestamp_window",
+ "database_statement_time_window",
+ "jst_calendar_dates_from_reference_start",
+ "jst_calendar_dates_from_database_window_start",
+ "jst_calendar_dates_inclusive",
+ "account_registry_not_period_scoped",
+ "derived_previous_daily_window",
+ "derived_from_current_and_previous",
+ "defined_per_output_item"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "applies_to",
+ "boundary"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / period / properties / timezoneAdded value: +{
+ "const": "Asia/Tokyo",
+ "type": "string"
+}Output schema / properties / period / properties / window_typeAdded value: +{
+ "enum": [
+ "rolling",
+ "calendar_to_date",
+ "comparison"
+ ],
+ "type": "string"
+}Output schema / properties / period / requiredPrevious value: -[
- "start",
- "end",
- "days"
-]New value: +[
+ "start",
+ "end",
+ "days",
+ "reference_start_at",
+ "reference_end_at",
+ "window_type",
+ "reference_bounds",
+ "timezone",
+ "duration_hours",
+ "calendar_dates_touched",
+ "source_alignment",
+ "source_boundaries"
+]Output schema / properties / period_boundary_definitionsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "account_registry_not_period_scoped": {
+ "type": "string"
+ },
+ "database_statement_time_window": {
+ "type": "string"
+ },
+ "defined_per_output_item": {
+ "type": "string"
+ },
+ "derived_from_current_and_previous": {
+ "type": "string"
+ },
+ "derived_previous_daily_window": {
+ "type": "string"
+ },
+ "jst_calendar_dates_from_database_window_start": {
+ "type": "string"
+ },
+ "jst_calendar_dates_from_reference_start": {
+ "type": "string"
+ },
+ "jst_calendar_dates_inclusive": {
+ "type": "string"
+ },
+ "path_syntax": {
+ "const": "dot_path_with_array_wildcard",
+ "type": "string"
+ },
+ "reference_timestamp_window": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path_syntax",
+ "reference_timestamp_window",
+ "database_statement_time_window",
+ "jst_calendar_dates_from_reference_start",
+ "jst_calendar_dates_from_database_window_start",
+ "jst_calendar_dates_inclusive",
+ "account_registry_not_period_scoped",
+ "derived_previous_daily_window",
+ "derived_from_current_and_previous",
+ "defined_per_output_item"
+ ],
+ "type": "object"
+}Output schema / properties / previous_period / $refAdded value: +"#/properties/period"Output schema / properties / previous_period / additionalPropertiesRemoved value: -falseOutput schema / properties / previous_period / propertiesRemoved value: -{
- "end": {
- "type": "string"
- },
- "start": {
- "type": "string"
- }
-}Output schema / properties / previous_period / requiredRemoved value: -[
- "start",
- "end"
-]Output schema / properties / previous_period / typeRemoved value: -"object"Output schema / requiredPrevious value: -[
- "site_id",
- "period",
- "previous_period",
- "basis",
- "kpis",
- "trend",
- "path_recommendation",
- "ad_spend_data_status",
- "connected_channels",
- "ad_spend_channels_in_period",
- "ad_spend_rows_in_period",
- "presentation_hints"
-]New value: +[
+ "site_id",
+ "period",
+ "previous_period",
+ "data_freshness",
+ "period_boundary_definitions",
+ "basis",
+ "kpis",
+ "trend",
+ "path_recommendation",
+ "ad_spend_data_status",
+ "connected_channels",
+ "ad_spend_channels_in_period",
+ "ad_spend_rows_in_period",
+ "presentation_hints"
+]get_breakdown2 fields changedOutput schema / properties / presentation_hintsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "avoid_long_prose": {
+ "const": true,
+ "type": "boolean"
+ },
+ "prefer_compact_visual_summary": {
+ "const": true,
+ "type": "boolean"
+ },
+ "primary_metric": {
+ "type": "string"
+ },
+ "recommended_followup_tools": {
+ "items": {
+ "enum": [
+ "get_breakdown",
+ "get_priority_insights"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommended_sections": {
+ "items": {
+ "enum": [
+ "kpi_summary",
+ "trend",
+ "ad_spend_context",
+ "breakdown",
+ "priority_insights",
+ "recommended_actions"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "response_type": {
+ "enum": [
+ "analytics_summary",
+ "analytics_breakdown",
+ "priority_insights"
+ ],
+ "type": "string"
+ },
+ "show_breakdown": {
+ "type": "boolean"
+ },
+ "show_period_comparison": {
+ "type": "boolean"
+ },
+ "show_priority_insights": {
+ "type": "boolean"
+ },
+ "show_trend": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "response_type",
+ "primary_metric",
+ "show_period_comparison",
+ "show_trend",
+ "show_breakdown",
+ "show_priority_insights",
+ "prefer_compact_visual_summary",
+ "avoid_long_prose",
+ "recommended_followup_tools",
+ "recommended_sections"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "site_id",
- "dimension",
- "period"
-]New value: +[
+ "site_id",
+ "dimension",
+ "period",
+ "presentation_hints"
+]get_priority_insights2 fields changedOutput schema / properties / presentation_hintsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "avoid_long_prose": {
+ "const": true,
+ "type": "boolean"
+ },
+ "prefer_compact_visual_summary": {
+ "const": true,
+ "type": "boolean"
+ },
+ "primary_metric": {
+ "type": "string"
+ },
+ "recommended_followup_tools": {
+ "items": {
+ "enum": [
+ "get_breakdown",
+ "get_priority_insights"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommended_sections": {
+ "items": {
+ "enum": [
+ "kpi_summary",
+ "trend",
+ "ad_spend_context",
+ "breakdown",
+ "priority_insights",
+ "recommended_actions"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "response_type": {
+ "enum": [
+ "analytics_summary",
+ "analytics_breakdown",
+ "priority_insights"
+ ],
+ "type": "string"
+ },
+ "show_breakdown": {
+ "type": "boolean"
+ },
+ "show_period_comparison": {
+ "type": "boolean"
+ },
+ "show_priority_insights": {
+ "type": "boolean"
+ },
+ "show_trend": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "response_type",
+ "primary_metric",
+ "show_period_comparison",
+ "show_trend",
+ "show_breakdown",
+ "show_priority_insights",
+ "prefer_compact_visual_summary",
+ "avoid_long_prose",
+ "recommended_followup_tools",
+ "recommended_sections"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "site_id",
- "period",
- "basis",
- "assumptions",
- "limitations",
- "rules_evaluated",
- "insights"
-]New value: +[
+ "site_id",
+ "period",
+ "basis",
+ "assumptions",
+ "limitations",
+ "rules_evaluated",
+ "insights",
+ "presentation_hints"
+]get_summary2 fields changedOutput schema / properties / presentation_hintsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "avoid_long_prose": {
+ "const": true,
+ "type": "boolean"
+ },
+ "prefer_compact_visual_summary": {
+ "const": true,
+ "type": "boolean"
+ },
+ "primary_metric": {
+ "type": "string"
+ },
+ "recommended_followup_tools": {
+ "items": {
+ "enum": [
+ "get_breakdown",
+ "get_priority_insights"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommended_sections": {
+ "items": {
+ "enum": [
+ "kpi_summary",
+ "trend",
+ "ad_spend_context",
+ "breakdown",
+ "priority_insights",
+ "recommended_actions"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "response_type": {
+ "enum": [
+ "analytics_summary",
+ "analytics_breakdown",
+ "priority_insights"
+ ],
+ "type": "string"
+ },
+ "show_breakdown": {
+ "type": "boolean"
+ },
+ "show_period_comparison": {
+ "type": "boolean"
+ },
+ "show_priority_insights": {
+ "type": "boolean"
+ },
+ "show_trend": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "response_type",
+ "primary_metric",
+ "show_period_comparison",
+ "show_trend",
+ "show_breakdown",
+ "show_priority_insights",
+ "prefer_compact_visual_summary",
+ "avoid_long_prose",
+ "recommended_followup_tools",
+ "recommended_sections"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "site_id",
- "period",
- "previous_period",
- "basis",
- "kpis",
- "trend",
- "path_recommendation",
- "ad_spend_data_status",
- "connected_channels",
- "ad_spend_channels_in_period",
- "ad_spend_rows_in_period"
-]New value: +[
+ "site_id",
+ "period",
+ "previous_period",
+ "basis",
+ "kpis",
+ "trend",
+ "path_recommendation",
+ "ad_spend_data_status",
+ "connected_channels",
+ "ad_spend_channels_in_period",
+ "ad_spend_rows_in_period",
+ "presentation_hints"
+]get_summary4 fields changedOutput schema / properties / kpis / properties / avg_duration_depth_basisAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "previous": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "previous",
+ "change"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / kpis / properties / median_duration_depth_basisAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/properties/kpis/properties/avg_duration_depth_basis/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / kpis / properties / median_scroll_depthAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/properties/kpis/properties/avg_duration_depth_basis/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / kpis / requiredPrevious value: -[
- "revenue",
- "sessions",
- "rps",
- "aov",
- "cvr",
- "avg_duration",
- "bounce_rate",
- "scroll_depth",
- "roas"
-]New value: +[
+ "revenue",
+ "sessions",
+ "rps",
+ "aov",
+ "cvr",
+ "avg_duration",
+ "bounce_rate",
+ "scroll_depth",
+ "avg_duration_depth_basis",
+ "median_duration_depth_basis",
+ "median_scroll_depth",
+ "roas"
+]get_breakdown2 fields changedInput schema / properties / visitor_typeAdded value: +{
+ "enum": [
+ "new",
+ "returning"
+ ],
+ "type": "string"
+}Output schema / properties / rows / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "aov_jpy": {
- "type": [
- "number",
- "null"
- ]
- },
- "avg_dwell_seconds": {
- "type": "number"
- },
- "bot_excluded_count": {
- "type": "number"
- },
- "bounce_rate_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "channel": {
- "type": "string"
- },
- "clicks": {
- "type": [
- "number",
- "null"
- ]
- },
- "conversion_value_jpy": {
- "type": [
- "number",
- "null"
- ]
- },
- "conversions": {
- "type": [
- "number",
- "null"
- ]
- },
- "cvr": {
- "type": [
- "number",
- "null"
- ]
- },
- "impressions": {
- "type": [
- "number",
- "null"
- ]
- },
- "is_unattributed": {
- "type": "boolean"
- },
- "orders": {
- "type": [
- "number",
- "null"
- ]
- },
- "revenue_jpy": {
- "type": "number"
- },
- "roas": {
- "type": [
- "number",
- "null"
- ]
- },
- "rps_jpy": {
- "type": "number"
- },
- "saturation_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "sessions": {
- "type": "number"
- },
- "spend_jpy": {
- "type": [
- "number",
- "null"
- ]
- },
- "visitors": {
- "type": "number"
- }
- },
- "required": [
- "channel",
- "sessions",
- "revenue_jpy",
- "rps_jpy",
- "visitors",
- "avg_dwell_seconds",
- "bounce_rate_pct",
- "bot_excluded_count",
- "orders",
- "aov_jpy",
- "cvr",
- "spend_jpy",
- "impressions",
- "clicks",
- "conversions",
- "conversion_value_jpy",
- "roas",
- "saturation_pct"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "aov_jpy": {
- "type": "number"
- },
- "campaign": {
- "type": "string"
- },
- "cvr": {
- "type": "number"
- },
- "revenue_jpy": {
- "type": "number"
- },
- "rps_jpy": {
- "type": "number"
- },
- "sessions": {
- "type": "number"
- }
- },
- "required": [
- "campaign",
- "sessions",
- "revenue_jpy",
- "rps_jpy",
- "aov_jpy",
- "cvr"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "avg_position": {
- "type": [
- "number",
- "null"
- ]
- },
- "avg_time_on_page_seconds": {
- "type": [
- "number",
- "null"
- ]
- },
- "bounce_rate": {
- "type": [
- "number",
- "null"
- ]
- },
- "clicks": {
- "type": [
- "number",
- "null"
- ]
- },
- "ctr": {
- "type": [
- "number",
- "null"
- ]
- },
- "impressions": {
- "type": [
- "number",
- "null"
- ]
- },
- "page": {
- "type": "string"
- },
- "pageviews": {
- "type": "number"
- },
- "pageviews_change": {
- "type": [
- "number",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- },
- "unique_visitors": {
- "type": "number"
- }
- },
- "required": [
- "page",
- "pageviews",
- "unique_visitors",
- "avg_time_on_page_seconds",
- "bounce_rate",
- "pageviews_change",
- "title",
- "impressions",
- "clicks",
- "ctr",
- "avg_position"
- ],
- "type": "object"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "aov_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "avg_dwell_seconds": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "bot_excluded_count": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "bounce_rate_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "channel": {
+ "type": "string"
+ },
+ "clicks": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "conversion_value_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "conversions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "cvr": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "impressions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "is_unattributed": {
+ "type": "boolean"
+ },
+ "orders": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "revenue_jpy": {
+ "type": "number"
+ },
+ "roas": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "rps_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "saturation_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "sessions": {
+ "type": "number"
+ },
+ "spend_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "visitors": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "channel",
+ "sessions",
+ "revenue_jpy",
+ "rps_jpy",
+ "visitors",
+ "avg_dwell_seconds",
+ "bounce_rate_pct",
+ "bot_excluded_count",
+ "orders",
+ "aov_jpy",
+ "cvr",
+ "spend_jpy",
+ "impressions",
+ "clicks",
+ "conversions",
+ "conversion_value_jpy",
+ "roas",
+ "saturation_pct"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "aov_jpy": {
+ "type": "number"
+ },
+ "campaign": {
+ "type": "string"
+ },
+ "cvr": {
+ "type": "number"
+ },
+ "revenue_jpy": {
+ "type": "number"
+ },
+ "rps_jpy": {
+ "type": "number"
+ },
+ "sessions": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "campaign",
+ "sessions",
+ "revenue_jpy",
+ "rps_jpy",
+ "aov_jpy",
+ "cvr"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "avg_position": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "avg_time_on_page_seconds": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "bounce_rate": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "clicks": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ctr": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "impressions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "page": {
+ "type": "string"
+ },
+ "pageviews": {
+ "type": "number"
+ },
+ "pageviews_change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "unique_visitors": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "page",
+ "pageviews",
+ "unique_visitors",
+ "avg_time_on_page_seconds",
+ "bounce_rate",
+ "pageviews_change",
+ "title",
+ "impressions",
+ "clicks",
+ "ctr",
+ "avg_position"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+]get_breakdown1 field changedOutput schema / properties / rows / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "avg_dwell_seconds": {
- "type": "number"
- },
- "bot_excluded_count": {
- "type": "number"
- },
- "bounce_rate_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "channel": {
- "type": "string"
- },
- "clicks": {
- "type": [
- "number",
- "null"
- ]
- },
- "conversion_value_jpy": {
- "type": [
- "number",
- "null"
- ]
- },
- "conversions": {
- "type": [
- "number",
- "null"
- ]
- },
- "impressions": {
- "type": [
- "number",
- "null"
- ]
- },
- "is_unattributed": {
- "type": "boolean"
- },
- "revenue_jpy": {
- "type": "number"
- },
- "roas": {
- "type": [
- "number",
- "null"
- ]
- },
- "rps_jpy": {
- "type": "number"
- },
- "saturation_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "sessions": {
- "type": "number"
- },
- "spend_jpy": {
- "type": [
- "number",
- "null"
- ]
- },
- "visitors": {
- "type": "number"
- }
- },
- "required": [
- "channel",
- "sessions",
- "revenue_jpy",
- "rps_jpy",
- "visitors",
- "avg_dwell_seconds",
- "bounce_rate_pct",
- "bot_excluded_count",
- "spend_jpy",
- "impressions",
- "clicks",
- "conversions",
- "conversion_value_jpy",
- "roas",
- "saturation_pct"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "aov_jpy": {
- "type": "number"
- },
- "campaign": {
- "type": "string"
- },
- "cvr": {
- "type": "number"
- },
- "revenue_jpy": {
- "type": "number"
- },
- "rps_jpy": {
- "type": "number"
- },
- "sessions": {
- "type": "number"
- }
- },
- "required": [
- "campaign",
- "sessions",
- "revenue_jpy",
- "rps_jpy",
- "aov_jpy",
- "cvr"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "avg_position": {
- "type": [
- "number",
- "null"
- ]
- },
- "avg_time_on_page_seconds": {
- "type": [
- "number",
- "null"
- ]
- },
- "bounce_rate": {
- "type": [
- "number",
- "null"
- ]
- },
- "clicks": {
- "type": [
- "number",
- "null"
- ]
- },
- "ctr": {
- "type": [
- "number",
- "null"
- ]
- },
- "impressions": {
- "type": [
- "number",
- "null"
- ]
- },
- "page": {
- "type": "string"
- },
- "pageviews": {
- "type": "number"
- },
- "pageviews_change": {
- "type": [
- "number",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- },
- "unique_visitors": {
- "type": "number"
- }
- },
- "required": [
- "page",
- "pageviews",
- "unique_visitors",
- "avg_time_on_page_seconds",
- "bounce_rate",
- "pageviews_change",
- "title",
- "impressions",
- "clicks",
- "ctr",
- "avg_position"
- ],
- "type": "object"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "aov_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "avg_dwell_seconds": {
+ "type": "number"
+ },
+ "bot_excluded_count": {
+ "type": "number"
+ },
+ "bounce_rate_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "channel": {
+ "type": "string"
+ },
+ "clicks": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "conversion_value_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "conversions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "cvr": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "impressions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "is_unattributed": {
+ "type": "boolean"
+ },
+ "orders": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "revenue_jpy": {
+ "type": "number"
+ },
+ "roas": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "rps_jpy": {
+ "type": "number"
+ },
+ "saturation_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "sessions": {
+ "type": "number"
+ },
+ "spend_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "visitors": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "channel",
+ "sessions",
+ "revenue_jpy",
+ "rps_jpy",
+ "visitors",
+ "avg_dwell_seconds",
+ "bounce_rate_pct",
+ "bot_excluded_count",
+ "orders",
+ "aov_jpy",
+ "cvr",
+ "spend_jpy",
+ "impressions",
+ "clicks",
+ "conversions",
+ "conversion_value_jpy",
+ "roas",
+ "saturation_pct"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "aov_jpy": {
+ "type": "number"
+ },
+ "campaign": {
+ "type": "string"
+ },
+ "cvr": {
+ "type": "number"
+ },
+ "revenue_jpy": {
+ "type": "number"
+ },
+ "rps_jpy": {
+ "type": "number"
+ },
+ "sessions": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "campaign",
+ "sessions",
+ "revenue_jpy",
+ "rps_jpy",
+ "aov_jpy",
+ "cvr"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "avg_position": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "avg_time_on_page_seconds": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "bounce_rate": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "clicks": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ctr": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "impressions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "page": {
+ "type": "string"
+ },
+ "pageviews": {
+ "type": "number"
+ },
+ "pageviews_change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "unique_visitors": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "page",
+ "pageviews",
+ "unique_visitors",
+ "avg_time_on_page_seconds",
+ "bounce_rate",
+ "pageviews_change",
+ "title",
+ "impressions",
+ "clicks",
+ "ctr",
+ "avg_position"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+]get_summary2 fields changedOutput schema / properties / kpis / properties / scroll_depthAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/properties/kpis/properties/revenue"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / kpis / requiredPrevious value: -[
- "revenue",
- "sessions",
- "rps",
- "aov",
- "cvr",
- "avg_duration",
- "bounce_rate",
- "roas"
-]New value: +[
+ "revenue",
+ "sessions",
+ "rps",
+ "aov",
+ "cvr",
+ "avg_duration",
+ "bounce_rate",
+ "scroll_depth",
+ "roas"
+]get_breakdown1 field changedOutput schema / properties / rows / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "avg_dwell_seconds": {
- "type": "number"
- },
- "bot_excluded_count": {
- "type": "number"
- },
- "bounce_rate_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "channel": {
- "type": "string"
- },
- "clicks": {
- "type": [
- "number",
- "null"
- ]
- },
- "conversion_value_jpy": {
- "type": [
- "number",
- "null"
- ]
- },
- "conversions": {
- "type": [
- "number",
- "null"
- ]
- },
- "impressions": {
- "type": [
- "number",
- "null"
- ]
- },
- "is_unattributed": {
- "type": "boolean"
- },
- "revenue_jpy": {
- "type": "number"
- },
- "roas": {
- "type": [
- "number",
- "null"
- ]
- },
- "rps_jpy": {
- "type": "number"
- },
- "saturation_pct": {
- "type": [
- "number",
- "null"
- ]
- },
- "sessions": {
- "type": "number"
- },
- "spend_jpy": {
- "type": [
- "number",
- "null"
- ]
- },
- "visitors": {
- "type": "number"
- }
- },
- "required": [
- "channel",
- "sessions",
- "revenue_jpy",
- "rps_jpy",
- "visitors",
- "avg_dwell_seconds",
- "bounce_rate_pct",
- "bot_excluded_count",
- "spend_jpy",
- "impressions",
- "clicks",
- "conversions",
- "conversion_value_jpy",
- "roas",
- "saturation_pct"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "aov_jpy": {
- "type": "number"
- },
- "campaign": {
- "type": "string"
- },
- "cvr": {
- "type": "number"
- },
- "revenue_jpy": {
- "type": "number"
- },
- "rps_jpy": {
- "type": "number"
- },
- "sessions": {
- "type": "number"
- }
- },
- "required": [
- "campaign",
- "sessions",
- "revenue_jpy",
- "rps_jpy",
- "aov_jpy",
- "cvr"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "avg_position": {
- "type": [
- "number",
- "null"
- ]
- },
- "avg_time_on_page_seconds": {
- "type": [
- "number",
- "null"
- ]
- },
- "bounce_rate": {
- "type": [
- "number",
- "null"
- ]
- },
- "clicks": {
- "type": [
- "number",
- "null"
- ]
- },
- "ctr": {
- "type": [
- "number",
- "null"
- ]
- },
- "impressions": {
- "type": [
- "number",
- "null"
- ]
- },
- "page": {
- "type": "string"
- },
- "pageviews": {
- "type": "number"
- },
- "pageviews_change": {
- "type": [
- "number",
- "null"
- ]
- },
- "unique_visitors": {
- "type": "number"
- }
- },
- "required": [
- "page",
- "pageviews",
- "unique_visitors",
- "avg_time_on_page_seconds",
- "bounce_rate",
- "pageviews_change",
- "impressions",
- "clicks",
- "ctr",
- "avg_position"
- ],
- "type": "object"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "avg_dwell_seconds": {
+ "type": "number"
+ },
+ "bot_excluded_count": {
+ "type": "number"
+ },
+ "bounce_rate_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "channel": {
+ "type": "string"
+ },
+ "clicks": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "conversion_value_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "conversions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "impressions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "is_unattributed": {
+ "type": "boolean"
+ },
+ "revenue_jpy": {
+ "type": "number"
+ },
+ "roas": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "rps_jpy": {
+ "type": "number"
+ },
+ "saturation_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "sessions": {
+ "type": "number"
+ },
+ "spend_jpy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "visitors": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "channel",
+ "sessions",
+ "revenue_jpy",
+ "rps_jpy",
+ "visitors",
+ "avg_dwell_seconds",
+ "bounce_rate_pct",
+ "bot_excluded_count",
+ "spend_jpy",
+ "impressions",
+ "clicks",
+ "conversions",
+ "conversion_value_jpy",
+ "roas",
+ "saturation_pct"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "aov_jpy": {
+ "type": "number"
+ },
+ "campaign": {
+ "type": "string"
+ },
+ "cvr": {
+ "type": "number"
+ },
+ "revenue_jpy": {
+ "type": "number"
+ },
+ "rps_jpy": {
+ "type": "number"
+ },
+ "sessions": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "campaign",
+ "sessions",
+ "revenue_jpy",
+ "rps_jpy",
+ "aov_jpy",
+ "cvr"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "avg_position": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "avg_time_on_page_seconds": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "bounce_rate": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "clicks": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ctr": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "impressions": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "page": {
+ "type": "string"
+ },
+ "pageviews": {
+ "type": "number"
+ },
+ "pageviews_change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "unique_visitors": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "page",
+ "pageviews",
+ "unique_visitors",
+ "avg_time_on_page_seconds",
+ "bounce_rate",
+ "pageviews_change",
+ "title",
+ "impressions",
+ "clicks",
+ "ctr",
+ "avg_position"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+]get_ai_traffic2 fields changedOutput schema / properties / criteria / properties / citation_max_bounceRemoved value: -{
- "type": "number"
-}Output schema / properties / criteria / requiredPrevious value: -[
- "content_namespaces",
- "min_pageviews",
- "citation_max_bounce",
- "min_ai_sessions"
-]New value: +[
+ "content_namespaces",
+ "min_pageviews",
+ "min_ai_sessions"
+]get_summary1 field changedOutput schema / properties / kpis / properties / roas / anyOfPrevious value: -[
- {
- "$ref": "#/properties/kpis/properties/revenue"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "change": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "previous": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "previous",
+ "change"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]get_summary2 fields changedOutput schema / properties / ad_spend_rows_last_7dRemoved value: -{
- "type": "number"
-}Output schema / requiredPrevious value: -[
- "site_id",
- "period",
- "previous_period",
- "basis",
- "kpis",
- "trend",
- "path_recommendation",
- "ad_spend_data_status",
- "connected_channels",
- "ad_spend_channels_in_period",
- "ad_spend_rows_in_period",
- "ad_spend_rows_last_7d"
-]New value: +[
+ "site_id",
+ "period",
+ "previous_period",
+ "basis",
+ "kpis",
+ "trend",
+ "path_recommendation",
+ "ad_spend_data_status",
+ "connected_channels",
+ "ad_spend_channels_in_period",
+ "ad_spend_rows_in_period"
+]get_content_actions7 fields changedOutput schema / properties / criteria / properties / expected_revenue_gainAdded value: +{
+ "type": "string"
+}Output schema / properties / criteria / properties / expected_sessions_gainAdded value: +{
+ "type": "string"
+}Output schema / properties / criteria / properties / priorityAdded value: +{
+ "type": "string"
+}Output schema / properties / criteria / requiredPrevious value: -[
- "provisional",
- "comparison",
- "significant_clicks_delta",
- "position_worsening",
- "striking_band",
- "striking_clicks_below",
- "dormant",
- "landing_attribution",
- "caveat_flags"
-]New value: +[
+ "provisional",
+ "comparison",
+ "significant_clicks_delta",
+ "position_worsening",
+ "striking_band",
+ "striking_clicks_below",
+ "dormant",
+ "landing_attribution",
+ "priority",
+ "expected_sessions_gain",
+ "expected_revenue_gain",
+ "caveat_flags"
+]Output schema / properties / pages / items / properties / expected_revenue_gainAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / pages / items / properties / expected_sessions_gainAdded value: +{
+ "type": "number"
+}Output schema / properties / pages / items / requiredPrevious value: -[
- "page",
- "action",
- "confidence",
- "caveats",
- "is_new",
- "cur_clicks",
- "cur_impressions",
- "cur_position",
- "prev_clicks",
- "prev_impressions",
- "prev_position",
- "main_query_position",
- "striking_uplift_clicks",
- "striking_query_count",
- "striking_queries",
- "sessions",
- "engaged",
- "revenue_jpy",
- "ai_sessions",
- "ai_revenue_jpy",
- "ai_sources",
- "clicks_threshold"
-]New value: +[
+ "page",
+ "action",
+ "confidence",
+ "caveats",
+ "is_new",
+ "cur_clicks",
+ "cur_impressions",
+ "cur_position",
+ "prev_clicks",
+ "prev_impressions",
+ "prev_position",
+ "main_query_position",
+ "striking_uplift_clicks",
+ "striking_query_count",
+ "striking_queries",
+ "sessions",
+ "engaged",
+ "revenue_jpy",
+ "ai_sessions",
+ "ai_revenue_jpy",
+ "ai_sources",
+ "clicks_threshold",
+ "expected_sessions_gain",
+ "expected_revenue_gain"
+]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.
