Loading ToolBench
A browser extension toolkit providing AI-powered text selection tools with floating toolbar UI, provider selection, and model management
This MCP server exhibits significant quality gaps typical of community-grade tools. All four tools have basic JSON Schema definitions with type and required fields present, but lack critical production-grade patterns. Descriptions exist but are generic and do not follow LLM-optimized guidance (one is 14 chars, one is 89 chars, best is 195 chars). No tool has documented output schemas. No error handling guidance. No parameter validation rules or examples. The server appears to be a browser extension or client-side tool (references 'background/tools', React components, no visible MCP transport layer), which suggests it may not be a true MCP server at all but rather a client-side tool wrapper. Critical pattern violations: (1) continue_message tool is meta-reasoning rather than domain action, this is anti-pattern for production MCP; (2) no composition guidance between web_search, google_search, and web_fetch, why three search tools?; (3) descriptions lack 'when to use' context and dependency hints; (4) no output schema documentation for any tool; (5) no security model or permission gates visible.
Use this tool to continue your response in a new message chunk. This is useful when you have more to say but want to break it up, or if you want to perform a chain of thought before the next response.
Search the web using Google. Use this to find current information, news, facts, or any topic that requires up-to-date web search results.
Fetch the content of a specific URL and return it as markdown. IMPORTANT: web_fetch WILL FAIL for authenticated or private URLs (e.g. Google Docs, Confluence, Jira, GitHub private repos). Use specialized MCP tools for those instead. Usage notes: - HTTP URLs will be automatically upgraded to HTTPS - Long pages will be truncated - Binary content (PDF, images, video) is not returned — attach files instead or pick a text/HTML URL
Search the web for up-to-date information. Returns a synthesized answer with source citations. Use for current events, recent docs, or any time-dependent facts.
continue_message tool is meta-reasoning anti-pattern, it does not perform domain work but instead instructs the LLM to break responses. This violates the principle that each tool should map to a user action. Remove or relabel as internal prompt-engineering only, not exposed to agents.
Three search/fetch tools (google_search, web_search, web_fetch) with overlapping semantics and no composition guidance. google_search vs web_search differ only in backend (Gemini vs xAI grounding), but descriptions do not explain when to prefer one. This creates ambiguity for LLM tool selection. Consolidate to one canonical search tool or clearly document the distinction in 'when to use' sections.
No output schemas documented. All tools have 'description' fields but none include structured output specifications. LLMs cannot plan downstream tool calls or extract typed fields. For example, web_fetch returns markdown but does not specify fields like 'content', 'title', 'url', 'fetched_at', 'truncated', etc. Each tool MUST include 'returns' documentation with field names, types, and descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
continue_message description is only 14 characters descriptive content after stripping preamble. This is well below the 34-char baseline (p10) and violates minimum guidance of 20+ chars for meaningful description. Expand to explain what 'break up' means, when an LLM should invoke it, and what the user sees.
No error handling guidance. Tool descriptions do not explain what errors are possible, what they mean, or what the agent should do in response. For example, web_fetch warns about 'authenticated or private URLs' but does not include a recovery path (e.g., 'Use specialized MCP tools or request user credentials'). No categorization of errors as retryable, user-fixable, or fatal.
Parameter descriptions lack format specifications and validation rules. 'query' is described as 'The search query to look up on the web' but does not specify max length, character restrictions, or example format. 'allowed_domains' in web_search lacks guidance on format (FQDN? with or without http? wildcard support?). Descriptions should include constraints like '1-2000 characters, alphanumeric + punctuation, no URLs'.
web_fetch tool description includes usage notes but as prose rather than structured constraints. 'HTTP URLs will be automatically upgraded to HTTPS' is an implementation detail that should be invisible or documented in error handling. 'Long pages will be truncated' should specify the limit (e.g., '10KB') and what the response includes (e.g., 'truncated: true, bytes_available: 50000').
No visible transport layer or MCP protocol implementation in source code. Code structure suggests a browser extension (React components, 'background' folder, no MCP imports visible) rather than a true MCP server. Cannot assess protocol compliance without evidence of MCP endpoints, transport handling, or tool registration via MCP initialize/call protocol.