Skip to main content
Glama

Clinicaltrials Search Studies

clinicaltrials_search_studies
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort 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.
queryNoGeneral free-text search across all fields. Runs the 57-field relevance search ClinicalTrials.gov publishes for this parameter — NCTId, NCTIdAlias, OrgStudyId, SecondaryId, Acronym, BriefTitle, OfficialTitle, Condition, InterventionName, InterventionOtherName, Phase, StdAge, StudyType, BriefSummary, outcome measures and their descriptions, LeadSponsorName, CollaboratorName, the Location* fields, the Design* fields, and the ConditionAncestorTerm/InterventionAncestorTerm MeSH umbrellas — so a hit need not carry your term in the field you had in mind. 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.
fieldsNoPascalCase leaf names to return; strongly recommended since full records are ~70KB. Omit for the compact index projection — an empty list is rejected, not treated as omission. 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.
nctIdsNoFilter to specific NCT IDs for batch lookups. Omit to search every study — an empty list is rejected, not treated as "no filter". Supplying this lifts the default unknown-enrollment exclusion, so an ID you name is never filtered out of its own lookup.
pageSizeNoResults per page, 1–200.
geoFilterNoGeographic 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.
pageTokenNoPagination cursor from a previous response.
countTotalNoInclude total study count in response. Only computed on the first page.
titleQueryNoSearch within study titles and acronyms only. Matches Acronym, BriefTitle, and OfficialTitle. 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.
phaseFilterNoFilter by trial phase. Omit to search all phases — an empty list is rejected, not treated as "no filter". Values: EARLY_PHASE1, PHASE1, PHASE2, PHASE3, PHASE4, NA.
outcomeQueryNoSearch within outcome measure fields. Matches PrimaryOutcomeMeasure, SecondaryOutcomeMeasure, OtherOutcomeMeasure, and OutcomeMeasureTitle, plus their description counterparts PrimaryOutcomeDescription, SecondaryOutcomeDescription, OtherOutcomeDescription, OutcomeMeasureDescription, and OutcomeMeasurePopulationDescription — so a term appearing only in outcome prose still matches. 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.
sponsorQueryNoSponsor/collaborator name search. Matches LeadSponsorName, CollaboratorName, and OrgFullName. 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.
statusFilterNoFilter by study status. Omit to search all statuses — an empty list is rejected, not treated as "no filter". 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.
locationQueryNoLocation search — city, state, country, or facility name. Matches LocationCity, LocationState, LocationCountry, LocationFacility, and LocationZip; a study matches when any of its sites does. 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.
advancedFilterNoAdvanced 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.
conditionQueryNoCondition/disease-specific search. E.g., "Type 2 Diabetes", "non-small cell lung cancer". Matches Condition, BriefTitle, OfficialTitle, ConditionMeshTerm, ConditionAncestorTerm, Keyword, and NCTId. ConditionAncestorTerm is the MeSH umbrella above the conditions a study itself lists, so results run broader than those lists — a study can match a parent term it never names. 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.
interventionQueryNoIntervention/treatment search. E.g., "pembrolizumab", "cognitive behavioral therapy". Matches InterventionName, InterventionType, ArmGroupType, InterventionOtherName, BriefTitle, OfficialTitle, ArmGroupLabel, InterventionMeshTerm, Keyword, InterventionAncestorTerm, InterventionDescription, and ArmGroupDescription. InterventionAncestorTerm is the MeSH umbrella above the interventions a study itself lists, so results run broader than those lists. 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.
includeUnknownEnrollmentNoInclude 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

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoRecovery guidance when no studies matched — echoes the constraint and suggests how to broaden. Absent on pages with results.
studiesNoMatching 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.
totalCountNoTotal matching studies (first page only when countTotal=true).
nextPageTokenNoToken for the next page. Absent when this response already carries every matching study; otherwise it mirrors the upstream cursor, which ClinicalTrials.gov emits whenever a page fills to pageSize — so on a continuation page a token can still lead to an empty page.
searchCriteriaNoEcho of active query/filter criteria applied to this search, including sentinelFilterActive when the default unknown-enrollment exclusion is in effect. Present on every response.
requestedFieldsNoEcho 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.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover readOnly, openWorld (search is non-exhaustive, hits can be broader than expected via MeSH ancestors), and idempotent. The description adds substantial behavioral context beyond these: the 57-field relevance search means hits need not carry the query term in the obvious field; ConditionAncestorTerm/InterventionAncestorTerm broaden results beyond listed terms; the geoFilter re-sorts locations by proximity; the default unknown-enrollment exclusion is lifted when nctIds is supplied; pageSize max 200; countTotal only computed on first page. No contradictions — e.g., nctIds lifting the exclusion is a subtle disclosed behavior. The description surfaces pitfalls (bare radius interpreted as meters, empty lists rejected, ~70KB records) that materially affect invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but every sentence adds needed detail for a complex 18-parameter search tool. The main purpose is front-loaded in the first sentence. Parameter descriptions are dense but structured consistently (what matches, syntax rules, pitfalls). Some repetition across query parameters (the bracket/grouping caveat is repeated in most query params) could be trimmed, but this trades some conciseness for self-containment per parameter, which aids agents inspecting parameters individually. Slightly wordy overall but justified by complexity.

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 18 parameters, rich output schema, and annotations, the description is exceptionally complete. It explains the default projection vs. full records, provides syntax rules, lists exact matched fields for each query type, warns about sentinel values and unit suffixes, and directs to sibling tools for field definitions. The output schema exists, so return values are covered structurally. For a search API with this many knobs, nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100%, but the description adds enormous value beyond schema types. It explains the query syntax (AREA/RANGE, bracket rules, comma-as-AND), the exact field sets each query matches (e.g., titleQuery matches Acronym/BriefTitle/OfficialTitle), the nuance that conditionQuery matches MeSH ancestors, the sort pairing recommendation for largest-trials queries, and the rejected empty-list behavior. For geoFilter it specifies the required unit suffix and the distance-annotation behavior. This goes far beyond the schema's parameter names and basic 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 opens with a specific verb+resource ('Search for clinical trial studies from ClinicalTrials.gov') and enumerates capabilities (full-text/field-specific queries, filters, pagination, sorting, field selection). It contrasts the compact index default with full-fidelity records, which distinguishes it from siblings like clinicaltrials_get_study_record. It clearly signals it's the general search entry point versus targeted lookup tools.

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?

