Loading ToolBench
MCP server providing access to Google Search Console API via the Model Context Protocol, enabling Search Console data retrieval in workflows via MCP Client
This server has foundational tool definitions but significant quality gaps. All 7 tools have names starting with action verbs (list_, get_, inspect_) which is good. However, descriptions are in Dutch and many lack depth about WHEN to use them or WHAT they return. Parameter descriptions are present but sparse. Most critically, NO OUTPUT SCHEMAS are documented, the code shows API calls but never specifies what fields the response contains, breaking the LLM's ability to plan downstream tool calls or extract data. Error handling exists (try/catch blocks) but error messages are generic ('Fout bij...') with no recovery guidance. The server accepts Google Site URL formats with some flexibility (sc-domain: or https://), which is user-friendly, but lacks enum constraints on parameters like 'dimensions' that should restrict to ['query', 'page', 'country', 'device']. Overall, this reads as an early-stage server suitable for personal use but not production-grade for agent integration.
Haal zoektermen op voor een specifieke URL
Haal search analytics data op voor een site
Haal top pagina's op voor een site
Haal top zoektermen op voor een site
Controleer URL indexeringsstatus
Lijst alle sitemaps voor een site
Lijst alle Search Console sites op
No output schemas documented. Tools return Google API responses but LLMs cannot determine what fields to expect, breaking downstream tool chaining and data extraction. For example, get_search_analytics() calls searchanalytics().query() but never specifies whether the response contains 'rows', 'data', 'metrics', or how they are structured.
Parameter 'dimensions' in get_search_analytics() accepts arbitrary strings but should be constrained to enum ['query', 'page', 'country', 'device']. Free-form strings invite hallucinated values like 'traffic' or 'engagement'.
All descriptions are in Dutch ('Lijst alle Search Console sites op', 'Haal search analytics data op voor een site'). International LLMs may not parse Dutch reliably, and English-speaking users cannot understand the tool intent. Descriptions should be in English for maximum compatibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Descriptions lack WHEN-to-use and WHAT-is-returned guidance. E.g., 'Haal search analytics data op voor een site' (35 chars) does not explain when to call it vs get_top_queries, what fields are in the response, or whether it supports pagination.
Parameter 'row_limit' lacks min/max constraints. Unbounded integers let LLMs pass absurd values like 1000000, risking API rate limits or timeouts. Should document 'row_limit (1 - 10000, default: 1000)'.
Date parameters (start_date, end_date) lack format specification in descriptions. Should state 'ISO 8601 format (YYYY-MM-DD), e.g. 2024-01-15'.
Error messages are generic and non-recoverable ('Fout bij ophalen search analytics' = 'Error fetching search analytics'). No guidance on whether to retry, ask the user, or check credentials. Per pattern:recovery-guide, errors should suggest next steps: 'Invalid site_url format. Use sc-domain:example.com or https://www.example.com. Try list_sites() to see available sites.'