Loading ToolBench
MCP server for gmapsscraper.io — let Claude, Cursor and any MCP client scrape Google Maps business data: names, phones, emails, websites, ratings.
Strong tool definitions with complete schemas, detailed descriptions, and thoughtful error handling. All 4 tools have explicit registrations with input schemas and descriptions. Naming is clear and action-oriented (scrape_*, get_*, start_*). Descriptions are comprehensive (150-250 chars), explaining WHAT, WHEN, and consequences. Parameters are well-typed with constraints (min/max, enums, defaults). Error responses guide recovery (e.g., 'Do NOT re-run the scrape' with job_id for polling). Key weakness: output schemas are not formally documented, responses are JSON but structure is inferred from code rather than declared in tool metadata. Security is solid (API key via env var, no secrets in params). Composition is clean: each tool has one responsibility, and outputs chain naturally (job_id from start_scrape_job feeds into get_scrape_results).
Get the remaining gmapsscraper.io credit balance for the configured API key. Each scrape costs 2 credits. Free to call.
Check the status of a scrape job and fetch the business records once it is complete. Does not spend credits — safe to call repeatedly.
Search Google Maps and return business leads: name, address, phone, email, website, rating, reviews count, category, coordinates. Costs 2 credits per call — every call bills again (NOT idempotent, do not retry on your own). Always confirm with the user before spending credits. Multiple related keywords in one call cost the same 2 credits. Blocks until the scrape finishes (typically 30-120s). Be specific with keywords, e.g. "vegan restaurant in Brooklyn NY".
Submit a Google Maps scrape job without waiting for it to finish. Costs 2 credits per call — every call bills again (NOT idempotent, do not retry on your own). Always confirm with the user before spending credits. Returns a job id — poll it later with get_scrape_results. Use this instead of scrape_google_maps for large areas or when the user wants to continue working meanwhile.
Output schemas not formally documented in tool metadata. Responses are JSON (via formatRecords, jsonResult helpers) but structure is inferred from code, not declared. LLMs cannot plan downstream calls without knowing returned fields (total_results, returned, businesses, job_id, status, etc.).
Result capping (MAX_RECORDS_RETURNED=100) is implemented but not mentioned in tool descriptions. Users/LLMs may expect all results and be surprised by truncation. Description should state: 'Returns up to 100 results; full CSV available from dashboard.'
Error handling for scrape_google_maps is sophisticated (distinguishes job_failed vs timeout, provides recovery paths) but relies on exception type inspection (GMapsScraperError instanceof checks). If SDK changes, error classification breaks. Consider wrapping in a stable error classification layer.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Tool annotations present (readOnlyHint, idempotentHint, destructiveHint, openWorldHint) but destructiveHint is false for scrape_google_maps and start_scrape_job despite billing 2 credits per call. Should be true or add a custom annotation for 'billable' to signal cost to agents.
No pagination support for get_scrape_results. If a job returns 1000+ records, only 100 are shown. No cursor, offset, or limit parameter to fetch additional pages. Agents cannot retrieve full result sets.