Loading ToolBench
An MCP server for searching clinical trials, retrieving medical literature, and building RAG systems from scientific papers. Provides tools for clinical trial analysis, PDF parsing, vector store creation, and image description.
This Clinical Trials & Medical Literature MCP server has significant structural and documentation gaps that would prevent production use. Of the 7 tools declared, only 1 (parse_pdf) has a reasonably complete definition. Most tools suffer from missing or incomplete input schemas, vague descriptions, and undocumented parameter purposes. The server conflates multiple tools with similar names (ClinicalTrialsSearchTool vs tool_clinical_trial), lacks error handling guidance, and exposes local file paths as parameters without safety validation. No output schemas are documented. Tool descriptions average ~80 characters but many are generic and lack actionable guidance for LLM selection. Parameter descriptions exist but are inconsistent in quality, some explain constraints, others do not. The TOON_formater utility is well-structured but is internal utility code, not exposed as a tool definition.
Clinical trials analyst. Search ClinicalTrials.gov for trials related to a given disease / condition.
Create a RAG (Retrieval-Augmented Generation) vector store from a list of DOIs.
Provide a detailed, thorough description of an image figure.
Reads a PDF file from a specified path and extracts the text content from every page.
Searches the PubMed database for articles related to a specific topic.
Search Clinical Trials database for trials with 4 arguments.
Retrieve context from a FAISS vector store based on a query.
Duplicate/conflicting tool definitions: 'ClinicalTrialsSearchTool' and 'tool_clinical_trial' appear to do the same thing but have different parameter types (max_results is 'number' vs 'string') and different max limits (100 vs 1000). LLMs will struggle to choose between them or encounter type errors.
No output schemas documented for any tool. LLMs cannot infer what fields to expect from search_pubmed, create_rag, use_rag, or describe_figure results. This prevents downstream tool chaining and forces the LLM to parse unstructured responses.
File path parameters exposed without validation or safety guards. 'parse_pdf' accepts arbitrary local file paths; 'create_rag' accepts 'VECTOR_DB_PATH' for saving. No validation against path traversal, no mention of sandboxing or permissions. Agents could be tricked into reading/writing arbitrary files.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Inconsistent parameter typing: 'max_results' is a 'number' in ClinicalTrialsSearchTool but a 'string' in tool_clinical_trial. 'top_k' in use_rag is correctly an 'integer', but no bounds are declared. LLMs will pass invalid values (negative numbers, absurdly large counts) and tools will fail without clear guidance.
Generic, non-actionable descriptions. 'Searches the PubMed database for articles related to a specific topic' (search_pubmed) does not explain WHEN to use this vs search_pubmed + parse_pdf + create_rag pipeline. 'Create a RAG vector store from a list of DOIs' (create_rag) lacks guidance on what a RAG store is for and when it is needed in the workflow. Descriptions do not guide LLM tool selection per the pattern:tool-description baseline.
No error handling or recovery guidance. Tools do not document what happens on failure: network timeouts, invalid DOIs, PDF parsing errors, missing vector stores. LLMs receive only a generic error code and have no guidance on retryability, user fixes, or alternatives.
'describe_figure' tool name lacks a clear action verb. 'Describe' is weak; 'analyze_image', 'extract_figure_caption', or 'summarize_figure' would be clearer. Current name is under-specific and LLMs may confuse it with other image operations if more tools are added.
'tool_clinical_trial' is a poor tool name, it is a noun phrase, not a verb_noun action name. Compare 'search_clinical_trials' (clear, starts with verb) vs 'tool_clinical_trial' (vague, sounds like a utility placeholder). Renaming is required for LLM clarity.
Parameter description quality is inconsistent. 'refs' in create_rag ('A comma-separated string of DOIs') does not specify format validation, handling of invalid DOIs, or max list size. 'image' in describe_figure has no description of supported formats, max resolution, or size limits.
No pagination or result limits documented. search_pubmed and ClinicalTrialsSearchTool may return hundreds of articles/trials, but no pagination parameters (offset, page, cursor) are declared. Returning large result sets will exhaust the context window per the mxe:enforce-result-limits baseline.