GSC Wizard

Use this when the user asks how much traffic Bing sends their site over time. Daily clicks and impressions from Bing Webmaster Tools (Bing/Yahoo/DuckDuckGo organic) for a property, up to about 16 months, plus window totals. Complements Google Search Console data with the Bing side of organic search. Not for Google traffic: use get_site_summary. Rows are sorted by date, oldest first. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_traffic_stats

Use this when the user asks which of their URLs have the most backlinks according to Bing. Inbound (backlink) counts per URL that Bing Webmaster Tools has recorded for a property, one page of Bing's results at a time, in Bing's order: most inbound links first. Pass `page` to paginate, though page 0 usually holds every row: despite its name, totalPages is the number of linked URLs Bing reports, not a count of result pages. Not for Google link data, which no tool here reads. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_link_counts

Use this when the user asks how much Bing search demand a keyword has, or how it moves with the seasons. Bing Webmaster Tools' historical impression volume for a single keyword (weekly buckets, oldest first), plus its broad-match impressions. This is Bing marketplace demand data, not tied to any of your properties, so it needs no siteUrl. Not for your site's Bing queries: use get_bing_query_stats. Returns notConfigured: true when no Bing Webmaster API key is set up in the GSC Wizard app.

get_bing_keyword_stats

Use this when the user asks which Bing searches lead to one page. The Bing search queries that led to ONE landing page (clicks, impressions, CTR as a 0-100 percentage, over 100 if Bing logs more clicks than impressions, and impression-weighted average position per query): Bing's per-page keyword view, and the drill-down after get_bing_page_stats. Bing reports only the page's top queries, dated by week, so they sum to at most its get_bing_page_stats row. Not for Google: use query_search_analytics filtered to the page. Rows are sorted by clicks, then impressions, highest first. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_page_queries

Use this when the user asks which Bing queries drive which of their pages. Bing Webmaster Tools query+landing-page pairs for a property, aggregated across the window (clicks, impressions, CTR as a 0-100 percentage, over 100 if Bing logs more clicks than impressions, and impression-weighted average position per pair): the basis for per-page keyword analysis and cannibalisation checks. Bing has no endpoint that returns these combinations, so they are assembled with one request per top page; pass `query` to pair from a single query instead, or use get_bing_page_queries for one page's queries. Coverage is bounded by seedLimit and by Bing's own top-value sampling, so totals are a lower bound (`truncated` says when). Bing dates the rows by week, so a window selects whole weeks by date. Not for Google cannibalisation: use analyze_cannibalization. Pairs are sorted by clicks, then impressions, highest first. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_query_page_stats

Use this when the user asks whether a page slipped on Bing for one search term. Clicks, impressions, CTR (0-100 percentage) and position over time for ONE exact query+landing-page combination on Bing, the only Bing endpoint that carries a true pair-level position. Each row in `daily` is one date and position Bing recorded (Bing records about once a week, and a date can repeat with a second position); `totals.position` is impression-weighted. Take the query and page verbatim from get_bing_query_page_stats or get_bing_page_queries. Not for Google: use get_query_performance with a page. Rows are sorted by date, oldest first, then by position. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_query_page_trend

Use this when the user asks which sitemaps Bing has for their site, or whether Bing reads them cleanly. Sitemaps and feeds submitted to Bing Webmaster Tools for a property, sorted by URL, with each feed's decoded status (Success / Pending / Warning / Error), type (Sitemap / RSS / Atom / ...), submitted and last-crawled dates, URL count and file size. A date of 1601-01-01 is Bing's empty value, not a real date. Not for Google sitemaps: use list_sitemaps, its Google counterpart. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_feeds

Use this when the user asks which pages Bing sends the most traffic to. Top landing pages on Bing Webmaster Tools for a property, aggregated across the window (clicks, impressions, CTR as a 0-100 percentage, and impression-weighted average position). Not for Google pages: use query_top_pages; for one page's queries use get_bing_page_queries. Bing dates page rows by week, so a window selects whole weeks by date. Rows are sorted by clicks, then impressions, highest first. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_page_stats

