Loading ToolBench
Model Context Protocol server for Google Search Console. Brings keyword and query data to Claude Code, Cursor, and any MCP-compatible AI tool.
Server has 8 well-named tools with clear, domain-specific descriptions (avg 180 chars). All tools have complete input schemas with types and defaults. However, output schemas are not formally documented, responses are inferred from code inspection. Parameter descriptions are present but some lack detail on constraints (e.g., 'days' lacks min/max bounds). No error handling guidance, no tool annotations, and no security/permission documentation. Naming follows verb_noun pattern well (list_sites, top_queries_*). Composition is sound, each tool has one responsibility. Missing: output schema documentation, error recovery guidance, and input validation rules.
Queries with strong impressions but unusually low click-through rate. These are pages where Google ranks you well but your title and meta description aren't earning the click. Rewriting the title is often the fastest SEO win.
Top landing pages by organic search clicks over the last N days. Tells you WHICH pages on your site are getting traffic from Google. Pair with `queries_for_page` to drill into what queries drove each page.
List all Search Console properties visible to the authenticated user. Use this to discover what `site` values are valid for other tools. Returns each site's URL and the user's permission level.
Queries ranking on positions 11-20 (Google's page 2). These are your CLOSEST-TO-WIN searches: already visible to Google but not yet on page 1. Pushing them to positions 1-10 is the highest-ROI SEO work because the ranking work is mostly done.
Output schemas not formally documented. Responses are inferred from code (dict with 'site', 'rows', 'row_count' fields) but not declared in tool definitions. LLMs cannot plan downstream operations without knowing return structure.
Parameter 'days' lacks min/max bounds and validation rules. Description says 'Lookback window in days (default 30)' but does not specify valid range (e.g., 1 - 365). LLMs may pass invalid values like 0 or 10000.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
All search queries that drove organic clicks to a SPECIFIC page. Use this when you want to know "what are people searching to find /some-specific-url". The page_url must match the URL Search Console indexed (typically the full https://... form).
Top search queries ranked by CLICKS over the last N days. Use this for "what searches are actually sending people to my site". Returns each query with clicks, impressions, click-through rate, and average Google ranking position.
Top queries ranked by IMPRESSIONS (Google show-ups, click or not). Use this to find ranking opportunities: queries Google is willing to surface you for but where you don't yet earn the click.
No error handling guidance. Tools call Google APIs but do not document what happens on auth failure, rate limit, or invalid site URL. LLMs receive raw errors with no recovery path.
full_seo_report has no description (empty string). LLMs cannot determine when to call it or what it returns. This violates the critical rule that every tool must have a non-empty description.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only but this is not declared. Agents cannot distinguish safe tools from destructive ones without explicit hints.