An advanced MCP Server for accessing and analyzing clinical evidence data, with flexible search options to support precision medicine and oncology research.
The server exposes a single clinical evidence search tool with a well-structured schema and comprehensive parameter descriptions. The tool name follows the verb_noun pattern (search_clinical_evidence), and all parameters include type definitions and non-trivial descriptions with examples. However, the output is returned as a plain string (markdown-formatted text) rather than a structured schema, which violates pattern:response-shaper and limits the LLM's ability to parse and chain results. The tool description itself is detailed (215 chars, within 10-1024 range) and explains WHAT it does and WHEN to use it. All 7 parameters have descriptions ranging from 80-160 chars, exceeding the 72-char baseline average. Error handling is minimal, the tool only checks for empty DataFrames and returns a plain message, with no guidance on validation failures or recovery paths.
Perform a flexible search for clinical evidence using combinations of filters such as disease, therapy, molecular profile, phenotype, evidence type, and direction. This flexible search system allows you to tailor your query based on the data needed for research or clinical decision-making. It returns a detailed report that includes summary statistics, a top 10 evidence listing, citation sources, and a disclaimer.
Output is returned as a plain string (markdown-formatted text) rather than a structured JSON object with typed fields. This violates pattern:response-shaper and forces the LLM to parse unstructured text, making downstream tool composition, data extraction, and result validation error-prone and token-expensive.
No documented output schema. The tool description does not explicitly state what structure or fields are returned. LLMs cannot plan downstream operations or extract key data (evidence IDs, citations, ratings) without knowing the response format.
Minimal error handling and no recovery guidance. If the CivicAPIClient fails to fetch data, or if the DataFrame is malformed, the tool returns a generic message or may raise an unhandled exception. LLMs receive no actionable guidance on what went wrong or how to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameters filter_strong_evidence, evidence_type, and evidence_direction accept free-form strings or booleans without enum constraints. evidence_type should be constrained to ['PREDICTIVE', 'DIAGNOSTIC', 'PROGNOSTIC', 'PREDISPOSING', 'FUNCTIONAL'], and evidence_direction to ['SUPPORTS', 'DOES_NOT_SUPPORT']. Free-form strings invite hallucinated invalid values.
No pagination or result limiting mechanism. If the CivicAPI returns thousands of clinical evidence records, the tool processes all of them and generates a markdown report with the top 10. The full DataFrame processing wastes tokens and risks context window exhaustion. The tool should accept limit and offset/cursor parameters and document the cap in the description.