Loading ToolBench
An MCP server that provides web search and web crawling capabilities using the Tavily API
Server has 2 tools with basic structure but significant quality gaps. Both tools have short, generic descriptions (13-17 chars) that fall well below the 50-200 char baseline for LLM-optimized descriptions. Input schemas are present and properly typed, but parameter descriptions are minimal or missing context. Output schemas are not documented. Error handling is minimal, tools return empty lists or None on failure without recovery guidance. The server relies on Tavily API integration but does not abstract API complexity or document expected output structure for downstream tool chaining.
crawl the web through url and extract the content.
search on web
Tool descriptions are critically short (13-17 characters). 'search on web' and 'crawl the web through url and extract the content.' do not answer WHAT the tool does (vague), WHEN to use it instead of the other tool (no differentiation), or what it returns (missing). Baseline for LLM-optimized descriptions is 50-200 chars; these are <5% of the minimum.
Output schemas are not documented anywhere. web_search returns formatted strings with no type annotation; web_crawl returns List[Dict] with internal structure visible only in code (title, raw_content, url, favicon). LLMs cannot plan downstream calls or know what fields to expect. Baseline: 100% of A+ tools have documented return types.
Error handling is missing. web_search returns None or empty list on API failure with no guidance. web_crawl returns empty list on any error. Agents cannot distinguish between 'no results found' and 'API failed' and have no recovery path. Baseline: errors must tell the LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Parameter 'topic' in web_search is constrained to enum [general, news, finance] but this constraint is not documented in the parameter description. The description 'Topic category for search' is generic and does not explain the valid values or when to use each. Baseline: describe expected format, range, and allowed values directly in parameter description.
Parameter descriptions are minimal or generic. web_search: 'The search query string' and 'Topic category for search' are bare. web_crawl: 'The URL to crawl' lacks context on expected format (http/https, full URL vs domain). 'Optional instruction' does not explain what kind of instruction (CSS selector? Natural language? Regex?). Baseline: average param annotation is 72 chars; these are 10-30 chars.
Tool names web_search and web_crawl are adequate (action verbs) but do not clearly differentiate use cases. Both tools interact with the web, the description should explain when to use search (find information) vs crawl (extract content from a specific page). Current descriptions do not guide this decision.
No result limits documented. web_search returns all results from Tavily API without pagination or cap. web_crawl returns all formatted results without limit. Returning unbounded results can blow context windows. Baseline: cap results at 20-50 and offer pagination; state the limit in description.
Response fields are not consistent or documented. web_search returns formatted strings (Title\nContent\nURL); web_crawl returns structured dicts with title, raw_content, url, favicon. Inconsistent return types make it hard for LLMs to compose tools or extract specific fields. Baseline: return structured objects with typed fields; document the schema.