pull_gsc_data

Cost: 5 credits.

pull_gsc_data fetches your project's Google Search Console performance for two adjacent windows — the most recent days-day period and the days-day period right before it — and stores them so the discovery tools (find_quick_wins, detect_cannibalization, analyze_content_decay) can read them without calling Google again. Connect Search Console first.

What it does

Using your project's encrypted refresh token, it mints a short-lived Google access token and runs searchAnalytics.query for both windows, broken down by query and page. The two windows are equal length and adjacent, so the discovery tools can compare "now" against "before". The result is stored against your project; the discovery tools read the most recent pull.

Only a completed pull is charged, and every refusal below happens before anything is spent — you are not charged, and each one says so:

• the project is archived;
• the project has no Search Console connection — no Google account is attached yet;
• the connection has no matched property, so there is nothing to query;
• Google refuses the property (403). The answer names the property and the two things that clear it: have an owner grant this account access, or connect an account that already has it;
• the Google credential is dead (access revoked or expired). The answer names the account and hands you the re-approval link — and SeoGrep also records that the account needs reconnecting, which is why list_gsc_properties and whats_next start saying so straight afterwards;
• the Google call fails for any other reason.

Example

Ask your MCP client in plain language:

Pull the last 90 days of Search Console data for my example.com project.

Then run a discovery tool over it:

Find quick wins for example.com.

Input

Returns

A summary of the pull: the two window date ranges, how many (query, page) rows each holds, and a job_id for the stored result. Feed the project into a discovery tool next.

Limitations (v0)

• Search Console finalizes a day's data with a ~2–3 day delay, and reports a day it has not finalized as zero rather than as missing. Both windows therefore end 3 days before today instead of running up to it, which clears the delay Google documents with margin to spare: measured against lags of up to 5 days, no unfinalized day is read as a traffic collapse. It is a bounded guard, not an absolute one — if Search Console ever falls further behind than that, unfinalized days re-enter the window and a run of zeros can still look like a drop. The trade-off: the newest 3 days are not analyzed, so a genuine drop surfaces here up to 3 days after it begins.
• Each window is fetched a page at a time until Search Console runs out of rows, four requests have gone out (100,000 rows, the absolute ceiling), or the rows fill what one stored pull can hold — a page that would overshoot is cut to what fits, so the limit is a hard bound rather than a check between pages. That storage budget is measured on the rows themselves, so a property with long URLs and long-tail queries stops at fewer rows than one with short ones — there is no single row number that is true for every site, which is why the reply names the count your window was cut at instead of quoting a cap. A window that was cut is flagged, here and in every analysis read from the pull.