Loading ToolBench
Model Context Protocol (MCP) server for Outscraper API (auto-generated from OpenAPI spec). Provides tools for scraping data from Google Maps, Google Search, social media, e-commerce platforms, and contact information discovery.
Three tools with auto-generated schemas from OpenAPI spec. All have descriptions and input schemas, but descriptions are minimal (10-60 chars) and lack LLM-optimized guidance. Tool names follow verb_noun pattern (search, discover, check) but descriptions do not explain WHEN to use each tool or what makes them distinct. Parameters have types and enums (language, region) but lack actionable constraint descriptions. No output schema documentation visible. Error handling and recovery guidance absent.
Discover emails and social contacts for a list of domains or business names. HTTP GET /emails-and-contacts
Search for businesses on Google Maps with specific criteria. HTTP GET /google-maps-search
Verify if the API key is valid and check account balance. HTTP GET /profile-balance
Descriptions are too brief (10-60 chars) and lack LLM-optimized guidance. 'Search for businesses on Google Maps with specific criteria' does not explain WHEN to use this vs other search tools, what the output contains, or how to chain results to downstream tools.
No output schema documentation. LLMs cannot infer what fields are returned (e.g., does google_maps_search return business_id, address, rating, phone?). This forces agents to guess and risks failed downstream tool calls.
Parameter descriptions are missing or generic. 'query' parameter lacks guidance on format (free text? domain names? business names?). 'limit' has no min/max bounds. 'language' and 'region' enums are extensive but lack examples of common values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
No error handling or recovery guidance. If an API call fails (invalid API key, rate limit, malformed query), the tool provides no actionable next steps for the LLM.
Tool names contain 'and' (emails_and_contacts) signaling multiple responsibilities. Consider splitting into separate tools: discover_emails and discover_social_contacts, so agents can compose them independently.