Loading ToolBench
Deep research MCP server for AI developers with 39 academic, web, developer, and Chinese-source channels
AutoSearch exposes 21 tools with basic schemas and descriptions, but lacks depth in LLM-optimization patterns. Most tool descriptions are present (194 - 220 chars on average) but generic and repetitive. Parameter schemas are present in the tool list but validation against the actual source code reveals that tool implementations and input validation details are not visible in the provided code sample, only metadata from check_mcp_tools.py is shown. Critical gaps: no tool annotations (readOnlyHint/destructiveHint despite 'WRITE' risk labels), no per-tool error recovery guidance, descriptions do not guide LLM selection (why clarify vs channel vs skills?), no batch/pagination patterns despite operating on result collections. Naming is verb-noun consistent but many tools are domain-specific and would benefit from clearer dependency ordering (e.g., 'loop_init must be called before loop_update'). Most tools score 40 - 55 individually due to present-but-underdeveloped schemas and descriptions.
Add a URL to a citation index with title and source metadata
Create a new citation index for tracking and deduplicating URLs
Export a citation index as a formatted Markdown reference list
Merge one citation index into another, deduplicating URLs
Manage context retention and memory policies for long-running research sessions
Delegate a research subtask to be handled by the agent
Run diagnostic checks on the AutoSearch installation and channel configuration
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite marking tools with Risk labels (READ_ONLY vs WRITE). Annotations are CURRENT MCP spec 2026-07-28 and enable agents to plan side effects correctly.
Descriptions are generic and do not clarify LLM decision points. 'Invokes the Clarifier to analyze and understand a search query' (run_clarify) does not explain when to call it vs run_channel or perspective_questioning. When should the LLM call it instead of a similar tool?'
No documented error recovery guidance in tool descriptions. If run_channel returns empty results, the description does not guide the agent on next steps (e.g., 'Try a different channel from list_channels or refine the query via run_clarify').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Generate a search plan using graph-based reasoning
Health check tool for MCP server status
Lists all available search channels with their current status and configuration
Lists available research skills (channels, tools, and meta-skills) with metadata and filters
Add a newly identified information gap to the research loop
Identify information gaps in the current research loop state
Initialize a research loop context for multi-turn research sessions
Update the state of an active research loop with new findings
Generate perspective-based follow-up questions to deepen research
Fuse recent signals from multiple sources to identify emerging trends
Runs a single search channel against a query and returns evidence results
Invokes the Clarifier to analyze and understand a search query, determining mode, query type, and channel priorities
Select and filter which channels to use for a research session
Harvest and trace evidence collection across channels for debugging
Loop tools lack documented parameter dependencies. loop_update and loop_add_gap both require loop_id (generated by loop_init), but descriptions do not state 'Call loop_init first' or explain the stateful workflow.
No pagination or limit parameters on tools returning collections (e.g., list_skills, list_channels).
Parameter descriptions lack format and constraint details. 'mode_hint' in run_clarify states 'Optional search mode hint (fast, deep, or comprehensive)' but does not declare this as an enum constraint. Formal constraints are machine-parseable and prevent the LLM from treating examples as the only valid options.'
No documented output schemas in tool descriptions. The code shows RunChannelResponse and ResearchResponse models, but tool descriptions do not state what fields are returned, which IDs are included, or whether results are paginated. LLMs need to know what fields to expect so they can plan downstream tool calls.'
'delegate_subtask' has a vague purpose and combines multiple concerns. Description does not clarify what 'delegating' means (execute a sub-plan? queue for later? return control to user?). Split into separate tools so each has one clear job.'
Composition gaps: run_channel's output references 'channel_empty_calls' and 'routing_trace' which are opaque to agents. If an agent needs to try a different channel after run_channel fails, does it get a list of alternative channels, or must it call list_channels again?
No idempotency guarantees documented. Multi-call tools like citation_add, loop_update, delegate_subtask should state whether repeated calls with the same parameters produce the same result or cause duplicate side effects.