Use this when the user asks which Bing searches bring them traffic. Top Bing Webmaster Tools queries for a property, aggregated across the window (clicks, impressions, CTR as a 0-100 percentage, and impression-weighted average position). Not for Google queries: use query_top_queries; for one page use get_bing_page_queries. Bing reports only its top queries, dated by week: a window selects whole weeks, and the rows do not sum to get_bing_traffic_stats totals. Rows are sorted by clicks, then impressions, highest first. `rowCount` counts the rows returned (at most `limit`), `totalRows` the distinct queries Bing reported before that cut. Returns notConfigured: true when no Bing Webmaster API key is set up for the property.

get_bing_query_stats

Use this when the user asks how a page's Search Console clicks line up with its GA4 outcomes. Joins Search Console (clicks, impressions, CTR, position) with GA4 (sessions, bounce rate, key events, revenue) per landing page, on the canonical path (no query/hash, no trailing slash). Flags GSC-only and GA4-only pages so neither side is silently dropped. Rows are sorted by clicks, highest first (ties by sessions), period by period with dateGranularity. Not for value per search query: use get_query_value_attribution. By default GA4 metrics are limited to google / organic sessions so both sides describe the same traffic (organicOnly: false for all-traffic GA4 metrics). Units differ by source: ctr is a percentage 0-100 (like every GSC CTR here) while bounceRate is a GA4 fraction 0-1. For a URL-prefix property with a path (e.g. https://example.com/blog/) only GA4 landing pages under that path are joined. Requires a GA4 property linked to the site in GSC Wizard; returns notConfigured otherwise. Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

get_blended_landing_pages

Use this when the user asks how much search traffic is branded: splits it into BRANDED and NON-BRANDED using the branded keywords saved on the property (set them with update_site; a keyword wrapped in slashes like /acme ?corp/ is treated as a regex, otherwise it is a case-insensitive substring). Not for other keyword groups: use get_topic_cluster_performance. Returns totals, the branded share of clicks, a daily clicks trend for both sides (date ascending), and the top queries on each side (clicks descending), with optional comparison-period totals. `nonBranded` is the property total minus `branded`, so the two sides add up to the property total (`total`) and `brandedClickShare` is branded clicks over that total (0-100, like `ctr`). Search Console leaves anonymised queries out of any query-filtered read, so they cannot be matched against the keywords: these long-tail searches are counted in `nonBranded` and reported on their own as `anonymized`, so `brandedClickShare` is a floor, and `coverage.hiddenClicksShare` (0-1) is the share of the property's clicks with no query row. `topNonBrandedQueries` lists named queries only. Returns notConfigured (not an error) when the property has no branded keywords yet. Served from the GSC Wizard ClickHouse warehouse when available, otherwise the live Search Console API (see `dataSource`). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

get_branded_performance

Use this when the user asks how a site section, folder or subdomain performs. Aggregates page-level performance into a subdomain and first-folder breakdown. Each page URL is parsed and grouped by its host plus the first `depth` path segments (depth 1 -> /folder, depth 2 -> /folder/subfolder, etc.). Returns per-group clicks, impressions, CTR (a 0-100 percentage), impression-weighted average position, and the number of distinct pages. Groups are sorted by clicks, highest first. Not for single pages: use query_top_pages. Served from the ClickHouse warehouse when available (every page is grouped), otherwise the live Search Console API (up to 25,000 page rows are grouped; see `dataSource`). `truncated` says when pages or groups were left out; quote totals from `coverage.siteTotals`, not summed groups. Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

breakdown_by_path

