Loading ToolBench
MCP server with Brave Search and Anthropic Claude integration
The server implements 3 tools with basic Zod schemas and descriptions, but exhibits significant quality gaps across naming, parameter documentation, output schema clarity, and error handling. Tool names lack action verbs (search is acceptable, but weather and chat are domain-specific rather than verb_noun pattern). Parameter descriptions are minimal or missing critical constraints. Output schemas are not formally documented, tools return JSON text blobs rather than structured MCP content objects. Error messages are generic and offer no recovery guidance. The chat tool definition is particularly problematic: it accepts a complex nested object (context.searchResults) without validating the structure, and the tool's purpose relative to search is ambiguous.
Chat with Claude about search results
Search the web using Brave Search
Get weather forecast from OpenWeatherMap
Tool 'weather' and 'chat' do not follow verb_noun naming convention. 'weather' is a domain noun, not an action. 'chat' is too generic. Recommended: 'get_weather' and 'send_chat_message' or similar action-based names.
Parameter 'postalCode' in weather tool is marked optional but its purpose is unclear. The tool description does not explain when to use postalCode vs city, or if both are required, or if they are mutually exclusive. This dependency is undocumented.
Chat tool accepts 'context' object with 'searchResults' array, but the schema does not validate the structure of searchResults items. No documentation on what fields are expected in each result object (title, url, description are assumed but not enforced). LLM cannot know if passing arbitrary objects will succeed.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Output schemas are not documented. Tools return JSON text wrapped in MCP text content, but the structure of that JSON is not formally declared. LLMs cannot plan downstream calls or extract fields reliably. For example, search returns { results: [...] } but this is not documented in the tool schema.
Error handling is generic and offers no recovery guidance. When Brave Search fails, the tool returns a text blob 'Error searching the web: ...' without telling the LLM whether to retry, adjust the query, or give up. No error categorization (retryable vs user-fixable).
Search tool has no limit on results count. The Zod schema accepts any string for 'query' without length constraints. The Brave API is called with resultsCount from config, but if that config value is high (e.g., 1000), the response will bloat and waste tokens. No pagination support (no offset/limit params).
Weather tool description does not clarify WHEN to use it or what 'postalCode (optional)' controls. Is it a fallback if city is ambiguous? Does it filter results by postal code? The description is too vague: 'Get weather forecast from OpenWeatherMap' without specifying scope, prerequisites, or how the optional param changes behavior.
Chat tool description does not explain its relationship to the search tool, or when the LLM should call it. Is it meant to synthesize search results? Summarize them? Have a freeform conversation? The purpose is ambiguous and the tool seems redundant, agents could just call search and reason about results without a separate 'chat' wrapper.
Parameter descriptions lack format/constraint guidance. 'query' in search has minLength=1 in Zod schema but the description does not mention this constraint. LLMs cannot see JSON Schema, they rely on description text. Also, no guidance on query format (free text vs structured syntax), maximum length, or special characters.
No support for tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools are read-only and should declare this via tool annotations so clients can optimize caching and retry logic.