Loading ToolBench
Production MCP server for multi-agent AI research with OpenRouter, featuring deep research capabilities, vector search, and knowledge graph integration
This server exhibits significant definition quality issues across 33 tools. While tool names generally follow verb_noun patterns (conduct_research, fetch_url, list_models), many lack descriptions entirely or provide minimal guidance. Input schemas are present for most tools but are often incomplete, many parameters lack type information or descriptions. The server attempts to cover a broad research/orchestration domain but spreads implementation thin: tool definitions are scattered across multiple files (mcpServer.js, tools.js, test files), making maintenance difficult. Critical gaps include missing output schema documentation, minimal error recovery guidance, and inconsistent parameter annotation. The 'zero_chat' and 'elicitation_respond' tools appear to be self-referential protocol tools rather than domain tools, indicating confused scope. For a production research server, this falls short of the quality baseline (194 chars avg description; 100% param annotation in A+ tools).
Backup the research database
Conduct multiple research queries in parallel
Perform mathematical calculations
Cancel an async research job
Conduct comprehensive research on a given topic using multiple AI agents and sources
Get current date and time information
Check database health and performance metrics
Critical naming ambiguity: Generic tool names ('search', 'query', 'retrieve', 'calc') violate verb_noun specificity and invite hallucination. Example: 'search' could mean web search, knowledge base search, or tool search; 'query' could mean SQL, Elasticsearch, or REST.
Missing output schema documentation: Tools like search_web, list_models, search_index, list_tools, date_time, get_job_status do not document their response structure. LLMs cannot plan downstream tool calls or extract fields without knowing what data is returned.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | 1.27.1+ | v1 |
Respond to user elicitation requests
Export research reports in specified format
Fetch and parse content from a URL
Get status of an async research job
Retrieve similar past research reports from the database
Retrieve the full content of a research report
Get current status of the MCP server and its services
Import research reports from specified format
Get status of the document indexing system
Index text documents in the knowledge base
Index content from a URL
List available AI models from OpenRouter with pricing and capabilities
List research history with optional filtering
List all available MCP tools
Execute SQL-like queries on research data
Rate and provide feedback on a research report
Reindex vector embeddings in the database
Alias for conduct_research - comprehensive research on a topic
Ask follow-up questions on previous research to deepen understanding
Retrieve specific research data by ID
Request LLM completion from the client via sampling
Search knowledge base for relevant documents
Search the indexed documents using hybrid search
Search available tools by name or description
Search the web for information on a given topic
Zero Protocol self-referential chat interface for dual-role node communication
Protocol tools exposed as domain tools: 'sample_message' and 'elicitation_respond' appear to be MCP protocol mechanisms (sampling, elicitation), not research domain tools. This violates separation of concerns and confuses what the server's actual capability domain is.
Sparse parameter descriptions: Many tools lack detailed parameter descriptions. Example: 'queryFilter' in list_research_history has no type hints (is it regex? substring? exact match?). 'timezone' in date_time has no validation (IANA TZ format?).
Minimal descriptions (under 50 chars): Tools like 'search', 'query', 'retrieve', 'calc', 'db_health', 'reindex_vectors' have descriptions under 50 characters, lacking context for when/why an LLM should call them. Rubric baseline: 194 chars average for A+ tools.
No pagination guidance: Tools returning lists (search_web, list_research_history, batch_research results) lack documented pagination (limit max?, has_next?, offset vs cursor?). Rubric pattern: tools returning lists should support page/limit and return total count.
Alias tool 'research' creates confusion: Package.json registers 'research' as an alias for conduct_research, but it appears as a separate tool in tool list with truncated schema. Aliases should be transparent to agents, not exposed as duplicate tools.
Missing error recovery guidance: Error handling specifications are absent or minimal. Example: What happens when a URL fetch times out? When a database backup fails? Should agents retry?
Destructive operations lack confirmation: Tools like 'backup_db', 'reindex_vectors', 'import_reports' (overwrite?), 'cancel_job' are potentially irreversible but have no mention of dry-run or confirmation. Rubric pattern: irreversible operations should support confirmation.
Tool definition scatter: Tool definitions are spread across src/server/mcpServer.js, src/server/tools.js, and test files (tests/test-mcp-tools.js). Per tooling best practices, all canonical definitions should live in a single registry or well-organized module to prevent definition drift and maintenance errors.