Triggers an immediate Google URL Inspection for up to 10 tracked URLs in the GSC Wizard Indexing Tracker, updating each URL's status, warnings, and append-only history. Each result carries the Google-selected and user-declared canonicals (null when Google did not report one). Counts against the daily 2,000-inspection/property quota. If the quota is exhausted, the call returns a quota message instead of running. URLs are inspected five at a time (about 7 seconds each at Google). If Google rate-limits the property or refuses access to it, the URLs not yet inspected come back with skipped: true and a skipReason (plus retryAfterSeconds when Google gave one) and are left untouched; retry them later. Use sparingly; the app's hourly cron checks tracked URLs automatically. This is a server-side write and is audit-logged.

check_tracked_url_now

Use this when the user asks whether a site migration, domain move or restructure lost or gained traffic: a before/after Search Console comparison. Three modes: "cross-property" compares two GSC properties (old domain vs new); "two-urls" compares two URL-prefix sections within one property; "regex" splits one property by two regexes. Returns the daily clicks/impressions trend for each side (date order), per-side totals (avgCtr 0-100) and the query and page winners and losers by click delta (topGainers by clicksDelta descending, topLosers ascending: biggest loss first). Without goLiveDate both sides share one date window (startDate/endDate). With goLiveDate it becomes a before/after comparison around the launch: side A is read over the before window and side B over the after window, placed by windowStrategy ("recent", the default: the last windowDays settled days vs the windowDays before go-live; "from-go-live": the first windowDays from go-live vs the windowDays before; "full": the 90 days before go-live vs every day since). windowDays defaults to 28; yoyBaseline compares with the same weeks a year earlier instead. The go-live result adds `windows` (dates, days since go-live, warnings), `recoveryPct` (B clicks per day as a % of A clicks per day; null under 10 baseline clicks) and trend buckets (lost, declined, stable, improved, new) for queries and pages; pages of two properties are joined by path. Not for the health verdict (risk score, redirect checks, recommendations, projected recovery): use get_migration_health. Query figures cover only the queries Google lists, so they describe visible queries, not the whole site (analyze_sampling_impact measures the gap). Reads the ClickHouse warehouse when available, else the live Search Console API. Query and page lists cover at most the top 25,000 rows by clicks per side; `truncated` / `truncationNote` flag a reached cap. Regexes are capped at 2,000 characters and must not nest quantifiers (for example (a+)+). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

compare_migration

Use this when the user asks how a section or content group of their site performs. Measures a property's content groups: clicks, impressions, CTR, impression-weighted average position, distinct page count and share of clicks per group (CTR and clickShare 0-100), plus an "uncategorized" bucket for pages no group claims. Pass groupId to drill into one group's top pages instead (by clicks, descending). Matching is first-match-wins in the groups' saved order, the same as the web app, and `groups` keep that order (matchOrder 1 first), not a ranking by clicks. Served from the GSC Wizard ClickHouse warehouse when available (where group totals are EXACT over every page of the property), otherwise from the live Search Console API over the top 25,000 pages by clicks (see `dataSource` and `truncated`). Not for the definitions: use list_content_groups (create_content_group adds one); for folder totals without saved groups use breakdown_by_path. Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

get_content_group_performance

Use this when the user asks about real-user page speed or Core Web Vitals. Chrome UX Report field data for a property (or a single page): the weekly history of Core Web Vitals (LCP, INP, CLS) plus FCP and TTFB, each with its p75 value (milliseconds; CLS is unitless), good/needs-improvement/poor rating, and the good-bucket density trend (a 0-1 fraction). periods run oldest first (28-day windows) and every series lines up with them by index. Also reports any week-over-week rating regressions. Where Chrome detected ads, adMetrics adds four experimental ad metrics (ad count, ad density, ad CPU, ad network weight) as a p75 trend each, with no thresholds and no rating; absent for sites with no ads. Needs a Chrome UX Report API key configured in the app; returns notConfigured otherwise, or noData when CrUX has too little real-world traffic for the target. Not for on-page HTML checks: use audit_onpage_seo.

get_core_web_vitals

