Loading ToolBench
A Model Context Protocol (MCP) server implementation that integrates with SerpApi for comprehensive search engine results and data extraction
The `search` tool has an exceptionally detailed description (1200+ chars) with clear WHEN-to-use guidance, engine discovery via resources, and examples. Input schema is present with type and description for both `params` (object) and `mode` (string). However, the four UI variant tools (search_table, search_dashboard, search_flights, search_hotels) have minimal descriptions (under 100 chars) and identical generic input schemas with no engine-specific parameter documentation. The `params` parameter across all tools lacks granular type constraints (no enum for engine names, no min/max for numeric params). Output schema is documented for `search` but not for the UI variants. Error handling is well-designed with actionable recovery messages (rate limit, auth, forbidden), but only visible in the text tool implementation, not reflected in tool definitions.
Universal search tool supporting all SerpApi engines and result types. When to use: - Any query needing live, structured SERP data: web results, news, product listings, job postings, local businesses, flight/hotel prices, video results, images, stock/weather cards, knowledge graph entities. Engine discovery via MCP resources: - serpapi://engines lists all engines supported by this tool. - serpapi://engines/<engine> provides engine-specific parameters and supported options. - Example: serpapi://engines/google_news Input schema: params: JSON object containing SerpApi engine parameters. Common parameters: - q: Search query. Required for most engines. - engine: SerpApi engine name. Defaults to "google_light". - location: Optional geographic location for localized results. - output: Optional response format. Omit for JSON (default), or set to "md" for Markdown. Engine-specific parameters are available via MCP resources: - serpapi://engines lists all supported engines. - serpapi://engines/<engine> provides parameters and options for one engine. mode: Response mode. Defaults to "complete". - "complete": Return the full SerpApi response. - "compact": Remove metadata fields from JSON responses. Markdown is returned unchanged. Output schema: structuredContent.result contains the response string: serialized JSON or unchanged Markdown. The same string is included in text content. Tool failures preserve this wrapper and set isError to true. Guided search: Searches can request missing engine parameters from supporting clients using the engine catalog and engine-specific rules. Flights collect airports and dates, hotels collect the destination and stay dates, and directions collect missing endpoints. Other clients receive a missing-parameter error. Cancellation does not run a search. Examples: Weather: {"params": {"q": "weather in London", "engine": "google"}, "mode": "complete"} Stock: {"params": {"q": "AAPL stock", "engine": "google"}, "mode": "complete"} General: {"params": {"q": "coffee shops", "engine": "google_light", "location": "Austin, TX"}, "mode": "complete"} Compact: {"params": {"q": "news"}, "mode": "compact"} Markdown: {"params": {"q": "news", "output": "md"}} Supported engines include (not limited to): - google - google_light - google_flights - google_hotels - google_images - google_news - google_local - google_shopping - google_jobs - bing - yahoo - duckduckgo - youtube_search - baidu - ebay
Four UI variant tools (search_table, search_dashboard, search_flights, search_hotels) have descriptions under 100 characters with no guidance on WHEN to use them vs. the base `search` tool or each other. LLMs cannot distinguish between them.
The `params` parameter across all tools accepts a free-form JSON object with no enum constraint on the `engine` field. LLMs will hallucinate invalid engine names instead of selecting from the documented list (google, google_light, google_flights, etc.).
Output schemas are documented only for the `search` tool. The four UI variant tools have no documented return type, forcing LLMs to guess what fields are available for downstream reasoning.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Interactive dashboard UI variant of search tool with metrics, charts, and detailed result inspection
Interactive flights search UI with price insights, itinerary details, and booking information
Interactive hotels search UI with property details, pricing, and availability information
Interactive table UI variant of search tool for displaying organic search results in a structured table format
The `mode` parameter description lacks clarity on the difference between 'complete' and 'compact' for non-JSON outputs (e.g., Markdown). The description states 'Markdown is returned unchanged' but does not explain when an LLM should choose compact mode.
Error handling logic (map_search_error, extract_error_response) is implemented in the tool code but not reflected in the tool definition. LLMs have no visibility into what error messages to expect or how to recover from rate limits, auth failures, or API errors.