Loading ToolBench
Google Search MCP Server - 优化版，支持双平台图片搜索、多模型AI分析、质量评分
This server has significant definition quality gaps that prevent reliable LLM usage. While all 5 tools are explicitly registered with input schemas and descriptions, the descriptions are written in Chinese and lack LLM-optimized English equivalents. More critically, parameter descriptions are minimal (often just type names), and the schemas, while present, lack proper type annotations and validation constraints. The tool names follow reasonable verb_noun patterns (google_search, fetch_url, batch_fetch_urls, search_and_extract, search_by_image), but descriptions are too brief to guide LLM decision-making. No output schemas are documented. Error handling is minimal, most handlers return plain text error messages rather than structured recoveries with next-step guidance. The server does not follow the pattern of natural identifiers (the image search tool requires file paths rather than accepting URLs or base64 strings). Tool composition is reasonable, each tool has a single clear responsibility, but the lack of chainable IDs in responses and missing pagination guidance on list operations limits multi-step agent planning.
批量提取多个网页的内容（并行处理，速度更快）
提取单个网页内容，返回标题和正文
使用 Google 搜索并返回结果
搜索后自动提取前N个结果的完整内容
上传产品图片，搜索相似产品参考图（双平台: Google + Pinterest，支持 AI 视觉分析，S/A/B/C 质量评分）
All descriptions are in Chinese only, with no English equivalents. LLMs trained primarily on English corpora may misinterpret or fail to parse these descriptions, leading to incorrect tool selection and misuse.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or parse responses without knowing field names, types, and availability. For example, google_search promises results but never documents the structure (url? title? snippet? ranking?), forcing LLMs to guess.
Error messages are plain text strings with no recovery guidance. Example: '❌ 提取失败: <error>' tells the LLM the call failed but not what to do next. Should return structured errors with categorization (retryable, user-fixable, fatal) and next-step suggestions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
search_by_image requires image_path (local file path). Violates natural-identifier pattern, users typically have URLs or base64 strings, not filesystem paths. Should accept multiple input formats or provide a separate upload tool.
search_and_extract tool name contains 'and', signaling multiple responsibilities. While the compound operation has performance benefits, the naming is ambiguous. LLMs cannot easily distinguish when to use search_and_extract vs. calling google_search + fetch_url sequentially.
No pagination support documented for any list/search tool. Even though maxResults has a cap (google_search: 25, fetch_urls unbounded), there is no next_cursor or offset for continuation. Large result sets could overflow context.
batch_fetch_urls has no documented per-item failure handling. If 1 of 10 URLs fails, does the tool return 9 results and 1 error, or does it fail entirely? Agents cannot plan recovery.
search_by_image description mentions 'S/A/B/C 质量评分' (quality scoring) and AI analysis, but the inputSchema has no way to select AI provider, model, or quality threshold. The enable_ai_analysis boolean is too coarse.