Loading ToolBench
An MCP server that conducts multi-perspective autonomous research using the STORM (Synthesis of Topic Outlines through Retrieval and Multi-perspective question asking) methodology to generate comprehensive research reports with verified citations and hierarchical chapter structures.
This MCP server has severe definition quality issues across nearly all dimensions. The source code reveals two tools with minimal structure, no proper schema definitions, and descriptions that barely meet the threshold for recognizable intent. Tool definitions appear to be inferred rather than explicitly registered with proper JSON Schema. The implementation consists of a bare-bones mcp_server.py that outputs static JSON and a client.py with a single method that returns hardcoded mock data. Neither tool has proper input validation, parameter descriptions, or documented output schemas. The server does not implement proper MCP protocol message handling, it merely prints a static status message. Tool registration is not visible in the provided code; only example usage exists. This is a non-functional MCP implementation that does not follow any of the 54 Agentic Tool Patterns.
Conducts multi-perspective autonomous research on a given topic using the STORM methodology, simulating expert perspectives and generating a comprehensive research report with verified citations and hierarchical chapters
Executes a skill action within the Multi-Perspective Autonomous Research STORM Synthesizer
No explicit tool registration with JSON Schema, tool definitions inferred only from client.py example code. execute_skill_action has no visible schema or implementation.
execute_skill_action tool has no input schema visible anywhere in source. Tool appears to be declared but never defined or invoked.
conduct_storm_research description lacks actionable context for LLM selection. No explanation of WHEN to use this tool vs similar research tools, no prerequisites stated, no guidance on output format. Description is 198 chars but reads like a feature list, not a prompt-engineering docstring.
Parameter descriptions in conduct_storm_research are minimal. 'expert_perspectives_count' description lacks constraints, no minimum/maximum, no guidance on valid range, no explanation of how this affects runtime or cost.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | 2026-07-28+ | v2 |
Output schema for conduct_storm_research is NOT documented. The mock response in client.py shows fields like 'storm_report_id', 'grounded_accuracy_score_pct', 'full_research_report_url', but no formal schema definition exists in the MCP server code.
No error handling. Tools return mocked success responses only. No guidance on failure modes, retryability, or what the LLM should do if the external STORM service becomes unavailable.
No input validation. Parameters are accepted as-is with no bounds checking. 'expert_perspectives_count' could be passed as -1, 0, or 1000 with no server-side safeguards or feedback to the LLM.
Tool composition problem: execute_skill_action and conduct_storm_research appear to serve overlapping purposes with no clear separation of concerns. No documentation explaining when to call which tool or how they compose.
Default values in conduct_storm_research parameters are example values that LLMs may reuse literally. 'Commercial Viability of Thorium Molten Salt Nuclear Reactors in 2030s' is a realistic topic that an agent might copy-paste into unrelated research requests.