Google Search Console Audit MCP

Overview Schema Source Related Servers Discussions Admin

gsc_compare_periods

Read-onlyIdempotent

Compare two date ranges in Google Search Console by dimension and rank rows by click delta, highlighting which queries or pages gained or lost traffic.

Instructions

Join two periods on one dimension and rank the rows by click delta.

Answers "what changed" without the model diffing two tables by hand. Rows present in only one period are kept, with zeros on the missing side; the biggest movers in both directions are returned, worst first. The meta counts how many rows gained and how many lost clicks.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`days`	No	Rolling window length ending today.
`period`	No	Named range: last_7_days, last_28_days, last_3_months, last_month, this_month, last_16_months.
`date_to`	No	End date YYYY-MM-DD. Defaults to today.
`no_cache`	No	Bypass the response cache for this call.
`site_url`	Yes	`sc-domain:example.com` for a domain property, or `https://example.com/` with the trailing slash for a URL-prefix property. Call gsc_sites if unsure.
`date_from`	No	Start date YYYY-MM-DD. Overrides period and days.
`dimension`	No	One of query, page, country, device, searchAppearance.	query
`row_limit`	No	Rows returned. Default 100, capped at 1000.
`prev_date_to`	No	Baseline end YYYY-MM-DD.
`prev_date_from`	No	Baseline start YYYY-MM-DD. Defaults to the equally long period ending the day before date_from.
`min_impressions`	No	Drop rows below this impression count in both periods.
`response_format`	No	`tsv` (default, compact) or `json`.	tsv

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.0.1Aug 28, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral detail: rows missing from one period are kept with zeros, movers are returned worst-first, and meta reports gained versus lost click counts. This goes well beyond the annotation hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the first sentence states the core operation, and each subsequent sentence adds a distinct, necessary behavioral detail. There is no filler and no repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema, output schema, and annotations, the description still covers the non-obvious behaviors an agent needs: one-sided rows are retained with zeros, ordering is worst-first, and meta counts gains versus losses. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter already has its own useful description, so the baseline of 3 applies. The description reinforces the period-comparison concept but does not add parameter syntax or date semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific operation: joining two periods on a dimension and ranking rows by click delta. Framing it as the 'what changed' comparison tool distinguishes it from more specific sibling trend tools like gsc_traffic_drops and gsc_content_decay.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use case: answer 'what changed' between periods without manually diffing tables. It does not explicitly name sibling alternatives or exclusion criteria, but the context is clear and not misleading.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server