Loading ToolBench
MCP server for Google Search Console on Cloudflare Workers
Strong foundation with 14 well-named tools following verb_noun convention (list_, get_, inspect_, submit_, delete_). All tools have descriptions (avg 150 chars, within 10-1024 baseline). Input schemas present and properly typed with JSON Schema. Key strengths: clear parameter descriptions with format guidance (e.g., 'sc-domain:example.com' vs 'https://example.com/'), enum constraints on dimensions/search_type, and thoughtful defaults (days=28, limit=50). Weaknesses: output schemas not documented in source; error handling present but recovery guidance sparse; no explicit per-tool risk annotations visible in schema (though risk metadata provided separately); parameter relationships (e.g., start_date/end_date mutual requirement) documented in descriptions but could be stricter via JSON Schema dependencies.
Delete a sitemap from Google Search Console.
Daily traffic over a date range, with clicks, impressions, CTR and average position.
Search performance data: clicks, impressions, CTR and average position, grouped by any combination of dimensions. This is the full performance report, use it when the preset tools do not fit.
Traffic by search appearance type (e.g. rich results, AMP, etc.), with clicks, impressions, CTR and average position.
Get details about a specific sitemap, including the number of URLs and any errors.
Top countries driving traffic to a property, with clicks, impressions, CTR and average position.
Output schemas not documented in source code. LLMs cannot plan downstream calls or extract fields without knowing response structure (e.g., what fields does inspect_url return? Is it indexed, canonical, mobile_usable?). Code shows summariseInspection() reducing responses, but this transformation is not exposed in tool definitions.
Destructive tools (submit_sitemap, delete_sitemap) lack confirmation/dry-run pattern. No explicit support for user confirmation before irreversible operations. Agents could accidentally delete sitemaps without safeguards.
Error handling returns ToolResult with isError flag, but recovery guidance is minimal. Example: 'No rows returned' note suggests checking date range, but does not guide LLM to retry with different parameters or call list_sites for validation. Error messages lack actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Traffic by device type (desktop, mobile, tablet), with clicks, impressions, CTR and average position.
Top pages on a property by clicks, with impressions, CTR and average position.
Top search queries driving traffic to a property, with clicks, impressions, CTR and average position.
Inspect a URL in Google's index: is it indexed, what is Google's canonical, is it mobile-usable, etc. Useful for debugging indexation issues.
Inspect multiple URLs in Google's index in parallel batches. Returns indexation status, canonicals, mobile usability, and robots.txt state for each URL.
Lists all sitemaps submitted to a property, with their status and last submission date.
Lists every Search Console property the service account can access, with its permission level. Call this first if unsure of the exact property identifier, since Google is strict about the format.
Submit or resubmit a sitemap to Google Search Console.
Parameter relationships not enforced via JSON Schema. start_date/end_date are documented as mutually required, but schema does not use 'required' array or 'oneOf' to enforce this. LLMs may pass only one, causing validation errors.
Batch tool (inspect_urls) accepts max 20 URLs but does not document this limit in the description. LLMs may attempt to pass 50+ URLs, causing silent truncation or errors. Limit must be explicit in parameter description.