Loading ToolBench
A comprehensive Model Context Protocol (MCP) server suite for academic research workflow automation. Includes 6 specialized servers for complete research pipeline from question refinement to report generation.
The Academic Research MCP Suite has three tools with moderate structural issues. All tools have descriptions and input schemas, but several are generic or incomplete. Parameter descriptions are present but lack specificity about formats, ranges, and constraints. The 'run' tool has high-risk destructive capabilities (code execution) with minimal safety guardrails. No tool annotations (readOnlyHint/destructiveHint) are present despite clear risk profiles. Output schemas are not documented in the provided code. Error handling is not visible, no recovery guidance or input validation shown. The suite targets a specialized domain (academic research) but the tool interface does not consistently match how researchers naturally express their workflows. STDIO transport caps the overall score.
Generates analysis scripts including EDA, correlation, and regression analysis based on research hypotheses
Refines research questions, develops hypotheses, and operationalizes concepts.
Executes analysis scripts in a specified environment
Tool 'run' executes arbitrary code (Python, R, Node) with minimal safety constraints. No permission gates, no dry-run option, no audit logging visible in the source. This is a critical security risk, an LLM could be tricked into running malicious code.
Tool 'run' has generic description: 'Executes analysis scripts in a specified environment.' Does not state that this is irreversible, that code execution is a destructive operation, or that retries could duplicate side effects. Missing destructiveHint annotation.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in any tool definition. The 'refine' and 'generate' tools are marked as READ_ONLY in metadata but not via structured tool annotations; 'run' is marked IRREVERSIBLE but has no corresponding hint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2025-06-18+ | v2 |
Parameter 'references' in 'refine' tool is an array of strings but the description does not specify the expected format: Are these full citations? DOIs? URLs? Unclear how the LLM should format reference materials.
Parameter 'environment' in 'run' tool has enum=['python', 'r', 'node'] with default='python', but no description of what each environment means, what libraries/versions are available, or why a user would pick one over another.
Output schemas are not documented in the source code. For 'refine', what structure does it return? A refined question string? A JSON object with hypotheses and definitions? LLMs cannot plan downstream tool calls without knowing the response shape.
No error handling or recovery guidance visible in the source. If 'run' fails (syntax error, timeout, permission denied), what does the LLM see? Stack trace? Plain error message? No guidance on how to recover or what to try next.
Tool 'run' accepts a 'scripts' parameter as a free-form object mapping filename to script content. No validation that filenames are safe (could contain path traversal like '../../../etc/passwd'). No validation that scripts are syntactically correct before execution.
Tool naming: 'refine', 'run', and 'generate' are vague action verbs without clear objects. 'refine' → could mean refine question, hypothesis, design. 'run' → could mean run code, run analysis, run experiment. Consider 'refine_research_question', 'execute_analysis_script', 'generate_analysis_script' for clarity.
The 'data' parameter in 'run' is described as 'Path to data file for analysis' but does not specify: absolute or relative path? What file formats are supported? Where should the file be located? Does the path need to exist beforehand? This ambiguity invites LLM errors.