SEO GSC Wizard MCP

Get site performance summary

get_site_summary

Read-only

Returns clicks, impressions, CTR, and average position for a property over the last N days (default 28), with a same-length prior period for comparison. Use this for quick health checks before drilling into details. Served from the ClickHouse warehouse when available, otherwise the live Search Console API (see dataSource). For an explicit window pass startDate/endDate (YYYY-MM-DD) instead: a date you pass always wins, and days only sizes an edge you leave out. The comparison period is always the same length as the window and sits immediately before it. avgPosition is impression-weighted, as Search Console reports it. dailyRows is the window day by day and previousDailyRows the comparison period day by day, in the same shape; previousDailyRows is omitted for a window longer than 180 days.

Input Schema

TableJSON Schema

Name	Required	Description
`days`	No	Length of the trailing window in days (default 28, max 180). Ignored for any edge you pin with startDate/endDate; when exactly one of those is given it sizes the other edge.
`brand`	No	Optional. Narrow to queries matching the property's branded keywords ('branded') or to all others ('non_branded'). Needs branded keywords set (update_site brandedKeywords); see get_filter_options.
`endDate`	No	Optional. Window end as YYYY-MM-DD (e.g. 2026-05-31). You do NOT need to know today's date or the latest available date: omit this and the window ends at the latest settled Search Console date (data lags ~2-3 days). Passed alone, the window is `days` long and ends here. Never pass null or the string "null".
`siteUrl`	Yes
`startDate`	No	Optional. Window start as YYYY-MM-DD (e.g. 2026-05-03). You do NOT need to know today's date: omit both startDate and endDate to use the trailing `days` window instead (Search Console data lags ~2-3 days, so the window ends at the latest settled date). Passed alone, the window runs from here to the latest settled date. Never pass null or the string "null".
`contentGroupId`	No	Optional. Narrow to pages in this content group (id from get_filter_options or list_content_groups). Groups whose rules cannot be applied as a filter are refused; get_filter_options says which.
`topicClusterId`	No	Optional. Narrow to queries in this topic cluster (id from get_filter_options or list_topic_clusters). Clusters whose keywords cannot be applied as a filter are refused.

Output Schema

TableJSON Schema

Name	Required	Description
`kind`	No	Widget variant: "kpis", "table", or "sections".
`kpis`	No	KPI cards (kind="kpis").
`note`	No	Caveat about the result, when the tool returned one.
`rows`	No	Data rows (kind="table").
`notes`	No	Caveats about the result, when the tool returned several.
`title`	No
`blocks`	No	Stacked sub-blocks (kind="sections").
`source`	No
`columns`	No	Column defs (kind="table").
`timeZone`	No	GA4 property's IANA reporting time zone.
`emptyText`	No
`siteScope`	No	Set when GA4 numbers were narrowed to this site's hostnames because the property is shared with other sites.
`dataMaturity`	No
`settledThrough`	No	Last day the data is complete through.
`comparisonHasData`	No	false when the comparison period has no data at all, so there is no comparison.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 7, 2026

addedOutput schema / properties / comparisonHasData

Added value: +{
+  "description": "false when the comparison period has no data at all, so there is no comparison.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / note

Added value: +{
+  "$ref": "#/properties/kind",
+  "description": "Caveat about the result, when the tool returned one."
+}

addedOutput schema / properties / notes

Added value: +{
+  "$ref": "#/properties/siteScope/anyOf/0/properties/hostnames",
+  "description": "Caveats about the result, when the tool returned several."
+}

addedOutput schema / properties / siteScope

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "hostnames": {
+          "anyOf": [
+            {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "includesSubdomainsOf": {
+          "$ref": "#/properties/title"
+        },
+        "note": {
+          "$ref": "#/properties/title"
+        },
+        "sharedWithSites": {
+          "$ref": "#/properties/siteScope/anyOf/0/properties/hostnames"
+        }
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Set when GA4 numbers were narrowed to this site's hostnames because the property is shared with other sites."
+}

First observedOct 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavior beyond that: the ClickHouse-vs-live-API data source fallback, impression-weighted avgPosition semantics, and the fact that previousDailyRows is dropped for windows longer than 180 days. It omits any permission or quota considerations, so it is strong but not exhaustive.

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

Conciseness4/5

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

Front-loads the return values and primary use case, then handles window semantics. The closing sentence explaining dailyRows/previousDailyRows is somewhat redundant given an output schema exists, but the 180-day omission caveat inside it is a genuine behavioral detail, so the length is mostly earned.

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?

With a rich output schema and annotations covering safety, the description supplies exactly what structured fields cannot: data-source behavior, comparison-period construction, edge-case precedence between days and explicit dates, and a return-shape caveat. An agent can invoke this correctly for a 7-parameter tool without further inference.

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

Parameters4/5

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

Schema description coverage is 86%, so the baseline is 3 and the schema already carries most parameter meaning. The description adds real edge-case semantics the schema only implies: 'a date you pass always wins, and `days` only sizes an edge you leave out,' plus the rule that the comparison period is always equal-length and immediately preceding. It leaves the filter params (brand, contentGroupId, topicClusterId) entirely to 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?

States a specific verb and resource (site-level clicks, impressions, CTR, average position over a trailing window) and explicitly positions itself as a high-level health check 'before drilling into details,' which separates it from get_page_performance, get_query_performance, and query_search_analytics. The agent can identify its role without opening the schema.

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?

Gives a clear usage cue ('quick health checks before drilling into details') and explains when to switch to explicit startDate/endDate rather than relying on `days`. It does not name which drill-down sibling to use next or state any conditions where this tool should be avoided, so it stops short of full when/when-not guidance.

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

All SEO GSC Wizard MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?