SEO GSC Wizard MCP

Inspect multiple URLs

bulk_inspect_urls

Runs the Google URL Inspection API against a list of URLs, persisting each result to GSC Wizard's inspection history. Each result carries the verdict, coverage, the Google-selected and user-declared canonicals (null when Google did not report one) and a Search Console link. Google caps inspections at 2,000 per property per day (shared across the UI and every MCP call); this tool counts each inspection against that cap and stops once it is reached, returning the URLs it could not get to. A Google rate limit, quota refusal or property-level permission refusal also stops the run: the URLs not yet inspected come back skipped, with skipReason, and the result carries stopReason (and retryAfterSeconds when Google gave one). Call get_inspection_quota first if you want to see remaining headroom. Each inspection takes about 7 seconds at Google, run 5 at a time, so a call takes up to 25 URLs (about 35 seconds); for larger sets add them with add_tracked_urls, where this connection offers it, and let the Indexing Tracker inspect them in the background (check_tracked_url_now inspects a few of them immediately).

Input Schema

Name	Required	Description	Default
`urls`	Yes	Up to 25 URLs per call; use add_tracked_urls for more, where this connection offers it.
`siteUrl`	Yes

Output Schema

Name	Required	Description	Default
`count`	No
`quota`	No
`failed`	No
`message`	No
`results`	No
`siteUrl`	No
`skipped`	No
`succeeded`	No
`stopReason`	No
`quotaExhausted`	No
`retryAfterSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 18, 2026

changedInput schema / properties / urls / description

Previous value: -"Up to 25 URLs per call; use add_tracked_urls for more."New value: +"Up to 25 URLs per call; use add_tracked_urls for more, where this connection offers it."

changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +true
```

changedOutput schema / properties / quota / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "count": {
-        "$ref": "#/properties/count"
-      },
-      "limit": {
-        "$ref": "#/properties/count"
-      },
-      "remaining": {
-        "$ref": "#/properties/count"
-      }
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "properties": {
+      "count": {
+        "$ref": "#/properties/count"
+      },
+      "limit": {
+        "$ref": "#/properties/count"
+      },
+      "remaining": {
+        "$ref": "#/properties/count"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / properties / results / items / additionalProperties
```
Previous value: -falseNew value: +true
```

Changed6 schema fields changedOct 10, 2026
- addedOutput schema / properties / results / items / properties / googleCanonical
```
Added value: +{
+  "$ref": "#/properties/siteUrl"
+}
```
- addedOutput schema / properties / results / items / properties / inspectionResultLink
```
Added value: +{
+  "$ref": "#/properties/siteUrl"
+}
```
- addedOutput schema / properties / results / items / properties / skipReason
```
Added value: +{
+  "$ref": "#/properties/siteUrl"
+}
```
- addedOutput schema / properties / results / items / properties / userCanonical
```
Added value: +{
+  "$ref": "#/properties/siteUrl"
+}
```
- addedOutput schema / properties / retryAfterSeconds
```
Added value: +{
+  "$ref": "#/properties/count"
+}
```
- addedOutput schema / properties / stopReason
```
Added value: +{
+  "$ref": "#/properties/siteUrl"
+}
```
First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover read-only/open-world/destructive flags, and the description adds far more: the 2,000-per-property-per-day cap shared with the UI, mid-run stop behavior, the shape of partial results (skipped URLs with skipReason, stopReason, retryAfterSeconds on Google rate limits or permission refusals), and the ~7s/5-concurrent timing model. This is exactly the operational context annotations cannot express.

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-loaded with the primary action and its persistence behavior, then layers quota, failure mode, and timing details in order of usefulness. The closing sentence packing add_tracked_urls, Indexing Tracker, and check_tracked_url_now is dense but each clause earns its place; slightly long overall.

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?

An output schema exists, yet the description still previews the meaningful return fields (verdict, coverage, canonicals, Search Console link, skipped/stopReason), so an agent knows both how to call it and what to expect. Nothing needed for correct invocation is missing.

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 50%: 'urls' is documented in the schema (maxItems 25, pointer to add_tracked_urls), while 'siteUrl' has no schema description. The description compensates by framing siteUrl as the property ('per property per day', 'property-level permission refusal'), clarifying its meaning beyond the bare string.

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+resource ('Runs the Google URL Inspection API against a list of URLs') and immediately distinguishes itself from the single-URL sibling by scope ('list of URLs') and by side effect ('persisting each result to GSC Wizard's inspection history'). It also names the role each related tool plays (get_inspection_quota, add_tracked_urls, check_tracked_url_now), so an agent can place it in the family without opening schemas.

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

Usage Guidelines5/5

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

It gives explicit routing rules: call get_inspection_quota first for headroom, use this tool for sets of up to 25, and switch to add_tracked_urls for larger sets so the Indexing Tracker runs them in the background. That is when-to-use plus the concrete alternative, not just implied context.

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?