PagePulse

Reads a website's sitemap and reports the URL paths it publishes, grouped by section (e.g. /services/, /blog/) with a count and sample URLs for each. Use this BEFORE create-project-tool whenever the user wants to track only part of a site — "track the service pages", "just the product pages", "our locations" — so you can find the real paths instead of guessing, show the user what you found, and then pass the confirmed paths to create-project-tool as include_paths. Returns both grouped sections AND the flat list of root-level pages, because many small-business sites put service pages at the root (/patio-installation/) with no /services/ prefix. Tries the usual sitemap locations automatically; pass sitemap_url if you already know it. Reads the public sitemap only — it does not create anything or require the site to be a project yet.

discover-site-paths-tool

Retrieves the full record for a single PagePulse entity (project or page) by its prefixed id. The id must be in the form "project:{uuid}" or "page:{id}" — the same format returned by the search tool. Returns a rich document-shaped payload ({id, title, text, url, metadata}) describing the entity, suitable for citation and for giving the model enough context to decide what specialized tool to call next. For deeper structured analytics (time series, changes, query-level breakdowns), use the dedicated tools (get_page_analytics_tool, get_project_analytics_tool, get_page_changes_tool, etc.) once you have the identifiers.

fetch-tool

Returns the MEASURED change→effect verdicts from the Page Pulse impact model: for change windows on a page, how clicks actually moved afterward versus the expected baseline, with a confidence band (possible / likely / high) and the evaluation horizon. THIS is the defensible "did that change help?" answer — prefer it over eyeballing time series yourself, because the model controls for the page's own baseline trajectory. Each row: the page, when the change window started, which fields dominated the change, clicks lift percent (negative = decline), confidence band and score, and the horizon in days. Rows exist only for changes the model judged meaningful AND that have completed an evaluation horizon — a recent change may not be evaluated yet (that is "still measuring", not "no effect"). Use search-changes-tool to see raw changes, this tool to see which ones mattered.

get-change-outcomes-tool

Returns the pages that MOVED the most — ranked by the change (delta) in a metric between the requested window and the prior window of the same length (or the same window last year). This is the triage tool for large projects: start here to find where traffic shifted, then use search-changes-tool / get-page-changes-tool to see what changed on those pages and get-change-outcomes-tool for measured change→effect verdicts. metric: clicks | impressions | position | ctr | key_events. Each row carries current and prior values, absolute and percent delta, and how many meaningful detected changes the page had in the window. POSITION SEMANTICS: position is lower-is-better, so a NEGATIVE position delta is an improvement; direction=up means "improved" for every metric (position falling). Use min_impressions to ignore pages with no real search presence.

get-movers-tool

Gets detailed SEO analytics for a single page over a date range. Returns aggregated metrics (clicks, impressions, average position, CTR, users, key events, page views, bounce rate, time on page), an optional daily time series, and a compact page_change_summary block showing which dates had changes (with counts by field and the strongest impact band per date — no raw diffs). Use this when the user asks how a specific page is performing ("is this page doing well", "how is [page] trending", "how is [page] doing this month"), whether traffic dropped, or to compare a recent period against a prior one. Pass comparison: previous-period or previous-year to get percent-change values automatically. The view_scope parameter controls whether you get page metrics or landing page metrics — default to "page" unless the user specifically asks about landing pages or session entries. Set include_time_series: false when you only need totals to save tokens. Position is "lower is better" — a position drop from 5 to 3 is an improvement. To investigate a drop: the page_change_summary in this response already tells you which dates had changes and how significant (via max_impact_band) — use that to pick a date, then call get_page_changes_tool or get_page_change_summary_tool for the details.

get-page-analytics-tool