Use this when the user asks how search traffic splits by country. Returns per-country performance (clicks, impressions, CTR, position) over a date range. Country codes are ISO 3166-1 alpha-3. Not for the device split: use query_devices. Rows are sorted by clicks, highest first; ctr is a 0-100 percentage. Quote totals from `coverage.siteTotals`, or `coverage.filteredTotals` when `coverage.scope` is "filtered", not summed rows. Served from the ClickHouse warehouse when available, else the live Search Console API (see `dataSource`). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

query_countries

Creates one or more URL-prefix properties in Google Search Console (Webmasters sites.add) and registers them in GSC Wizard. Use this to add folder-level properties (e.g. https://example.com/blog/) that do not yet exist in Search Console. They are auto-verified if the connected Google account owns the parent domain property. `parentSiteUrl` is an existing GSC Wizard property whose Google account has access; the new properties inherit it. Every property URL must be under the `parentSiteUrl` domain (that domain or a subdomain of it). Created properties are added hidden and consume no plan slot until you show them with set_dashboard_visibility, which enforces the dashboard limit. For properties that already exist in GSC, use add_site instead.

create_gsc_property

Adds a chart annotation. Scope is "account" by default (visible only to the user); pass siteUrl to scope the annotation to a single property. Platform-wide annotations are reserved for system events and cannot be created via this tool.

create_annotation

Creates a content group partition on a property. Rules are an array of { type, value } objects (prefix / contains / regex / equals) that match URLs into the group. Group names are unique per site. A `regex` rule that cannot compile is rejected; one that is valid but unsupported by the warehouse (a lookahead, lookbehind or backreference) or skipped as ReDoS-prone is accepted and reported in `ruleWarnings`. Relay those to the user, since a skipped pattern matches no pages at all.

create_content_group

Stores a filter preset against a property, as the dashboard's filter panel would. `filters` is the list of filter rows (dimension / operator / value), in the same shape list_saved_filters returns, and `filterLogic` says whether they combine with AND or OR. Saving a preset does not apply it to anything on its own: it appears in the property's filter presets for the user to pick.

create_saved_filter

Saves a table of rows as a shareable GSC Wizard report. Pass the `rows` you got from another tool (e.g. query_top_queries, get_content_group_performance) plus the `columns` describing which fields to show; the report renders at view time, so the stored payload stays small. THIS IS STEP 1 OF 3: the returned URL opens for NOBODY until access is granted, not even for the account owner, because the viewer is the client portal and requires a client login. To actually share it: (2) create_report_client with the recipient's email, then (3) manage_report_access to grant them the report. A recipient never shared with before also needs the account owner to confirm the share from the email GSC Wizard sends them. Do not hand the URL to anyone before access is granted; it will not open. Up to 50 reports per account; delete old ones with delete_shared_report.

create_shared_report

Creates a topic cluster on a property by grouping keywords under a name. Cluster names are unique per property, and the call is idempotent: if the name already exists the existing cluster is returned with alreadyExisted: true instead of an error, so there is never anything to retry. Use update_topic_cluster to change an existing cluster's keywords. Keywords are stored as text and matched against GSC queries in the dashboard.

create_topic_cluster

Use this when the user asks how all their properties are doing, or which gained or lost most. Aggregates a last-N-days clicks/impressions summary across the account's registered Search Console properties (optionally filtered to those carrying a given tag), with a same-length prior period for comparison and per-site totals. Without a tag it also covers properties shared with the account (marked `shared: true`; tags are the caller's own, so a tag filter covers owned properties only). The MCP equivalent of the app's Global Reports page. Set `includeSearchTypes` to also split every property across web / image / video / news / discover, and `includeCountries` for a country leaderboard aggregated over the whole portfolio; their ctr and clickShare are 0-100. perSite and countries are sorted by clicks, descending. Each site routes independently to the ClickHouse warehouse or the live Search Console API, so `dataSource` is reported per site; a site whose read fails, or a share that no longer grants access, is reported in `errors` with a `reason` rather than failing the whole call, and the totals then cover only `sitesIncluded` properties, which `warning` says. Not for one property: use get_site_summary; for a tag's daily trend and top queries and pages use get_tag_group_view. Processes at most `maxSites` properties per call (default and maximum 100; `scope.truncated` says when more matched, so narrow by `tag`). The rate-limit cost scales with the number of properties and the breakdowns requested.

