A minimal MCP server for Google Search Console
This server has solid parameter schemas and mostly clear descriptions, but falls short of production-grade quality in several critical areas. All four tools use Zod for schema definition with proper type constraints and descriptions. However, the tool descriptions are inconsistent in depth; some lack context about when to use them vs. alternatives. Output schemas are not documented, responses are formatted as plain text tables rather than structured data. Error handling is minimal (try-catch returns generic error messages without recovery guidance). The tool set is narrow but well-scoped for read-only Search Console access. Overall, this is a mid-tier implementation suitable for basic use but lacking the polish and detail required for enterprise deployment.
Inspect a URL to check its indexing status, crawl info, and any issues Google found.
List all sitemaps submitted for a site in Google Search Console.
List all sites (properties) you have access to in Google Search Console.
Query search analytics data from Google Search Console. Returns clicks, impressions, CTR, and position for your site.
No documented output schemas. Responses are formatted as plain-text strings (tables, text blobs) rather than structured JSON objects with typed fields. LLMs cannot parse these reliably to extract data for downstream tool calls.
Minimal error handling with no recovery guidance. Errors return generic messages like 'Error querying search analytics: <error.message>'. LLMs receive no actionable next steps, retryability classification, or suggestions for resolution.
Tool descriptions lack context about WHEN to use each tool and how they differ. E.g., 'inspect_url' and 'search_analytics' both provide information about site performance, but the description doesn't clarify the distinction or when to prefer one.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
No pagination or result-limiting guidance. 'search_analytics' accepts rowLimit (default 100, max 25000) but doesn't explain why the limit exists or how to iterate through large result sets. No next_cursor or total_count in response.
Parameter descriptions include example values (e.g., 'e.g. https://example.com/' in siteUrl, 'e.g. USA, GBR' in countryFilter). LLMs frequently reuse these literals in real calls. Use enum constraints or format patterns instead.
Tool descriptions do not state whether operations are read-only or mutate state. While all four tools are read-only (good), this property should be explicit for LLM decision-making (agent knows these are safe to retry).