Loading ToolBench
MCP server for OpenRouter web search
Single tool server with adequate but incomplete definition quality. The search_web tool has a clear verb-based name and reasonable schema with proper typing, but critical gaps exist in descriptions, parameter documentation, and error handling guidance. The tool description is functional but lacks context on when/why to use it vs alternatives. Parameters lack actionable constraints and dependency hints. Output schema is undocumented, LLMs cannot predict return structure for downstream reasoning. Error handling exists but provides no recovery guidance. Security baseline met (API key injected via environment), but no rate limiting or input sanitization documented.
Search the web using OpenRouter and return relevant results
Output schema undocumented, LLMs cannot predict return structure or plan downstream steps. No documentation of what fields SearchWebResult contains, field types, or pagination behavior.
Tool description lacks actionable context. '217-char description does not state WHEN to use this tool vs other search options, WHAT format results are in, or consequences of calling it. Missing dependency hints (e.g., 'This tool requires OpenRouter API key to be configured').
Parameter descriptions lack actionable constraints. 'focus' parameter has enum constraint visible in schema but description does not explain what 'technical' vs 'development' vs 'general' actually filter, LLMs must guess the semantic difference. 'num_results' description states range (1-10) but not what happens at boundary values or why 10 is the cap.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Error handling provides no recovery guidance. Code catches Zod validation errors and generic errors but returns raw error text: 'Invalid parameters: ...' and 'Search failed: ...'. LLMs cannot determine if error is retryable, user-fixable, or fatal. No suggestions for next steps (e.g., 'Try a shorter query', 'Check API key configuration').
No rate limiting, timeout specification, or runaway protection documented. External API calls (OpenRouter) have no visible timeout or retry bounds. Agent could exhaust quota or hang indefinitely without safeguards.
Output from openrouter.ts (SearchWebResult structure) is not documented in tool schema. Code returns JSON.stringify(result, null, 2) but LLMs have no formal schema of what result contains, whether it's {results: [], metadata: {}} or {items: [{title, url, snippet}]} etc. This forces LLMs to infer structure from examples, degrading accuracy.
No input sanitization or constraint validation beyond Zod schema. If OpenRouter API is vulnerable to injection attacks (unlikely but possible with plugin parameters), untrusted user queries pass through directly. Code should validate/escape search_prompt generation in utils.ts.