MCP SDK v2 server for multi-source biomedical literature research
This server presents 41 tools with significant definition quality gaps. While tool names generally follow verb_noun patterns (search_*, get_*, list_*, etc.) and are action-oriented, the implementation reveals critical deficiencies in schema completeness, parameter descriptions, and output documentation. Many tools lack visible input schemas in the provided code; parameter descriptions are minimal or missing; output structures are undocumented. The server addresses a sophisticated domain (biomedical literature research) but the tool definitions do not meet production standards for LLM-driven composition. Average tool definition score across the 41 tools is 52, pulling down the overall dimension. Most tools lack comprehensive error guidance, output schema documentation, and parameter relationship documentation required for robust agent planning.
Analyze and optimize search queries for better results
Build and explore citation networks
Create versioned, evidence-supported research evolution timeline
Configure OpenURL Link Resolver for institutional access
Convert between ICD-10 and MeSH medical terminologies
Delete a saved search pipeline
Diagnose institutional access issues
Output schemas are not documented. For tools like fetch_article_details, get_citation_metrics, build_citation_tree, and prepare_export, the response structure is not visible in the provided code. LLMs cannot plan downstream tool calls without knowing what fields will be returned.
Parameter descriptions are minimal or absent. Most tools have only placeholder descriptions ('Population parameter', 'Intervention parameter', etc.) that do not explain what values are valid, expected formats, constraints, or when to use the parameter. The rubric requires that parameter descriptions answer format, range, and constraints explicitly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Fetch detailed metadata for articles by PMID
Find articles that cite a given article
Find articles related to a given PMID
Generate MeSH-expanded search queries from PICO parameters
Extract figures and visual data from articles
Get references cited by an article
Get citation metrics and impact information for articles
Get detailed information about a chemical compound
Get literature associated with a compound
Retrieve full text of articles from various sources
Get detailed information about a gene
Get literature associated with a gene
Get institutional access link for an article
Get execution history for a pipeline
Extract text-mined terms and entities from articles
List all saved search pipelines
List available resolver presets for institutional access
Load and execute a saved search pipeline
Prepare citations for export in various formats
Prepare and execute figure search using computer vision (experimental)
Query research chronicle for versioned evolution and evidence
Read session data including PMID cache, articles, summaries, events, and artifacts
Save and persist literature research notes
Save a reusable search pipeline configuration
Schedule a pipeline for periodic execution
Search biomedical images from Open-i repository
Search ClinVar for genetic variations
Search PubChem compound database
Search NCBI Gene database
Test institutional access configuration
Unified multi-source literature search gateway
Remove scheduled execution of a pipeline
MeSH expansion, agent-provided PICO handoff, and query analysis
Reference list verification with PubMed evidence
Tool descriptions lack actionable context for LLM selection. Descriptions like 'Generate MeSH-expanded search queries from PICO parameters' do not explain when to call this tool instead of unified_search or generate_search_queries, what prerequisites exist (must PICO be validated first?), or what the output represents. Per the rubric, descriptions should answer: What does it do? When should the LLM call it instead of a similar tool? What does it return?
Destructive tools (save_literature_notes, save_pipeline, schedule_pipeline, delete_pipeline, unschedule_pipeline, configure_institutional_access) lack confirmation/dry-run patterns and recovery guidance. An LLM could accidentally overwrite research notes or delete a pipeline without a safe path to undo. The error handling rubric requires irreversible operations to support confirmation or dry-run modes.
Error handling guidance is absent. No tools document what errors they may return, what they mean, or what the LLM should do if an error occurs. Tools calling external APIs (NCBI, PubChem, etc.) will fail; without recovery guidance, the LLM has no recovery strategy.
Tool composition is unclear. Multiple tools operate on the same resources (articles, genes, compounds) but relationships are not documented. Does validate_pico_plan need to be called before generate_search_queries? Can an LLM call unified_search and then fetch_article_details, or is there a different expected sequence? Dependencies should be documented in descriptions.
Parameter type definitions are incomplete or missing. In tool_contracts.py and tool_registry.py, visible parameters show basic types (string, array, object), but many lack enum constraints, min/max bounds, regex patterns, or format specifications. For example, 'format' parameter in prepare_export accepts string but valid values (bibtex, ris, etc.) are not declared as an enum.
Pagination and result limits are not visible. Tools like unified_search, find_related_articles, and get_article_references that may return many results do not show limit, offset, page, or cursor parameters in the provided schemas. Without pagination, large result sets will exhaust context windows.