Loading ToolBench
Drop-in replacement for web_search with automatic usage tracking
mcp-tracked-search has significant definition quality gaps. While all 4 tools have names and descriptions, the descriptions contain embedded emoji and domain-specific guidance that distracts from core functionality. Parameter schemas are present for all tools, but descriptions are inconsistent. Most critically, the server lacks documented output schemas entirely, LLMs have no visibility into what these tools return. Tool compositions are reasonable (search variants + usage tracking), but error handling and response shaping are minimal.
Get comprehensive documentation for all tracked-search functions
Get current search usage statistics
💡 Architecture Check First! Enhanced web search with more options and automatic usage tracking. Consider checking Master Architecture Index or project docs first.
💡 Architecture Check First! Try Master Architecture Index or project ARCHITECTURE.md files before web search. Search the web with automatic usage tracking (drop-in replacement for built-in web_search)
No documented output schemas for any tool. LLMs cannot predict what fields to expect (web search results format, usage stats structure, help documentation format, etc.). This violates the foundational pattern:tool requirement.
Tool descriptions contain emoji (💡) and domain-specific guidance ('Try Master Architecture Index...') that adds noise and consumes tokens without clarifying what the tool does or when to use it. Descriptions should focus on functionality, not pedagogical hints.
search_usage and search_help have minimal descriptions (<30 chars for search_help, ~30 chars for search_usage). Too brief to guide LLM selection or explain purpose.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions for web_search and tracked_search are sparse. 'count' and 'offset' lack explanation of limits (1-20), pagination semantics, or defaults. 'freshness' lacks guidance on what 'all' means or when to use each option.
No error handling or recovery guidance visible in tool definitions. If Brave API fails, or daily/monthly quota exceeded, what does the LLM see? How does it recover? Code shows trackUsage() can return 'allowed: false' with 'reason' fields, but these are not documented in the tool description or output schema.
Pagination is incomplete. tracked_search accepts 'offset' but does not document what the total count or next_cursor is, so LLMs cannot know when to stop paginating or how many more results are available.