Gets detected on-page changes for a specific page within a date range. Each change includes the field that changed (title, h1, meta_description, body_content, internal_links, schema, etc.), the old and new values, the change type (new/edit/removal), the detected timestamp, and its IMPACT BAND — noise, low, notable, high, or critical — from the Page Pulse impact model, plus the underlying impact_score (0-100). Use this when the user asks "what changed on this page" / "did anything change recently" / "what edits happened to [page]" / "show me the diff on [page]", or as a follow-up to get_page_analytics_tool when investigating why traffic moved. Pass min_band: notable to skip cosmetic noise; use high or critical when the user asks for the biggest or most important changes. About bands: impact_band is null when the impact model did not score that change — usually because it fell below the model's meaningfulness floor (trivial or repeated edits), which is itself a signal it is not worth surfacing. Separately, meta.impact_scored: false means the whole project has never been through the impact model, in which case NO change has a band, any min_band filter is ignored (see meta.band_filter_applied), and you should say the project has not been scored yet rather than reporting that nothing changed. Sorted newest first.

get-page-changes-tool

Gets aggregated SEO analytics across all pages in a project — or a filtered subset. Returns total clicks, impressions, users, key events, average position, plus an optional daily time series and a page change summary. Use this for project-wide questions like "how is the whole site doing" / "site overview" / "what's the trend on this site" / "are we losing traffic overall", "how did my blog perform last month" (filter by tag), or "what changed across the site". Filter to a subset of pages using search (URL substring), tag_ids (OR logic — pages with any of those tags), or has_page_change_on (pages with changes on specific dates). The pages_count in the response tells you how many pages matched the filters. Each date in the page change summary carries impact_bands (counts per band: noise, low, notable, high, critical); use min_band to restrict the summary to meaningful changes only (min_band: notable is the usual floor, high/critical for the biggest). impact_scored: false means the project has not been through the impact model yet, so bands are unavailable — say so rather than reporting nothing changed. Set include_time_series: false to save tokens when you only need totals.

get-project-analytics-tool

Lists tracked pages within a PagePulse project. Use this to find a specific page (by URL substring via the search param), to browse pages by tag, or to find pages that had changes on specific dates. Returns paginated results with each page's URL, path, title, tags, and aggregated clicks/impressions/position for the requested date range. Pages can number in the thousands per project — always use search/tag filters when possible, and rely on pagination. Returns total count in meta so you can tell the user if there's more data. Use this when the user asks for "top pages" / "best pages" / "highest-traffic pages" / "biggest pages by clicks" (the default sort handles ranking — clicks descending), "what pages do I have", "find the page about X", "show me pages tagged Y", "pages that changed on [date]", or before drilling into a specific page with the analytics or changes tools. Results are sorted by clicks descending by default (pages with the most traffic in the date range first); pass order_by (clicks, impressions, url, id) and order_by_dir (asc, desc) to change this. Sort ties are always broken by page id ascending so pagination is stable.

get-project-pages-tool

Gets Google Search Console query performance data for a specific page over a date range. Returns the search queries (keywords) that drove impressions or clicks to this page, each with totals for clicks, impressions, average position, and CTR. Use this when the user asks "what keywords does this page rank for", "what queries are bringing traffic here", or to understand what search intent a page is capturing. Sort by clicks (default) to see top performers, or by impressions to see queries with high visibility but low clicks (potential CTR optimization opportunities). Use the search param to look for queries containing specific terms. Pages can have hundreds of queries — pagination is supported. A query with high impressions but very low clicks/CTR may indicate a title or meta description that doesn't match search intent.

get-search-queries-tool

Lists every alert on a PagePulse project: name, enabled/disabled, what it watches (trigger + scope), where it delivers (emails / Slack), its cadence, and its live state — alert_state (ok or firing), last_triggered_at (when it last notified) and last_checked_at (when it was last evaluated). Use this to answer "what alerts do I have", "did my alert fire last night" (check last_triggered_at), "why didn't I get an email" (check enabled and last_checked_at), and ALWAYS before creating an alert, to avoid proposing a duplicate of one that already exists. An alert with enabled=false never notifies anyone — say so plainly rather than reporting it as coverage. Use update-alert-tool to enable/disable an alert or change its delivery; deleting or editing conditions requires the web app (manage_url).

list-alerts-tool