get_cross_site_summary

Use this when the user asks how queries or pages trended month by month (or week by week). Per-query or per-page performance broken down by month or week: the same matrix the app's Query Decay and Content Decay pages render (a row per query/page, one column per period). Not for a list of decliners between two fixed ranges: use find_decaying_content. Returns the top `limit` rows by total clicks, largest first, each with a `values` array aligned to `periods` (oldest first) for the chosen `metric` (ctr is a 0-100 percentage), plus a TOTALS-style per-period aggregate across all matched rows. With dimension query, rows and totals cover only the queries Google lists, not the whole site: on most properties a large share of clicks has no query row (analyze_sampling_impact measures it). Defaults to the last `months` complete months (through the end of last month). Served from the GSC Wizard ClickHouse warehouse when available (longer history), otherwise the live Search Console API (see `dataSource`). On the live API each period is read separately; `truncated: true` with a `note` means a period's read was capped or did not finish in time, and `incompletePeriods` lists any period that reads 0 because it was not read.

get_decay_overview

Deletes a chart annotation by id. Only annotations the user owns can be removed; platform-scoped annotations cannot be deleted via this tool.

delete_annotation

Deletes a content group by id. The property it belongs to must be one you own or one shared with you with full access.

delete_content_group

Deletes a saved filter preset by id. Presets belong to the property, so its owner or anyone with full access to it may delete any of them, as in the GSC Wizard app; read-only access is not enough.

delete_saved_filter

Permanently deletes a saved shareable report and every client grant on it, breaking the shared link for anyone who still has it. Only reports owned by the authenticated user can be deleted. Find the id with list_shared_reports.

delete_shared_report

Deletes a topic cluster by id. The property it belongs to must be one you own or one shared with you with full access.

delete_topic_cluster

Permanently deletes saved redirect mappings. Narrow the deletion with `label` and/or the A/B property pair; to delete EVERY mapping on the account you must pass confirmDeleteAll: true, since an unnarrowed delete would also wipe unrelated migrations. Preview exactly what would go with list_migration_redirects using the same filters first.

delete_migration_redirects

Use this when the user asks whether something broke or spiked on a specific day. Flags statistically anomalous days in a property's Search Console series for a chosen metric (clicks, impressions, CTR, or position). Not for level shifts or gradual trends: use detect_change_points. Uses a robust Modified Z-score with median absolute deviation and day-of-week baselines (mean absolute deviation when most days are identical, as on a low-traffic property), then scores each spike/drop by severity (critical to info). Anomalies are listed by date, oldest first; for ctr, `actual` and `expected` are 0-100 percentages. `direction` is numeric (actual above or below expected), so for position "down" is a better ranking; `outcome` (improved or worsened) is the good-or-bad reading for every metric. Each anomaly carries the day's impressions and clicks. For ctr and position an outlier the day's volume can explain is dropped, and a day under `minImpressions` is kept but marked lowVolume with severity capped at low. `episodes` groups flagged days that follow each other: a run of 3 or more (possibleLevelShift) is usually one level shift, not separate events, and nextStep then says how to check it with detect_change_points. Days without rows count as zero for clicks and impressions, so a drop to zero (deindexing) is flagged; the 21-day minimum is measured in calendar days from the first day with data. CTR and position use only days with impressions. `coverage` reports the days analysed and how an empty tail at the end of the window was treated. Reads the ClickHouse warehouse when available, else the live Search Console API.

detect_anomalies