The description explicitly notes when to use this tool versus alternatives: it directs users to clinicaltrials_get_field_definitions for finding sortable fields and AREA-compatible names, and mentions the dedicated *Query parameters scope searches to one field. The description of the default compact projection and the recommendation to pass fields implies when one might prefer clinicaltrials_get_study_record for full records. This is embedded across parameter descriptions, providing clear decision guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct action: finding eligible trials, resolving field names, discovering field values, counting studies, fetching full records, fetching results, and searching. Even the count tool is clearly separated from search by its lightweight, no-data purpose. No two tools have ambiguous boundaries.

Naming Consistency5/5

All tools follow a strict 'clinicaltrials_' prefix followed by a descriptive verb_noun pattern (find_eligible, get_study_record, search_studies). The naming is uniform in snake_case and clearly indicates the operation and object. This consistency makes the tool set predictable.

Tool Count5/5

Seven tools is well within the ideal range for a focused MCP server. Each tool covers a necessary aspect of the ClinicalTrials.gov API (search, retrieval, counting, field exploration, results, eligibility matching) without bloat or redundancy. The scope feels complete for a read-only clinical trials interface.

Completeness5/5

The tool set covers the full read-only lifecycle: discovering the data model, searching, counting, fetching protocol records, fetching results, and matching patients to trials. There are no obvious gaps like missing location details or result statistics (both handled via parameters). The server fulfills its stated purpose without dead ends.