F
license-
qualityD
maintenanceEnables searching and retrieving information from the ClinicalTrials.gov database of over 400,000 clinical studies, including trial details, eligibility criteria, locations, and results across 220+ countries.
5
clinicaltrialsgov-mcp-server
Server Details
Search ClinicalTrials.gov — find studies, retrieve results, match patients to eligible trials.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/clinicaltrialsgov-mcp-server
- GitHub Stars
- 87
- Server Listing
- clinicaltrialsgov-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.5/5.0
Tool DescriptionsA
Average 4.6/5 across 7 of 7 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a distinct purpose: specialized eligibility matching, general search, record retrieval, results, counts, and field exploration. Descriptions are detailed and clearly differentiate them.
Naming Consistency4/5
All tools use the 'clinicaltrials_' prefix with snake_case verb phrases. While most use 'get_', two use 'find_' and 'search_', but the pattern is consistent and predictable.
Tool Count5/5
7 tools is well-scoped for a clinical trials API, covering search, retrieval, counts, eligibility matching, and schema exploration without being overwhelming.
Completeness5/5
The tool surface covers all common read operations for clinical trial data: searching, filtering, fetching records, results, counts, and exploring field definitions and values. No obvious gaps.
Available Tools
7 toolsclinicaltrials_find_eligibleClinicaltrials Find EligibleARead-onlyIdempotentInspect
Match patient demographics and conditions to eligible recruiting clinical trials. Provide age, sex, conditions, and location to find studies with matching eligibility criteria, contact information, and recruiting locations. Results are re-ranked so studies whose own condition matches a requested condition surface above tangential matches from ClinicalTrials.gov's fuzzy condition search.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Patient age in years. | |
| sex | Yes | Patient's biological sex. Use 'ALL' to include studies regardless of sex restrictions. | |
| location | Yes | Patient location as `{ country (required), state?, city? }`. Country is required; state/city narrow the match. For radius-based geographic search, use clinicaltrials_search_studies with geoFilter. | |
| conditions | Yes | Medical conditions or diagnoses, e.g. ["Type 2 Diabetes", "Hypertension"]. Each entry is matched as a condition (multi-word entries match as a phrase); multiple entries are combined with OR, so studies for any listed condition qualify. Returned studies are re-ranked so those whose own condition list names a requested condition rank above tangential matches the upstream fuzzy search pulls in via the MeSH umbrella. | |
| maxResults | No | Maximum results to return. | |
| recruitingOnly | No | Only include actively recruiting studies. | |
| healthyVolunteer | No | Whether the patient is a healthy volunteer. When true, only studies accepting healthy volunteers are queried. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| funnel | Yes | Match counts at each filter stage. Shows where the funnel collapsed — e.g., conditionMatched=298 but demographicsMatched=2 means age/sex/status are the constraint. |
| notice | No | Recovery guidance when no studies matched — identifies which filter stage collapsed and suggests how to broaden. Absent when results are returned. |
| studies | Yes | Matching studies with eligibility and location fields. |
| totalCount | No | Total matching studies from the API. |
| searchCriteria | Yes | Normalized search criteria applied to this eligibility query, including the exact upstream query strings needed to reproduce the full match set via clinicaltrials_search_studies (replay with includeUnknownEnrollment=true, which find_eligible always sets). |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare safety and idempotency. The description adds rich behavioral details: results re-ranking, OR combination of conditions, healthy volunteer handling, and fuzzy search behavior, exceeding what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no fluff: first states purpose, second explains unique re-ranking. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (7 params, nested objects, output schema), the description covers all essential aspects: input requirements, behavior, and special features like re-ranking. No gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3, but the description adds significant meaning beyond schema (e.g., OR logic, re-ranking, healthy volunteer implications), justifying a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Match patient demographics and conditions') and the resource ('eligible recruiting clinical trials'), with differentiation from siblings through mention of re-ranking and fuzzy condition search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The main description implies the use case but does not explicitly state when not to use this tool. However, the location parameter description provides an alternative for radius-based search, offering context for choosing between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clinicaltrials_get_field_definitionsClinicaltrials Get Field DefinitionsARead-onlyIdempotentInspect
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Operation mode. "search" — keyword search (requires `query`); "drill" — drill into a section by path (requires `path`); "overview" — list all top-level sections (no other args needed). | |
| path | No | drill mode only. Dot-notation path to drill into — e.g., "protocolSection.designModule", "protocolSection.eligibilityModule", "resultsSection". Returns the section's individual fields. | |
| limit | No | search mode only. Maximum results to return. Default: 20. | |
| query | No | search mode only. Keyword to search field names by — e.g., "enrollment", "sponsor", "adverse events". Returns matching field names ranked by relevance with their full paths and data types. | |
| includeIndexedOnly | No | drill mode only. Only return indexed (searchable) fields. Default: false. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied to this search (search mode only). |
| shown | No | Number of fields returned (search mode only). |
| fields | Yes | Field definitions, ordered by relevance when mode is "search". |
| notice | No | Recovery guidance when search mode returns no matches, or a truncation note when results are capped. |
| truncated | No | True when the field list was capped by the limit parameter (search mode only). |
| searchQuery | No | Echo of the keyword used in search mode. Absent for drill and overview. |
| totalFields | Yes | Total fields returned. |
| resolvedPath | No | Resolved path when mode is "drill". |
| totalMatches | No | Total fields matching the query before the limit cap was applied (search mode only). Compare against `shown` to size a follow-up limit, or to see that a capped result set is barely over the cap rather than hundreds deep. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint). It details the three modes, their inputs, and their outputs (ranked matches with paths and data types for search, individual fields for drill, top-level sections for overview), which enriches the agent's understanding of how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three sentences. The first sentence front-loads the core purpose and examples. The second introduces modes, and the third expands each mode with parameter requirements. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers the tool's purpose, usage guidelines, parameter semantics, and behavioral traits. It explains what each mode returns, making the tool fully understandable. The five parameters are all documented in both schema and description, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant meaning by clarifying the purpose of each mode, giving concrete examples for query ('enrollment', 'sponsor'), and explaining inter-parameter dependencies (e.g., search requires query, drill requires path). This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Resolve valid field names' and identifies the resource as the ClinicalTrials.gov data model. It provides concrete examples of canonical identifiers (OverallStatus, EnrollmentCount) and explicitly distinguishes this tool from siblings by noting its output feeds into other tools like clinicaltrials_get_field_values and the fields/advancedFilter/sort parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (search, drill, overview) and specifies the required parameters for each. While it doesn't explicitly state when not to use this tool versus alternatives, the context about output being input to other tools implies its purpose. A more explicit exclusion statement would elevate this to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clinicaltrials_get_field_valuesClinicaltrials Get Field ValuesARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | PascalCase field name(s) to get value statistics for. Examples: OverallStatus, Phase, StudyType, Sex, LeadSponsorClass. Use clinicaltrials_get_field_definitions with a query to find more field names. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| fieldStats | Yes | One entry per requested field: canonical path, PascalCase piece name, data type, missing/unique counts, and top values with study counts (or trueCount/falseCount for BOOLEAN fields). |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that results include 'study counts per value' and gives example fields, which is useful context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The description is front-loaded with the core purpose and immediately useful for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter), rich annotations, and presence of an output schema, the description is complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description provides examples of valid field values and references get_field_definitions, adding some meaning beyond the schema, but does not substantially extend it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers valid field values with study counts, using specific verbs and resources. It distinguishes itself from siblings like clinicaltrials_get_field_definitions by mentioning 'filter options before building a search.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it 'before building a search' to explore filter options, providing clear context. It does not state when not to use it or name alternatives, but the sibling list implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clinicaltrials_get_study_countClinicaltrials Get Study CountARead-onlyIdempotentInspect
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | General free-text search across all fields. Plain words plus AND, OR, NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression — those work here as well as in advancedFilter, so AREA[Phase]PHASE2 is accepted in this parameter; a stray bracket fails. `( )` group sub-expressions and work when matched; `,` acts as AND. The dedicated *Query parameters (conditionQuery, interventionQuery, etc.) scope a search to one field. | |
| titleQuery | No | Search within study titles and acronyms only. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| phaseFilter | No | Filter by trial phase. Values: EARLY_PHASE1, PHASE1, PHASE2, PHASE3, PHASE4, NA. | |
| outcomeQuery | No | Search within outcome measure fields. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| sponsorQuery | No | Sponsor/collaborator name search. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| statusFilter | No | Filter by study status. Values: RECRUITING, COMPLETED, ACTIVE_NOT_RECRUITING, NOT_YET_RECRUITING, ENROLLING_BY_INVITATION, SUSPENDED, TERMINATED, WITHDRAWN, UNKNOWN, WITHHELD, NO_LONGER_AVAILABLE, AVAILABLE, APPROVED_FOR_MARKETING, TEMPORARILY_NOT_AVAILABLE. | |
| locationQuery | No | Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| advancedFilter | No | Advanced filter using AREA[FieldName]value syntax. Examples: "AREA[StudyType]INTERVENTIONAL", "AREA[EnrollmentCount]RANGE[100, 1000]", "AREA[Phase]PHASE2 AND AREA[StudyType]INTERVENTIONAL", "(AREA[Phase]PHASE3 OR AREA[Phase]PHASE4) AND AREA[StudyType]INTERVENTIONAL". AND/OR/NOT join complete AREA[FieldName]value expressions; parentheses group them. Call clinicaltrials_get_field_definitions to find AREA[]-compatible field names. | |
| conditionQuery | No | Condition/disease-specific search. E.g., "Type 2 Diabetes", "non-small cell lung cancer". Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| interventionQuery | No | Intervention/treatment search. E.g., "pembrolizumab", "cognitive behavioral therapy". Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| includeUnknownEnrollment | No | Include studies whose EnrollmentCount is the upstream "unknown" sentinel (99999999). Excluded by default — the sentinel pollutes RANGE[N, MAX] queries. Set true for data-quality audits. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery guidance when totalCount is 0 — suggests how to broaden the query or filters. |
| totalCount | Yes | Total studies matching the query/filters. |
| searchCriteria | No | Echo of active query/filter criteria applied to this count, including sentinelFilterActive when the default unknown-enrollment exclusion is in effect. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds context about speed ('fast and lightweight') and that it returns only a count without fetching study data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, performance, usage guidance. No fluff, front-loaded with key information. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values are covered. Description covers general use, performance, and breakdown strategy. Could mention that all parameters are optional, but schema already shows no required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters in detail. The description adds general usage advice but does not enhance meaning of individual parameters beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'total clinical trial study count', differentiating from sibling tools like clinicaltrials_search_studies that fetch detailed data. It specifies the tool returns only a count, not study data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: quick statistics and building breakdowns by calling multiple times with different filters. Implicitly suggests alternatives when full data is needed. Could explicitly state when not to use, but current guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clinicaltrials_get_study_recordClinicaltrials Get Study RecordARead-onlyIdempotentInspect
Fetch a single clinical trial study by NCT ID from ClinicalTrials.gov. Returns the full study record including protocol details, eligibility criteria, outcomes, arms, interventions, contacts, and locations. Optional locationLimit / outcomeLimit / referenceLimit / nearLocation parameters trim locations, outcomes, and references — original totals are preserved in filtersApplied only when a cap actually trims the set.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nctId | Yes | NCT identifier — format `NCT` followed by 8 digits (e.g., `NCT03722472`). | |
| nearLocation | No | Filter returned locations to those within radius of (lat, lon) and sort by distance. Adds distanceMi to each location. Locations without published coordinates are dropped — most US sites carry them; international sites less reliably so. Distances reflect ClinicalTrials.gov geocoding granularity — typically city-centroid, not facility-level — so multiple sites in the same city resolve to near-identical distances. For broader geographic filtering across studies, use clinicaltrials_search_studies with geoFilter. | |
| outcomeLimit | No | Optional cap on the number of secondary and other outcomes returned. Omit for no cap (full upstream lists). Primary outcomes are never capped. Original totals preserved in filtersApplied.totalSecondaryOutcomes / totalOtherOutcomes only when the cap trims a list. | |
| locationLimit | No | Optional cap on the number of locations returned. Omit for no cap (full upstream list). Pairs naturally with nearLocation for narrowing a large multi-site trial. Original total preserved in filtersApplied.totalLocations only when the cap trims the list. | |
| referenceLimit | No | Optional cap on the number of references returned. Omit for no cap (full upstream list). Original total preserved in filtersApplied.totalReferences only when the cap trims the list. seeAlsoLinks are never capped. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| study | Yes | Full study record with caller-requested filters already applied to locations and outcomes. Top-level keys: protocolSection (identification, status, sponsor, conditions, design, arms/interventions, outcomes, eligibility, contacts/locations), derivedSection (MeSH-normalized terms), hasResults, documentSection. The heavy resultsSection is omitted — see resultsSummary for counts and clinicaltrials_get_study_results for full results data. Use clinicaltrials_get_field_definitions to explore the schema. |
| filtersApplied | Yes | Metadata about the filtering applied to `study`. |
| resultsSummary | No | Compact counts of posted results, present when hasResults is true. The full resultsSection is intentionally omitted from this record-level tool — fetch it via clinicaltrials_get_study_results or the clinicaltrials://{nctId} resource. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description explains behavioral details: limit parameters preserve original counts in filtersApplied only when trimmed, nearLocation drops unpublished coordinates and distances are city-centroid granularity. This fully informs the agent of side effects and nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences covering purpose, return contents, and parameter nuances. Front-loaded with main action. Efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, nested objects, and an output schema, the description covers all necessary aspects: return contents, parameter behaviors, and alternative tool for geo-filtering. No gaps given the presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. The description adds value by noting that primary outcomes are never capped, and that nearLocation adds distanceMi. This extra context justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single clinical trial by NCT ID and lists the full record contents. It distinguishes from sibling tools like clinicaltrials_search_studies which returns multiple studies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single study retrieval and explicitly mentions using clinicaltrials_search_studies for broader geographic filtering. However, it does not explicitly state when not to use this tool for other purposes like searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clinicaltrials_get_study_resultsClinicaltrials Get Study ResultsARead-onlyIdempotentInspect
Fetch clinical trial results data from ClinicalTrials.gov for completed studies — outcome measures with statistics, adverse events, participant flow, baseline characteristics, and results metadata (limitations & caveats, certain-agreement disclosure restrictions, results point of contact). Only available for studies where hasResults is true. Use clinicaltrials_search_studies first to find studies with results.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nctIds | Yes | One or more NCT IDs (max 20). E.g., "NCT12345678" or ["NCT12345678", "NCT87654321"]. Use summary=true for large batches to avoid large payloads. | |
| summary | No | Return condensed summaries instead of full data. Full mode renders every row and field on both output channels, so a large results set can exceed 500KB per study; summary mode reduces that to ~5KB. Summaries include outcome titles, types, timeframes, group counts, and top-level stats — omitting individual measurements, analyses, and per-group data. | |
| sections | No | Filter which sections to return. Values: outcomes, adverseEvents, participantFlow, baseline, moreInfo. Omit for all sections. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Results per study. |
| fetchErrors | No | Studies that could not be fetched. |
| studiesWithoutResults | No | NCT IDs that do not have results data. |
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent, so description adds value beyond by detailing behavior: sections returned, summary mode reducing payload (full mode up to 500KB), and condition (hasResults). No contradictions. Minor gap: no mention of rate limits or auth, but not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. Front-loaded with purpose, then availability constraint, then usage recommendation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (3 params, output schema exists, annotations present), description covers purpose, usage, behavioral details, and parameter guidance. It is complete for the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100%, but description adds practical advice (use summary=true for large batches). It clarifies the summary parameter's impact, which is helpful beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches clinical trial results data for completed studies, listing specific sections (outcomes, adverse events, etc.). It distinguishes from sibling tools like clinicaltrials_search_studies by specifying it's for results and recommends using that search first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly guides to use clinicaltrials_search_studies first to find studies with results and notes availability only when hasResults is true. This provides clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clinicaltrials_search_studiesClinicaltrials Search StudiesARead-onlyIdempotentInspect
Search for clinical trial studies from ClinicalTrials.gov. Supports full-text and field-specific queries, status/phase/geographic filters, pagination, sorting, and field selection. Returns a compact per-study index by default; pass the fields parameter to get specific leaves at full fidelity — full study records are ~70KB each.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order. Format: FieldName:asc or FieldName:desc. E.g., "LastUpdatePostDate:desc", "EnrollmentCount:desc". Max 2 fields comma-separated. For "largest trials" queries, pair EnrollmentCount:desc with advancedFilter "AREA[StudyType]INTERVENTIONAL" — the top enrollment counts are observational registry/claims studies enrolling tens of millions. Enrollment counts are sponsor-reported and not validated upstream beyond the unknown-enrollment sentinel exclusion. Use clinicaltrials_get_field_definitions to find sortable field names. | |
| query | No | General free-text search across all fields. Plain words plus AND, OR, NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression — those work here as well as in advancedFilter, so AREA[Phase]PHASE2 is accepted in this parameter; a stray bracket fails. `( )` group sub-expressions and work when matched; `,` acts as AND. The dedicated *Query parameters (conditionQuery, interventionQuery, etc.) scope a search to one field. | |
| fields | No | PascalCase leaf names to return; strongly recommended since full records are ~70KB. Common leaves: NCTId, BriefTitle, BriefSummary, OverallStatus, Phase, LeadSponsorName, Condition. Call clinicaltrials_get_field_definitions with a concept query (e.g., "adverse events", "eligibility") to find the exact leaf for any concept. | |
| nctIds | No | Filter to specific NCT IDs for batch lookups. | |
| pageSize | No | Results per page, 1–200. | |
| geoFilter | No | Geographic proximity filter. Format: distance(lat,lon,radius), where radius carries a `mi` or `km` suffix — e.g. "distance(47.6062,-122.3321,50mi)" for studies within 50 miles of Seattle. Always include the suffix: a bare radius is accepted upstream but interpreted as meters, which silently matches almost nothing. When set, each study's locations are re-sorted by proximity to the center so the nearest matched site leads, annotated with its distance in miles; the full location list is preserved. | |
| pageToken | No | Pagination cursor from a previous response. | |
| countTotal | No | Include total study count in response. Only computed on the first page. | |
| titleQuery | No | Search within study titles and acronyms only. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| phaseFilter | No | Filter by trial phase. Values: EARLY_PHASE1, PHASE1, PHASE2, PHASE3, PHASE4, NA. | |
| outcomeQuery | No | Search within outcome measure fields. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| sponsorQuery | No | Sponsor/collaborator name search. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| statusFilter | No | Filter by study status. Values: RECRUITING, COMPLETED, ACTIVE_NOT_RECRUITING, NOT_YET_RECRUITING, ENROLLING_BY_INVITATION, SUSPENDED, TERMINATED, WITHDRAWN, UNKNOWN, WITHHELD, NO_LONGER_AVAILABLE, AVAILABLE, APPROVED_FOR_MARKETING, TEMPORARILY_NOT_AVAILABLE. | |
| locationQuery | No | Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| advancedFilter | No | Advanced filter using AREA[FieldName]value syntax. Examples: "AREA[StudyType]INTERVENTIONAL", "AREA[EnrollmentCount]RANGE[100, 1000]", "AREA[Phase]PHASE2 AND AREA[StudyType]INTERVENTIONAL", "(AREA[Phase]PHASE3 OR AREA[Phase]PHASE4) AND AREA[StudyType]INTERVENTIONAL". AND/OR/NOT join complete AREA[FieldName]value expressions; parentheses group them. Call clinicaltrials_get_field_definitions to find AREA[]-compatible field names. | |
| conditionQuery | No | Condition/disease-specific search. E.g., "Type 2 Diabetes", "non-small cell lung cancer". Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| interventionQuery | No | Intervention/treatment search. E.g., "pembrolizumab", "cognitive behavioral therapy". Plain words plus AND/OR/NOT. `[ ]` are valid only inside an AREA[FieldName]value or RANGE[min, max] expression, which this parameter accepts; a stray bracket fails. `( )` group sub-expressions when matched; `,` acts as AND. | |
| includeUnknownEnrollment | No | Include studies whose EnrollmentCount is the upstream "unknown" sentinel (99999999). Excluded by default — the sentinel pollutes RANGE[N, MAX] queries and EnrollmentCount:desc sorts. Set true for data-quality audits or when targeting unknown-enrollment studies specifically. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery guidance when no studies matched — echoes the constraint and suggests how to broaden. Absent on pages with results. |
| studies | Yes | Matching studies. By default each entry is a COMPACT index projection — nctId, briefTitle, overallStatus, phases, enrollmentCount, leadSponsor, conditions, and a bounded locations summary ({ total, nearest }) — mirroring the rendered result, NOT the full ~70KB record. Pass the fields parameter to receive exactly the requested leaves at full fidelity instead (e.g. all locations). Fetch a full single record with clinicaltrials_get_study_record. |
| totalCount | No | Total matching studies (first page only when countTotal=true). |
| nextPageToken | No | Token for the next page. Absent on last page. |
| searchCriteria | No | Echo of active query/filter criteria applied to this search, including sentinelFilterActive when the default unknown-enrollment exclusion is in effect. Present on every response. |
| requestedFields | No | Echo of the explicit fields parameter — present only when the caller passed fields. Signals that studies carry the requested leaves at full fidelity (not the default compact index) and that the rendered truncation cap is lifted so all of them appear. |
Tool Definition Quality
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds value by stating the default return format (compact per-study index) and noting that full records are ~70KB, which informs agents about data size and performance considerations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the core purpose and key features. Every sentence adds value with no redundancy. It is appropriately sized for a complex search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich parameter descriptions, the tool description covers the main capabilities and return format. It mentions default behavior and important size caveats. No missing critical information for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description provides a high-level summary of capabilities (full-text/field-specific queries, filters, pagination, etc.) but does not add significant meaning beyond what the schema already provides. Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for clinical trial studies' with specific verb and resource. It distinguishes from siblings like clinicaltrials_get_study_record by noting that it returns a compact index and full records are large.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general search and mentions field selection to avoid full records, hinting at when not to use for full details. However, it lacks explicit guidance on when to use this tool versus siblings like clinicaltrials_find_eligible or clinicaltrials_get_study_record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables searching and querying clinical trials from ClinicalTrials.gov with intelligent filtering for recruiting studies, geographic search, and detailed trial information including contacts and eligibility criteria.376MIT
- Flicense-qualityCmaintenanceEnables searching clinical trials, retrieving trial details, matching patient profiles to recruiting trials, and extracting eligibility criteria from ClinicalTrials.gov.
- Flicense-qualityDmaintenanceEnables searching and retrieving detailed clinical trial information from ClinicalTrials.gov via the official API.1
Try in Browser
Your Connectors
Sign in to create a connector for this server.