io.scalably/gsc-mcp

Official

Overview Schema Source Related Servers Score Discussions Admin

gsc_batch_inspect_urls

Read-only

Inspect many URLs under a Google Search Console property in one batch, returning indexing details per URL, with rate-limit and per-URL error handling.

Instructions

Inspect many URLs under a single Search Console property. Rate-limited.

Respects Google's 600 QPM / 2,000 QPD per-site limits. Default pace of 8 QPS stays well under 600/minute with headroom. For large jobs (>2000 URLs), split across days or across multiple verified properties (e.g. per-subdomain).

Args: urls: list of fully-qualified URLs under site_url. No dedup. site_url: the Search Console property. language_code: BCP-47, default "en-US". requests_per_second: pace. Max ~10 (600 QPM). Caller can lower on 429 pressure. continue_on_error: if True, collect per-URL errors instead of aborting.

Returns: { "results": [{"url": str, "inspection": {...flattened...}} | {"url": str, "error": str}], "count": total, "errors": N, "skipped": 0 }

Quota warning: This does NOT replace the Search Analytics API for bulk query analysis. If the intent is "which pages have most traffic", use gsc_query_search_analytics instead - 40,000 QPM per project vs 600/site here.

Input Schema

TableJSON Schema

Name	Required	Default
`urls`	Yes
`site_url`	Yes
`language_code`	No	en-US
`continue_on_error`	No
`requests_per_second`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Sep 8, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete rate limits, the default 8 QPS pace, the ~10 QPS maximum, behavior under 429 pressure, and the lack of deduplication. It also clarifies continue_on_error behavior, making the tool's runtime behavior fully transparent.

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 well-structured with an opening summary, rate-limit context, an Args section, a Returns section, and a quota warning. Every sentence adds operational value, and the most important scoping information is front-loaded.

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?

For a 5-parameter rate-limited batch tool with no schema descriptions, the description covers invocation, parameter semantics, error handling, rate limits, return shape, and alternative routing. Nothing essential for an agent to call this tool correctly is missing.

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

Parameters5/5

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

Despite 0% schema description coverage, the description richly documents each parameter: fully-qualified URLs under site_url, the Search Console property, BCP-47 language_code, rate limit semantics for requests_per_second, and the conditional effect of continue_on_error. This fully compensates for the schema's lack of descriptive text.

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 description opens with 'Inspect many URLs under a single Search Console property', stating a specific verb, resource, and batch scope. The batch nature clearly differentiates it from the sibling gsc_inspect_url, and the quota warning distinguishes it from gsc_query_search_analytics.

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?

The description gives explicit guidance on when not to use this tool: it explicitly names gsc_query_search_analytics as the alternative for bulk traffic analysis. It also provides practical usage guidance for large jobs, including splitting across days or multiple verified properties, and mentions lowering requests_per_second when hitting 429 pressure.

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

Install Server