Loading ToolBench
Model Context Protocol server for Google Search Console API - integrate with Claude Code and Claude Desktop
The server defines 6 tools with complete JSON Schema input definitions and descriptions. However, descriptions lack LLM-optimization detail (most are 50-120 chars, below the 194 char baseline for A+ tools), and output schemas are not documented. Parameter descriptions are present but sparse, lacking format constraints, ranges, or dependency documentation. Error handling exists but is generic. Tool naming follows verb_noun convention correctly. No security issues detected (auth is server-side). The server is functional for basic Search Console automation but lacks the refinement expected of production-grade tools.
Compare search performance metrics between two time periods (e.g., this week vs last week)
Query search performance data from Google Search Console for a specified date range
Retrieve sitemap information for a Google Search Console site
Inspect the indexing status of a specific URL in Google Search Console
List all Google Search Console sites accessible to the user
Submit a URL to Google for indexing or request URL removal (requires Indexing API enabled)
Output schemas not documented. LLMs cannot plan downstream calls or extract fields from responses without knowing the structure. Each tool's response shape is invisible in the definitions.
Descriptions are under-specified for LLM optimization. 'List all Google Search Console sites accessible to the user' (62 chars) lacks context on when to call vs related tools, what fields are returned, or prerequisites. Baseline is 194 chars. Most descriptions lack format guidance, constraints, or recovery hints.
Parameter descriptions are minimal. 'The site URL (e.g., "https://example.com/")' is too short and contains example values that LLMs may reuse literally. Format constraints (trailing slash required?), validation rules, and mutual exclusivity (siteUrl vs domain?) are undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No pagination guidance in tool descriptions. get_analytics and compare_periods accept rowLimit and startRow but the description does not explain max limits (25000), whether total count is returned, or how to detect end of results. Without pagination clarity, agents risk context explosion or incomplete result sets.
Error handling in index.ts is generic: 'Tool execution failed: {error.message}' provides no guidance on recovery (retry vs ask user vs fatal). The SearchConsoleError class in error-handler.ts includes recovery hints, but these are not exposed in tool definitions or consistently applied across all code paths.
submit_url_for_indexing is marked WRITE but no confirmation or dry-run pattern. Agents can submit URLs for deletion (URL_DELETED) without a safety gate, risking accidental removal requests. A confirmation_request pattern would prevent catastrophic errors.
Parameter naming ambiguity: 'type' enum in submit_url_for_indexing uses 'URL_UPDATED' and 'URL_DELETED', which are API enums, not user-friendly. Description should explain what each means in plain English ('Request indexing' vs 'Request removal'). No suffix (e.g., 'notification_type') to disambiguate from other possible 'type' params.