Loading ToolBench
Web research MCP server for AI agents — search, fetch, and synthesize web content via Model Context Protocol.
The server demonstrates solid tool design with verb-based naming (web_search, fetch_page, research_topic), comprehensive parameter schemas using Zod, and clear descriptions. All three tools have well-structured input schemas with proper type constraints and descriptions. However, there are gaps in output schema documentation and error handling guidance that prevent a higher score. The tools follow good composition patterns (single responsibility, proper chaining) and accept reasonable parameters. Descriptions are LLM-optimized and contextual (50-200 chars range). The implementation uses current SDK patterns (StreamableHTTPServerTransport, stateless server creation per request) but lacks tool annotations (readOnlyHint, idempotentHint) and comprehensive error recovery guidance.
Fetch a URL and return the main text content. Use extractMode="article" for article text (default), "full" for entire body, "links" for all links. Strips navigation, ads, scripts, and boilerplate.
Multi-step research: search the web, fetch top results, score relevance, deduplicate, and return a synthesis with key facts from each source. Use this to get a thorough answer backed by multiple sources in a single call.
Search the web and return structured results (title, URL, snippet). Use Brave Search API when configured, falls back to DuckDuckGo. Use this when you need to find pages about a topic before reading them.
Missing output schema documentation. Tools return structured responses with 'content' and 'structuredContent' fields, but the output schema is not documented in the tool definitions. LLMs cannot predict downstream field availability or plan multi-step chains.
Weak error recovery guidance. Catch blocks return generic error text ('Error: {message}') without categorization (retryable vs user-fixable) or actionable next steps. An LLM hitting a network timeout sees 'Error: ECONNREFUSED' with no guidance on retry strategy.
No tool annotations. All three tools are READ_ONLY (no side effects), but this is declared only in the prompt metadata, not via tool annotations (readOnlyHint). LLMs cannot reliably infer idempotence or safety from tool names alone.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 69 | - | v1 |
Missing pagination/limit enforcement documentation in fetch_page. The tool accepts a URL and returns content, but there is no explicit statement of maximum response size or guidance on what happens if content exceeds token limits. Large documents risk context window exhaustion.
research_topic naming ambiguity. The name 'research_topic' does not start with a clear action verb (search_, fetch_, get_). It reads more like a noun (a topic to research) than an action. Clearer names would be 'search_and_synthesize' or 'research_and_summarize', though the latter violates single-responsibility. Consider 'synthesize_topic' or 'gather_research'.