Use this when the user asks when a property's clicks or impressions moved to a new sustained level (a step, e.g. after a migration, algorithm update or redesign): returns each break's before vs after average and % change, oldest first. Not for one-off spikes: use detect_anomalies; for totals use get_site_summary. Each date is the first day of the new level; breaks at least 14 days apart are found separately. Days without rows count as zero, so a drop to zero (deindexing) is a change point; `coverage` says how an empty tail was treated. beforeMean and afterMean are the daily means of the full segments either side of the break (to the neighbouring breaks or the series ends), and segmentBefore and segmentAfter date those segments. A gradual trend has no step, so read trendSummary (first vs last 14 days) and, on an empty result, emptyBecause, strongestShift or strongestShiftReason, and any nextStep. Reads the ClickHouse warehouse when available, else the live Search Console API. When a shift starts from a zero baseline (beforeMean 0) it has no percentage: changePercent is 0 by convention, which does not mean no change; describe it as new traffic from zero using afterMean. Each change point has a shape: step (at once), gradual (over rampStartDate to rampEndDate) or ambiguous (the data cannot tell at once from over several weeks); describe a gradual or ambiguous one as nextStep words it, never as a one-day event.

detect_change_points

Use this when the user asks how search traffic splits between desktop, mobile and tablet. Returns per-device performance (DESKTOP, MOBILE, TABLET) over a date range. Not for the country split: use query_countries. Rows are sorted by clicks, highest first; ctr is a 0-100 percentage. Quote totals from `coverage.siteTotals`, or `coverage.filteredTotals` when `coverage.scope` is "filtered", not summed rows. Served from the ClickHouse warehouse when available, else the live Search Console API (see `dataSource`). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

query_devices

Use this when the user asks which queries bring GA4 value: estimates GA4 sessions, key events, and revenue per Search Console query via proportional click share: a query with 80% of a page's GSC clicks is credited 80% of that page's GA4 outcomes. Not for page totals: use get_blended_landing_pages. Page-level estimates with known blind spots (device/country/date mismatches are invisible; every click is treated as equally likely to convert). matchedClickShare (0-1) reports how much of the named-query click volume the estimates cover, and `coverage.hiddenClicksShare` (0-1) the share of the property's clicks with no query row, which gets no estimate; estRevenue appears only when the GA4 property records revenue. Rows run clicks descending, period by period with dateGranularity. Requires a GA4 property linked to the site in GSC Wizard; returns a notConfigured explanation otherwise. Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

get_query_value_attribution

Use this when the user asks how their Merchant Center feed scored in the feed audit or which checks fail. Results of the Merchant Center feed audit for a GSC Wizard site: the latest run (or the run of a given runDate) with its status, Feed Score (0-100, split into scoreFeed and scorePage), failure counts by severity, per-check applicable / failed / passed counts with pass rates, offers audited, pages fetched and crawl coverage, plus the score history of earlier runs for the trend. checks run worst first (most failures), history newest first. coverage and the rates are 0-1 fractions (0.12 = 12%), not the 0-100 percentage ctr uses elsewhere. Not for Google's own item issues: use get_product_listing_status. checkKey narrows the checks list to one check; severity is accepted for parity with the app report, but the per-offer issue rows behind either filter live in the ClickHouse warehouse this server cannot read, so such a call answers `issuesAvailable: false`, pointing at the Feed Audit report in the GSC Wizard app. A run can cover several markets (one "<contentLanguage>~<feedLabel>" key each, e.g. "en~GB"): `run.markets` lists them, home market first, and `run.perMarket` gives each market's own offersAudited, score and severity counts; both are null on runs from before multi-market audits, and perMarket stays null until the run completes. The run-level score and checks combine every market the run covered; pass `market` with a key from run.markets to get that market's per-check counts in `checks` instead (a key the run does not cover answers a `marketNote` listing its markets, not an error). The owner picks the home market and up to 4 extra markets on the Feed Audit page in the GSC Wizard app; this server cannot change them. `run.crawlBlocked: true` means the page crawl stopped early because the site refused GSCWizard-Bot (401/403 or robots.txt), so the page-plane checks and scorePage cover few or no pages; allow the crawler and queue a new run. `run: null` means no audit has run yet, or none on runDate (queue one with run_feed_audit). `syncPaused` (with a one-line `staleNote`) means the Merchant Center sync is paused because Merchant Center no longer lets the connected Google account read the merchant: the stored results are still returned but may be stale, and `syncPaused.message` says how to fix it. `syncNotice` (reason "gmc_on_other_account") means Merchant Center is connected on another Google login than the property's Search Console one, so no new audit can run; stored results are still returned. Returns a `notConfigured` result (not an error) when Merchant Center is not connected, its credentials were revoked, no Merchant Center account is linked to the site, or (reason "gmc_on_other_account") no audit was ever stored because Merchant Center sits on another Google login.

