Skip to main content
Glama

ClinicalTrials.gov MCP by usefulapi

Search clinical trials (ClinicalTrials.gov)

search_studies
Read-only

Search the ClinicalTrials.gov v2 study registry. Provide any combination of query terms (condition, intervention, title, location, sponsor, general term) — multiple query.* terms are ANDed together — plus optional filters (status, geo, advanced Essie expression, explicit NCT ids). Returns { totalCount?, studies: [...], nextPageToken? }. Use fields to trim the response to specific fields/modules, sort to order (e.g. '@relevance', 'LastUpdatePostDate:desc', 'EnrollmentCount:desc'), and pageSize/pageToken to page. GET /studies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoRestrict to these NCT ids (maps to filter.ids), e.g. ['NCT00841061'].
sortNoSort order, e.g. '@relevance', 'LastUpdatePostDate:desc', 'EnrollmentCount:desc', 'StudyFirstPostDate:desc'.
termNoGeneral full-text 'other terms' query (maps to query.term).
titleNoWords in the study title (maps to query.titles).
fieldsNoFields or modules to return, e.g. ['NCTId','BriefTitle','OverallStatus'] or ['protocolSection.identificationModule']. Omit to return full study records.
statusNoFilter by overall recruitment status (maps to filter.overallStatus). One or more of: ACTIVE_NOT_RECRUITING, COMPLETED, ENROLLING_BY_INVITATION, NOT_YET_RECRUITING, RECRUITING, SUSPENDED, TERMINATED, WITHDRAWN, AVAILABLE, NO_LONGER_AVAILABLE, TEMPORARILY_NOT_AVAILABLE, APPROVED_FOR_MARKETING, WITHHELD, UNKNOWN.
sponsorNoSponsor / collaborator name (maps to query.spons).
advancedNoAdvanced Essie expression applied as an additional filter (maps to filter.advanced).
locationNoStudy location text, e.g. a city/state/country (maps to query.locn).
pageSizeNoNumber of studies per page (1–1000; API default 10).
conditionNoDisease / condition to match (maps to query.cond), e.g. 'diabetes'.
geoFilterNoGeo filter as a raw geo-function string (maps to filter.geo), e.g. 'distance(39.0027,-77.1,50mi)'.
pageTokenNoOpaque token from a previous response's nextPageToken, to fetch the next page.
countTotalNoInclude the total number of matching studies (totalCount) on the first page.
interventionNoTreatment / drug / intervention to match (maps to query.intr).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

With readOnlyHint=true already declaring the safety profile, the description still adds real substance: the response envelope ({ totalCount?, studies, nextPageToken? }), pagination via nextPageToken, field trimming, and the AND-combination semantics of query terms. It stops short of mentioning rate limits, auth, or the 1000-item cap's practical consequences, so it is not a 5.

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?

Front-loads purpose, then queryable dimensions, then return shape and result-shaping controls — a sensible order with no filler sentences. The sort and fields examples duplicate what already appears in the schema, which is minor waste.

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?

There is no output schema, so the description must carry the return contract, and it does by naming totalCount/studies/nextPageToken and the paging token. For a 15-parameter tool it is complete on invocation mechanics, though it omits any guidance on choosing among the many sibling lookup tools.

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%, so the baseline is 3, but the description adds genuine meaning beyond the schema: that multiple query.* terms are ANDed, that fields can be addressed at field or module granularity, and worked sort examples. These are semantic details the parameter descriptions do not fully convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search the ClinicalTrials.gov v2 study registry') and enumerates the query dimensions it accepts, so the scope is unambiguous. It never names the siblings it is adjacent to (get_study for a single record, count_studies for totals, list_field_values for vocabulary), so it earns a 4 rather than a 5.

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?

Gives clear operating context: any combination of query terms are ANDed, filters are optional, and fields/sort/pageSize/pageToken are the knobs for shaping results. It does not say when to prefer count_studies (only implied via the countTotal flag) or get_study, so there is no explicit exclusion or alternative routing.

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.