Loading ToolBench
Perform deep research on a topic using AI-powered web search with recursive query expansion, source reliability evaluation, and comprehensive reporting
Single tool 'deep-research' has a well-structured schema with proper type definitions, enums via min/max constraints, and reasonable descriptions. Tool naming is action-verb-based ('deep-research' as verb phrase). However, descriptions lack depth and guidance for LLM selection. Parameter descriptions are present but minimal (10-30 chars), below the 72-char production baseline. Output schema is documented in code but lacks explicit schema documentation in the tool definition itself. Error handling is basic (try-catch returns isError flag) with no recovery guidance. No tool annotations for destructive/readonly hints despite the tool being READ_ONLY. The implementation shows competent engineering but misses several LLM-optimization patterns.
Perform deep research on a topic using AI-powered web search
Tool description lacks LLM-selection context. Current: 'Perform deep research on a topic using AI-powered web search' (68 chars). Should explain WHEN to use (vs manual search), WHAT to expect (time, structure), and key capabilities (web search with AI synthesis). Production baseline: 194 chars average.
Parameter descriptions are under 30 chars each, below the 72-char production baseline. 'How deep to go...' (30 chars) and 'How broad to make...' (25 chars) lack actionable guidance. Should explain: impact on time/cost, what 'depth' means semantically (breadth-first vs depth-first search tree), and when to use low vs high values.
Tool declares READ_ONLY risk but schema has no tool annotations (readOnlyHint=true, idempotentHint=true). Code uses server.tool() registration but does not set these hints in the tool definition. Modern MCP servers (spec 2026-07-28) should declare annotations to guide agent planning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error handling returns bare error messages without recovery guidance. 'Error performing research: <message>' tells the LLM nothing about retry strategy, user action, or next steps. Production pattern: 'Invalid query: <constraint>. Try with 1-5 depth/breadth values.' or 'Network timeout. Retry with reduced breadth to lower concurrent requests.'
Output schema (metadata.stats, learnings, visitedUrls) is documented in code but not exposed in a schema field of the tool definition. LLMs cannot plan downstream use of stats without explicit schema. Should document return type: {content: [{type, text}], metadata: {learnings: [], visitedUrls: [], stats: {totalLearnings, totalSources, averageReliability}}}.
No pagination or result-limiting guidance. Tool can return arbitrary number of learnings and visited URLs in metadata. If a research query yields 500+ sources, returning all in metadata wastes tokens and dilutes signal. Should cap to top 20-50 and document in description: 'Returns up to 50 most relevant sources and learnings.'