get_feed_audit_results

Use this when the user asks which pages or queries are losing clicks. Finds queries or pages losing traffic between a baseline (earlier) period and a recent period. startDate/endDate is the RECENT period; comparisonStartDate/comparisonEndDate is the BASELINE period. Not for a period-by-period matrix (clicks/impressions/position per month or week, like the app's Query Decay / Content Decay pages): use get_decay_overview; for position movers, get_ranking_changes. A key is considered when its baseline has at least `minImpressions` impressions (default 100; when you leave it out and nothing qualifies, the tool retries once at 10 and reports `minImpressionsAutoRelaxed`; a value you pass is always applied as given) and at least `minBaselineClicks` clicks (default 5; decliners under it are counted in `belowClickFloor`). Each row has `clicksLost` (baseline minus recent) and a `severity` that needs both a share and an absolute loss: severe = over 50% AND at least 5 clicks lost, moderate = over 20% AND at least 2, otherwise mild. `lowConfidence: true` marks a loss under 2 Poisson standard deviations ((baseline - recent) / sqrt(baseline + recent) < 2), which chance alone produces. `pattern` is the LIKELY cause read from the key's own totals (proving a query-mix shift needs a page x query read); first match wins: lost_from_search (no recent impressions), ranking_loss (position 3+ worse), long_tail_pruned (position 3+ better AND impressions down 30%+: low-ranked impressions dropped away, which lifts the average position), demand_drop (position steady, impressions down 20%+), low_volume (under 10 baseline clicks), ctr_loss (position and impressions steady, CTR down), else unclear. `positionDelta` is recentPosition - baselinePosition, so POSITIVE means WORSE; it is 0 for a key with no recent row. Returns at most `limit` rows (default 100, max 1000), ordered by `sortBy`: clicksLost (default, largest loss first) or clickChangePct (most negative first); `sortedBy`/`sortOrder` state it. With dimension query only the queries Google lists can appear: on most properties a large share of clicks has no query row (analyze_sampling_impact measures it). The baseline is scanned for its top `scanLimit` keys by clicks (warehouse: max(limit*10, 1000), capped at 50000; live API: 25000 rows per period). On the warehouse every scanned key's recent figure is exact. On the live API the recent period is its own top 25000, so a key missing from a full recent read is not known to be at zero: its recent clicks are at most the smallest count that read kept. When that ceiling is still below the key's baseline, the row is reported with `recentIsUpperBound: true`: `recentClicks` is the ceiling, the real loss is AT LEAST |clickChangePct| (and `clicksLost`), `severity` is a floor, and its recent impressions and position are unknown (0). When the ceiling shows no loss, the key is left out and counted in `unresolvedKeys`. When the two windows differ in length the comparison is per day: baseline clicks are scaled to the recent window (`windowNormalization` says so; each row adds `baselineClicksScaled`, which clickChangePct, clicksLost and minBaselineClicks use, and `baselineClicks` stays the raw total). `truncated: true` means a read hit its cap, so `counts` are measured within the scan, not across the whole property. Served from the GSC Wizard ClickHouse warehouse when available, otherwise the live Search Console API (see `dataSource`). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

find_decaying_content

Use this when the user asks which queries could gain the most clicks by moving up. Finds queries ranking just outside the top positions (between minPosition and maxPosition) and estimates the click upside of pushing them to a target position. Not for an impression-weighted score across positions 3-30: use score_opportunities. The upside uses the property's OWN CTR at the target position (measured over every query in the window on the warehouse), not an industry benchmark. Only queries Google lists are scanned: on most properties a large share of clicks has no query row (analyze_sampling_impact measures it). When the property has no queries at the target position, or fewer than 100 impressions there, it falls back to the industry benchmark named by `fallbackBenchmark`: awr (Advanced Web Ranking 2026, default), awr2026 (AWR 2026 CTR study, organic), awrAio (same study, SERPs with an AI Overview), firstPageSage (First Page Sage 2026), sistrix (Sistrix 2024), or backlinko (Backlinko 2019). The response reports `targetCtr` (the expected CTR used; it and each row's `ctr` are 0-100 percentages), `ctrSource` ("own" or the benchmark key) and `ctrSourceNote` (why). Sorted by `potentialClicks`, largest first. Scans up to 25,000 queries: on the warehouse the ones with the most impressions; on the live API its click order. `truncated: true` means the scan hit that cap (`scanNote` says what that left out). minImpressions defaults to 10 (it also floors the own CTR curve); when it is left out and no query passes, the tool retries once at 1 on its own and says so in `minImpressionsAutoRelaxed` (`minImpressions` is always the floor applied). Served from the GSC Wizard ClickHouse warehouse when available, otherwise the live Search Console API (see `dataSource`). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

