Loading ToolBench
Deep research on any topic using Ollama LLMs with web search (Tavily, Perplexity, Exa)
This server has 3 tools with explicit registrations visible in src/index.ts. All three tools have descriptions and input schemas defined via Zod. However, there are critical gaps: (1) parameter descriptions are minimal or absent, (2) output schemas are not documented, (3) error handling lacks recovery guidance, and (4) the 'configure' tool exposes configuration as a writable tool without permission checks or confirmation. The server follows basic MCP registration patterns but falls short of production-grade tool quality. Tool names are reasonable (research, get_status, configure) but parameter naming and description depth are weak.
Configure the research parameters (max loops, LLM model, search API)
Get the current status of any ongoing research
Research a topic using web search and LLM synthesis
Parameter descriptions are minimal (20-70 chars) and lack actionable constraints. For example, 'maxLoops' says '(1-10)' but does not explain the cost or latency implications. 'topic' and 'llmModel' have only 28-39 chars of description.
No output schemas documented. The 'research' tool calls a Python subprocess that returns structured data (summary, sources, error fields visible in code), but the agent cannot see what to expect. The 'get_status' and 'configure' tools' return types are also undocumented.
The 'configure' tool is a WRITE operation that modifies global state (config dict) without any confirmation step, permission gate, or dry-run mode. An agent can inadvertently change the LLM model or search API, affecting all subsequent research calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Error handling is minimal. The 'research' tool validates empty topics and API keys, but errors are returned as tool execution errors (isError: true) without recovery guidance. No actionable next steps are provided, e.g., if TAVILY_API_KEY is missing, the error says so, but does not suggest checking env vars or reconfiguring.
The 'configure' tool description includes an example model name 'gemma4:31b', which violates best practice, LLMs often reuse example values literally. A constraint list (enum) of supported models should be provided instead.
The 'research' tool has a 30-minute timeout, but this is mentioned only in a code comment (line with setTimeout), not in the tool description. Agents cannot predict latency or plan timeouts intelligently.
API keys (TAVILY_API_KEY, PERPLEXITY_API_KEY, EXA_API_KEY) are validated server-side and passed via environment variables, which is correct. However, the tool descriptions do not indicate which API keys are required for each search_api option. An agent using 'exa' without EXA_API_KEY will get a confusing error.
No idempotency guarantees documented. If the 'research' tool is called twice with the same topic, will it return the same summary? Are results cached? This matters for agent retry logic.