Loading ToolBench
MCP server that gives Claude Code real-time web access — Grok AI search, Tavily fetch/map, and Firecrawl screenshots, with multi-key failover.
This server has 6 tools with mixed quality. Naming is strong (verb-noun convention consistently applied). Descriptions are present for all tools and mostly adequate, though some lack specificity about when to use them vs. similar tools. Parameter schemas are well-structured with proper types and descriptions for most parameters, but several tools lack explicit output schema documentation. Error handling exists but is minimal, most tools return bare error strings rather than actionable recovery guidance. The server demonstrates awareness of patterns (e.g., session_id for source caching, pagination-aware design) but execution is incomplete. Primary gaps: (1) output schemas not formally documented; (2) error messages lack recovery hints; (3) some parameter descriptions are verbose but lack concrete constraints; (4) no parameter validation hints for edge cases like empty strings or zero values.
Retrieve the current MCP server configuration (available backends, API keys status, model info, Tavily/Firecrawl health).
When you feel confused or curious about the search response content, use the session_id returned by web_search to invoke this tool to obtain the corresponding list of information sources. Retrieve all cached sources for a previous web_search call. Provide the session_id returned by web_search to get the full source list.
Change the default Grok model for subsequent web_search calls (affects API mode only).
Fetch and parse the full content of a given URL.
Take a full-page or viewport screenshot of a given URL using Firecrawl.
Performs a deep web search based on the given query and returns Grok's answer directly. Backend is chosen automatically: local Grok Build CLI (`grok -p`, no API key needed) when installed, otherwise the OpenAI-compatible Grok API. Check `get_config_info` → active_grok_backend. This tool extracts sources if provided by upstream, caches them, and returns: - session_id: string (When you feel confused or curious about the main content, use this field to invoke the get_sources tool to obtain the corresponding list of information sources) - content: string (answer only) - sources_count: int
Output schemas not formally documented. Tools return dicts without declared output_schema in code (e.g., web_search has output_schema=None). LLMs cannot predict return field structure and must infer from descriptions or experience trial failures.
Error handling lacks recovery guidance. Functions return bare error strings like 'Invalid model: {model}' or '配置错误' (Chinese error). Errors should guide the LLM on what to do next (e.g., 'Invalid model. Call get_config_info to see available models.').
Descriptions use implicit domain knowledge. web_search description references 'Grok Build CLI' and 'grok -p' without explaining what Grok is or when to use this tool vs. generic search. get_config_info lacks any hint of what 'active_grok_backend' means or why an LLM would call it.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Parameter 'extra_sources' in web_search has no bounds or validation hint. Description says 'Default 5. Set 0 only when user explicitly wants Grok-only' but does not state the valid range. Can an LLM pass 1000? -5? Unclear.
Descriptions contain mixed languages. web_search error message '配置错误' is in Chinese; get_sources uses English. Inconsistency may confuse LLMs that expect uniform language and complicates localization.