Loading ToolBench
A Model Context Protocol (MCP) server implementation that provides real-time web search capabilities through a simple API
Single tool with adequate schema definition and parameter coverage, but significant issues with description quality, redundancy, and lack of structured output documentation. The tool name 'web_search' is appropriately verb-noun formatted and clear. Input schema is fully typed using Zod with all parameters documented. However, the description is verbose, repetitive, and contains a confusing retry instruction ('If you request search with 1 result number and failed, retry with bigger results number') that should not appear in tool descriptions. Output schema is not formally documented, responses are returned as JSON text within a content block rather than a structured, typed object. No error handling guidance is provided to help agents understand how to recover from failures. The tool accepts reasonable parameters (query, numResults with smart default, language, region, domain filters, result type enum) but lacks output pagination and result count constraints that would prevent context window exhaustion.
Search the web for information. Use this tool when you need to search the web for information. You can use this tool to search for news, blogs, or all types of information. You can also use this tool to search for information about a specific company or product. You can also use this tool to search for information about a specific person. You can also use this tool to search for information about a specific product. You can also use this tool to search for information about a specific company. You can also use this tool to search for information about a specific event. You can also use this tool to search for information about a specific location. You can also use this tool to search for information about a specific thing. If you request search with 1 result number and failed, retry with bigger results number.
Tool description is verbose and repetitive (400+ chars with 6 near-identical statements: 'You can also use this tool to search for information about a specific X'). Violates pattern:tool-description guidance (10-1024 chars, LLM-optimized 50-200 chars). Also includes procedural instruction ('If you request search with 1 result number and failed, retry with bigger results number') that belongs in error handling, not the description.
Output schema is undocumented. Tool returns JSON text wrapped in a content block, but the structure (query field, results array with title/snippet/text/url/siteName/byline fields) is not formally defined. LLMs cannot plan downstream tool calls or extract data reliably without documented response types. Violates pattern:tool (D. SCHEMAS & OUTPUT).
No pagination, result limits, or context-window protection. Tool accepts arbitrary numResults and returns all results as JSON text. No documented cap on results per call. For large result sets, this will exhaust context windows and degrade LLM reasoning. Pattern mxe:enforce-result-limits recommends capping at 20-50 items and offering pagination.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Error responses lack recovery guidance. Code catches axios errors and returns raw error messages (e.g., 'Error: Network Error') with no actionable next step for the agent. Pattern:recovery-guide requires errors to tell the LLM what to do next (e.g., 'Search failed: API timeout. Retry with fewer results or try a simpler query.').
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). This tool is read-only and idempotent, MCP spec allows annotating these properties so clients can optimize caching and retry logic. Omitting annotations forces clients to guess or apply conservative retry policies.