Loading ToolBench
Model Context Protocol server — exposes degoog search as an MCP tool for AI clients
Single tool 'search' has a well-defined schema with proper types and descriptions for all parameters. Tool name is action-oriented (verb_noun pattern). However, the tool description is generic (47 chars, below the 50-200 char LLM-optimized range), lacks context on when to use it vs alternatives, and does not document output structure. Parameter descriptions are present but minimal (e.g., 'Page number (default: 1)' lacks range constraints). No output schema is documented. Error handling in the implementation returns text responses but lacks actionable recovery guidance for LLMs. The tool is read-only and safe, but definition quality falls short of production standards.
Search using degoog search aggregator
Tool description is too brief (47 chars) and lacks LLM-optimized context. Should explain WHAT it does, WHEN to use it, and what structure is returned. Current: 'Search using degoog search aggregator', missing actionable guidance.
Output schema is not documented. LLMs cannot plan downstream calls or extract fields without knowing the response structure (title, url, snippet, sources, relatedSearches). Add explicit output schema to tool definition.
Parameter 'page' lacks range constraints. Description says 'default: 1' but does not specify min/max (e.g., 1 - 100). LLMs may pass absurd values. Add explicit bounds.
Error responses are plain text without recovery guidance. E.g., 'Search failed with status 500' tells the LLM nothing actionable. Should include: error category (retryable/user-fixable/fatal), what went wrong, and next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Parameter descriptions lack format/constraint details. E.g., 'time' accepts 'any, hour, day, week, month, year, custom' but description does not clarify what 'custom' requires or how to use it. Replace examples with enum constraints.