find_page_poaching_opportunities

Use this when the user asks how much search traffic to expect in coming weeks or months. Projects future Search Console clicks (or impressions) for a property using the app's forecasting model: multiplicative seasonal decomposition (ratio-to-moving-average) plus an auto-selected trendline (linear / polynomial / log / exponential / power by best R-squared), re-seasonalised for each future period. Not for explaining a past change: use detect_change_points. `forecast` runs oldest period first, `candidateTrendlines` best r2 first; `*Sessions` fields count the chosen metric (clicks or impressions). Optionally applies a manual growth rate and derives revenue from a conversion rate and average order value. History needs: weekly needs 13 complete weeks and monthly 6 complete months, after the first and last (possibly partial) period are dropped, so about 105 days (weekly) or 240 days (monthly) of data. Days and periods without rows count as zero. A constant history (for example all zero) gets a flat forecast with `forecastNote`. Reads the ClickHouse warehouse when available, else the live Search Console API.

forecast_traffic

Use this when the user asks how a site's GA4 traffic splits by one dimension. Runs ONE GA4 dimension breakdown for the property linked to a GSC Wizard site: channel, sourceMedium, page, landingPage, country, device, event, date (daily trend), hostName, firstUserChannel or firstUserSourceMedium. channel and sourceMedium attribute each session to its own source; firstUserChannel and firstUserSourceMedium attribute users to the source that first acquired them, as GA4's User acquisition report does (use those when the user asks about new users or first-user attribution). Each dimension carries its own metric set (returned in `metrics`); rows are sorted by the first metric, highest first (date breakdowns by date, oldest first). Not for site totals: use get_ga4_overview (rows stop at `limit`; do not sum them). Set `secondaryDimension` to "date" or "hostName" to split every row further, e.g. dimension "event" + secondaryDimension "date" shows on which days an event fired; each row then carries that field (dates as YYYY-MM-DD). Rows include prev* fields that are only meaningful when a comparison range is given (`hasComparison`); date breakdowns take no comparison range. Only the first `limit` rows are returned (`truncated` and `note` say when more exist); to follow one event, pass filters: { event: ["<eventName>"] }. When the GA4 property is shared with other sites, results are limited to this site's hostnames and `siteScope` says so (on a shared property a hostName filter narrows within that scope; only the owner can replace it). Rates (engagementRate, bounceRate) are fractions 0-1, not percentages. Returns `notConfigured` (not an error) when Google Analytics is not connected or no GA4 property is linked to the site in GSC Wizard. Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

query_ga4_report