Loading ToolBench
MCP server for the ClinicalTrials.gov v2 API. Search trials, retrieve study details and results, and match patients to eligible trials.
This server demonstrates good schema coverage and comprehensive parameter descriptions, placing it in the B+ range. All 5 tools have clear names starting with action verbs (get_, clinicaltrials_find_) and well-documented parameters with types and descriptions. Output schemas are partially documented through parameter descriptions. However, there are gaps in error handling guidance, output schema structure documentation, and some parameter constraints could be more explicit. The tool descriptions are detailed and context-rich (100-500 chars), exceeding the baseline average of 194 chars. Tool naming follows verb_noun convention and is highly specific (e.g., clinicaltrials_get_field_definitions vs. get_field_definitions), which is excellent for disambiguation. The main weakness is incomplete output schema documentation, while input schemas are rigorous, return value structures are not formally declared in the code provided.
Match patient demographics to eligible recruiting clinical trials.
Resolve valid field names from the ClinicalTrials.gov data model — the canonical PascalCase identifiers (OverallStatus, EnrollmentCount, LeadSponsorName) accepted by the `fields`, `advancedFilter`, and `sort` parameters of other tools, and as input to clinicaltrials_get_field_values. Select a mode: `"search"` — keyword search returning ranked matches (pass `query`, e.g. "enrollment", "sponsor", "adverse events"); `"drill"` — drill into a specific section by dot-notation path (pass `path`, e.g. "protocolSection.designModule"); `"overview"` — top-level summary of all sections (no additional args).
Discover valid values for ClinicalTrials.gov fields with study counts per value. Use to explore available filter options before building a search — e.g., valid OverallStatus, Phase, InterventionType, StudyType, or LeadSponsorClass values.
Get total clinical trial study count from ClinicalTrials.gov matching a query, without fetching study data. Fast and lightweight. Use for quick statistics or to build breakdowns by calling multiple times with different filters (e.g., count by phase, count by status, count recruiting vs completed for a condition).
Output schemas not formally documented. Tool descriptions explain input parameters in detail but do not declare what fields/structure will be returned. LLMs cannot plan downstream operations without knowing return value structure.
clinicaltrials_get_study_results has vague sections parameter, enum values are declared ['outcomes', 'adverseEvents', 'participantFlow', 'baseline', 'moreInfo'] but the description does not clarify what each section contains or how they map to API response structures. LLMs cannot reason about which sections to request.
No pagination support explicitly declared in tool schemas. Tools like clinicaltrials_get_field_definitions have a 'limit' parameter (1-100, default 20) but no offset/cursor or total_count guidance documented. Large result sets may require multiple calls but the chaining strategy is not clear.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Extract outcomes, adverse events, participant flow, baseline, and results metadata from completed studies.
Error handling guidance missing. No tool description explains what errors might occur, how they are categorized (retryable vs. permanent), or what the LLM should do if a call fails. No examples of error recovery paths.
clinicaltrials_get_study_count has complex query syntax documentation (AREA[], RANGE[], boolean operators) but no explicit error message guidance if the LLM constructs invalid filter syntax. No examples of valid advanced filters are provided in parameter descriptions.