Search ClinicalTrials.gov — find studies, retrieve results, match patients to eligible trials.
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. Each candidate returns only the sites matching the requested location (capped by locationLimit), not the study's full registered site list — a large trial can register hundreds of sites worldwide. When none of a candidate's matched sites is recruiting, its nearest recruiting site is added, so an enrollable site is never hidden behind a closer closed one. Fetch a study's complete record with clinicaltrials_get_study_record.
| 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. | |
| locationLimit | No | Cap on the sites returned per candidate. Each candidate keeps only the sites matching the requested location at the narrowest level that matched (city, else state, else country), capped at this many; the rest of the study's registered sites are omitted. The cap governs those matched sites — when none of them is recruiting, the candidate's nearest recruiting site is added on top of it, so a candidate can carry one site more than this. Raise it to see more nearby sites, or fetch the complete site list with clinicaltrials_get_study_record. Each candidate reports totalLocations / matchedLocations / locationsTruncated / nearestRecruitingSiteAdded in locationSummary only when the bound actually dropped sites. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| funnel | No | 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 | No | Matching studies with eligibility and location fields. Each candidate's protocolSection.contactsLocationsModule.locations is BOUNDED to the sites matching the requested location (capped at locationLimit) plus, when none of those is recruiting, the candidate's nearest recruiting site — not the study's full registered site list. A candidate whose sites were bounded also carries a top-level locationSummary object — { totalLocations, matchedLocations, locationsTruncated, nearestRecruitingSiteAdded?, retrieveFullStudyWith } — absent when nothing was dropped; nearestRecruitingSiteAdded is present only when that extra site was added. Fetch a study's complete record and site list with clinicaltrials_get_study_record. |
| totalCount | No | Total matching studies from the API. |
| searchCriteria | No | 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses several non-obvious behaviors: results are re-ranked so direct condition matches surface above fuzzy MeSH matches; each candidate returns only location-matched sites capped by locationLimit; and when no matched site is recruiting, the nearest recruiting site is added. These details materially change how an agent interprets the results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense with no filler. It front-loads the primary purpose, then explains ranking and site-filtering behavior, and closes with an alternative routing. The paragraph is structured logically, though slightly verbose; a tighter split into a few bullet-like sentences would be ideal, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, nested location object, output schema), the description covers everything an agent needs to call it correctly: matching logic, ranking, site selection rules, the cap behavior, fallback to nearest recruiting site, and even mentions the locationSummary fields. It also references the alternative tool for complete records, making the choice context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter, but the description adds critical semantics: conditions are matched as phrases and OR'd together, the location object's narrowing precedence (city > state > country), the exact behavior of locationLimit (cap plus the possibility of one extra site), and the meaning of locationSummary fields. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Match patient demographics and conditions to eligible recruiting clinical trials.' It names the core inputs (age, sex, conditions, location) and explicitly contrasts itself with siblings like clinicaltrials_get_study_record and clinicaltrials_search_studies, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit alternatives for fetching a full record ('Fetch a study's complete record with clinicaltrials_get_study_record') and for radius-based search ('For radius-based geographic search, use clinicaltrials_search_studies with geoFilter'). It implies when to use this tool (patient matching) but does not state a formal when-not-to-use condition, so it falls short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| 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. |
| Name | Required | Description |
|---|---|---|
| cap | No | The limit cap applied to this search (search mode only). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of fields returned (search mode only). |
| fields | No | 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 | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, idempotent, open-world operation, so the bar for the description is about adding value on top. It clarifies the mode-dependent contract numerically — what happens when each mode's parameters are dispatched — and the kind of output (ranked matches, section fields, top-level summary). It stops short of disclosing edge cases like empty result sets, invalid paths, or whether overview has bounded output, which would take this to 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose clause is front-loaded before the em dash, with the mode-by-mode breakdown following in a scannable, rhythmically consistent format. Every clause earns its place: the examples are illustrative, the mode-to-parameter mapping is tight. It is two substantial sentences, which is appropriate for the complexity, though it could theoretically be slimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's genuine complexity (three dispatch modes, conditional parameter requirements, cross-tool integration), the description leaves little procurement failure mode uncovered: all modes, their params, and example values are documented. The presence of an output schema frees the description from return-value documentation, and it fills the remaining gap (downstream usage) by noting this feeds clinicaltrials_get_field_values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. Credit is earned by the description's enrichment above the schema: it groups parameters by mode (search/drill/overview), provides realistic example values ("enrollment", "sponsor", "protocolSection.eligibilityModule"), and clarifies the conditional requirements (e.g., overview takes 'no additional args') that aren't explicit in the schema's required-fields alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb ('Resolve') and a tightly-scoped resource: 'valid field names from the ClinicalTrials.gov data model,' buttressed by canonical examples (OverallStatus, EnrollmentCount, LeadSponsorName). It explicitly says what the output is for — the fields/advancedFilter/sort parameters of other tools and input to clinicaltrials_get_field_values — which clearly differentiates it from the study-query siblings. An agent could identify this tool's role without opening a single sibling schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context for every branch: keyword search passes `query`, drill passes a dot-notation `path`, and overview needs no arguments. It also states where the output is consumed, which routes an agent toward correct downstream usage. However, it never names what it is not — e.g., unlike clinicaltrials_search_studies or clinicaltrials_get_study_record — so an explicit exclusion for the other five siblings is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | PascalCase field name(s) to get value statistics for — an empty list is rejected, not treated as "every field". Examples: OverallStatus, Phase, StudyType, Sex, LeadSponsorClass. Use clinicaltrials_get_field_definitions with a query to find more field names. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| fieldStats | No | 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate a non-destructive operation. The description adds context about returning study counts per value without contradicting any annotation. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no redundancy, and front-loads the core action ('Discover valid values') before the usage hint. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are already specified. The description adds the key detail of 'study counts per value' and the usage context, making it complete for an agent to decide when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the 'fields' parameter. The description reinforces this with examples (OverallStatus, Phase, etc.) and clarifies edge cases like the rejection of an empty list, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Discover valid values for ClinicalTrials.gov fields with study counts per value.' It also provides concrete examples (OverallStatus, Phase, etc.) and distinguishes it from sibling tools like clinicaltrials_search_studies by focusing on filter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to 'Use to explore available filter options before building a search,' which gives a clear when-to-use directive. It implicitly differentiates from search and count tools by positioning it as a precursor to search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | General 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. | |
| titleQuery | No | Search 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. | |
| phaseFilter | No | Filter by trial phase. Omit to count all phases — an empty list is rejected, not treated as "no filter". Values: EARLY_PHASE1, PHASE1, PHASE2, PHASE3, PHASE4, NA. | |
| outcomeQuery | No | Search 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. | |
| sponsorQuery | No | Sponsor/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. | |
| statusFilter | No | Filter by study status. Omit to count 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. | |
| locationQuery | No | Location 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. | |
| 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". 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. | |
| interventionQuery | No | Intervention/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. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery guidance when totalCount is 0 — suggests how to broaden the query or filters. |
| totalCount | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which establishes the safety and idempotency profile. The description adds meaningful behavioral context by stating it fetches no study data and is 'fast and lightweight', which helps an agent reason about performance and side-effect-free execution. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. It front-loads the purpose, states the key distinction ('without fetching study data'), and then gives concrete use-case guidance. There is no filler, repetition, or unnecessary context. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11-parameter schema (all optional, all fully documented in the schema) and the presence of an output schema, the description is complete for its role. It tells an agent what the tool does, when to use it, and that it avoids heavy data fetching. All edge cases (e.g., empty filter lists, bracket syntax) are covered by the schema itself, so the description does not need to repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — every parameter has a detailed description covering syntax, valid values, and filtering behavior (e.g., phaseFilter, statusFilter, advancedFilter). The tool description adds no additional parameter semantics beyond what the schema already provides. Since the schema carries the full burden of parameter documentation, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a resource ('total clinical trial study count from ClinicalTrials.gov'), and a key scope ('matching a query, without fetching study data'). This distinguishes it from siblings like clinicaltrials_search_studies (which returns full study records) and clinicaltrials_get_study_record (single study), so an agent can tell them apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage guidance: 'Use for quick statistics or to build breakdowns by calling multiple times with different filters' with examples (count by phase, status, recruiting vs completed). It clearly implies this is for counting rather than data retrieval, though it does not explicitly name alternative tools like clinicaltrials_search_studies for fetching data. The context is clear enough for appropriate routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| study | No | 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 | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly, idempotent, and open-world, so the safety profile is covered. The description adds valuable behavioral context beyond those annotations: cap parameters trim locations/outcomes/references, primary outcomes are never capped, and original totals are preserved in filtersApplied only when a cap actually trims the set. This gives an agent accurate expectations about how limits behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, lists the returned content compactly, and then states the cap-related behavior without redundancy. Every clause contributes information an agent needs; there is no filler or rephrasing of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, effective annotations, and an existing output schema, the description provides what is missing: the scope of the full study record and the nuanced behavior of optional trimming parameters. An agent has enough information to select and invoke this tool correctly without needing return-format details, since the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already carries detailed descriptions including defaults, bounds, and filter behavior. The tool description only summarizes the trimming behavior already documented in the schema, so it adds little semantic value beyond the structured field definitions. This is the correct baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch a single clinical trial study by NCT ID from ClinicalTrials.gov.' It clearly differentiates this single-record retrieval tool from the sibling search, count, and results tools, and names exactly what the returned record contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the core usage explicit: use this tool when you need a single study record by NCT ID. It also provides one concrete routing rule in the nearLocation parameter, directing broader geographic filtering to clinicaltrials_search_studies with geoFilter. It does not enumerate exclusions for every sibling, but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. A results-rich record can exceed 500KB per study in full mode — bound it with summary=true, narrower sections, or the outcomeLimit / adverseEventLimit caps, whose trims are reported per study in filtersApplied.
| Name | Required | Description | Default |
|---|---|---|---|
| nctIds | Yes | One or more NCT IDs (max 20) — an empty list is rejected. 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. For a middle ground, keep full mode and cap the two lists that carry the bulk with outcomeLimit / adverseEventLimit. | |
| sections | No | Filter which sections to return. Values: outcomes, adverseEvents, participantFlow, baseline, moreInfo. Omit for all sections — an empty list is rejected, not treated as omission. | |
| outcomeLimit | No | Optional cap on the number of outcome measures returned per study, taken in the order ClinicalTrials.gov publishes them. Omit for no cap (every measure). Applies to full mode only — summary mode is already condensed. Each surviving measure keeps its complete groups/classes/measurements/analyses tree. Upstream total preserved in filtersApplied.totalOutcomes only when the cap trims the list. | |
| adverseEventLimit | No | Optional cap on the number of serious and other adverse events returned per study, applied to each list separately in upstream order. Omit for no cap (every event). Applies to full mode only — summary mode already ranks the top 20 by participants affected. Event groups are never capped. Upstream totals preserved in filtersApplied.totalSeriousEvents / totalOtherEvents only when the cap trims a list. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| results | No | Results per study. |
| truncated | No | True when a cap trimmed a list on at least one study; absent when nothing was trimmed, matching filtersApplied one level down. Which study and which list is named in that study’s filtersApplied. |
| fetchErrors | No | Studies that could not be fetched. |
| studiesWithoutResults | No | NCT IDs that do not have results data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this read-only, open-world, and idempotent. The description adds valuable behavioral context: the hasResults prerequisite, the dramatic size range (5KB summary vs 500KB+ full), and the caps' behavior (order, trimming, filtersApplied reporting). This goes beyond the annotation flags, so 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense paragraph front-loads the key constraint (hasResults) before size warnings and caps. Every clause adds operational value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite (hasResults), sibling workflow (search first), size/performance behavior, and parameter interplay (summary vs full mode, limits). Output schema presumably conveys return shape, so missing description of return fields is acceptable. Minor gaps: no mention of authentication or pagination, but annotations don't signal those either.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all 5 parameters (100% coverage), so baseline is 3. The description adds practical semantics: how nctIds and summary interact, that sections lists are filters with no empty-list default, and the trimming behavior of outcomeLimit/adverseEventLimit with counters in filtersApplied. These nuances go beyond schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies a specific resource:
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: only for studies with hasResults true, and directs to use clinicaltrials_search_studies first to find such studies. It also advises on mode vs sections for large payloads. It does not explicitly mention when NOT to use (e.g., when you need the main study record), but the guidance provided is concrete and helpful, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. 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. | |
| fields | No | PascalCase 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. | |
| nctIds | No | Filter 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. | |
| 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. 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. | |
| phaseFilter | No | Filter 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. | |
| outcomeQuery | No | Search 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. | |
| sponsorQuery | No | Sponsor/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. | |
| statusFilter | No | Filter 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. | |
| locationQuery | No | Location 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. | |
| 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". 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. | |
| interventionQuery | No | Intervention/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. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery guidance when no studies matched — echoes the constraint and suggests how to broaden. Absent on pages with results. |
| studies | No | 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 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
clinicaltrials_find_eligible7 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / location / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "studies",
+ "searchCriteria",
+ "funnel"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `blank_value`: A parameter was supplied with a blank, whitespace-only, or empty-list value. `rate_limited`: ClinicalTrials.gov returned 429 after retry budget exhausted. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "blank_value",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "studies",
- "searchCriteria",
- "funnel"
-]clinicaltrials_get_field_definitions6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "fields",
+ "totalFields"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `path_not_found`: The dot-notation path does not match any node in the field tree. `rate_limited`: ClinicalTrials.gov returned 429 after retry budget exhausted. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "path_not_found",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "fields",
- "totalFields"
-]clinicaltrials_get_field_values6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "fieldStats"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `blank_value`: A parameter was supplied with a blank, whitespace-only, or empty-list value. `field_invalid`: A requested field name is not a valid PascalCase piece name. `rate_limited`: ClinicalTrials.gov returned 429 after retry budget exhausted. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "blank_value",
+ "field_invalid",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "fieldStats"
-]clinicaltrials_get_study_count6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "totalCount"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `blank_value`: A parameter was supplied with a blank, whitespace-only, or empty-list value. `field_invalid`: A field name in the advanced filter or AREA[] expression is invalid (often a module name instead of a piece name). `enum_invalid`: statusFilter or phaseFilter contains a value ClinicalTrials.gov does not accept. `query_parse_error`: A free-text query or advancedFilter expression uses syntax the upstream Essie parser rejects — typically a `[` or `]` outside an AREA[…] / RANGE[…] expression, an unmatched `(` / `)`, or an unterminated quote in a query/conditionQuery/etc. value. `rate_limited`: ClinicalTrials.gov returned 429 after retry budget exhausted. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "blank_value",
+ "field_invalid",
+ "enum_invalid",
+ "query_parse_error",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "totalCount"
-]clinicaltrials_get_study_record7 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / nearLocation / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "study",
+ "filtersApplied"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `study_not_found`: The provided NCT ID does not match any study at ClinicalTrials.gov. `rate_limited`: ClinicalTrials.gov returned 429 after retry budget exhausted. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "study_not_found",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "study",
- "filtersApplied"
-]clinicaltrials_get_study_results6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `blank_value`: A parameter was supplied with a blank, whitespace-only, or empty-list value. `rate_limited`: ClinicalTrials.gov returned 429 after retry budget exhausted. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "blank_value",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "results"
-]clinicaltrials_search_studies6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "studies"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `blank_value`: A parameter was supplied with a blank, whitespace-only, or empty-list value. `ids_not_found`: One or more NCT IDs in the nctIds filter are not present at ClinicalTrials.gov. `field_invalid`: A field name in the fields parameter or AREA[] expression is invalid (often a module name instead of a piece name). `enum_invalid`: statusFilter or phaseFilter contains a value ClinicalTrials.gov does not accept. `query_parse_error`: A free-text query or advancedFilter expression uses syntax the upstream Essie parser rejects — typically a `[` or `]` outside an AREA[…] / RANGE[…] expression, an unmatched `(` / `)`, or an unterminated quote in a query/conditionQuery/etc. value. `geo_invalid`: geoFilter is not a well-formed distance(lat,lon,radius) expression. `sort_invalid`: sort is not FieldName:asc / FieldName:desc, or names more than 2 fields. `rate_limited`: ClinicalTrials.gov returned 429 after retry budget exhausted. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "blank_value",
+ "ids_not_found",
+ "field_invalid",
+ "enum_invalid",
+ "query_parse_error",
+ "geo_invalid",
+ "sort_invalid",
+ "rate_limited"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "studies"
-]clinicaltrials_find_eligible2 fields changedInput schema / properties / locationLimitAdded value: +{
+ "default": 10,
+ "description": "Cap on the sites returned per candidate. Each candidate keeps only the sites matching the requested location at the narrowest level that matched (city, else state, else country), capped at this many; the rest of the study's registered sites are omitted. The cap governs those matched sites — when none of them is recruiting, the candidate's nearest recruiting site is added on top of it, so a candidate can carry one site more than this. Raise it to see more nearby sites, or fetch the complete site list with clinicaltrials_get_study_record. Each candidate reports totalLocations / matchedLocations / locationsTruncated / nearestRecruitingSiteAdded in locationSummary only when the bound actually dropped sites.",
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / studies / descriptionPrevious value: -"Matching studies with eligibility and location fields."New value: +"Matching studies with eligibility and location fields. Each candidate's protocolSection.contactsLocationsModule.locations is BOUNDED to the sites matching the requested location (capped at locationLimit) plus, when none of those is recruiting, the candidate's nearest recruiting site — not the study's full registered site list. A candidate whose sites were bounded also carries a top-level locationSummary object — { totalLocations, matchedLocations, locationsTruncated, nearestRecruitingSiteAdded?, retrieveFullStudyWith } — absent when nothing was dropped; nearestRecruitingSiteAdded is present only when that extra site was added. Fetch a study's complete record and site list with clinicaltrials_get_study_record."clinicaltrials_get_study_results5 fields changedInput schema / properties / adverseEventLimitAdded value: +{
+ "description": "Optional cap on the number of serious and other adverse events returned per study, applied to each list separately in upstream order. Omit for no cap (every event). Applies to full mode only — summary mode already ranks the top 20 by participants affected. Event groups are never capped. Upstream totals preserved in filtersApplied.totalSeriousEvents / totalOtherEvents only when the cap trims a list.",
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / outcomeLimitAdded value: +{
+ "description": "Optional cap on the number of outcome measures returned per study, taken in the order ClinicalTrials.gov publishes them. Omit for no cap (every measure). Applies to full mode only — summary mode is already condensed. Each surviving measure keeps its complete groups/classes/measurements/analyses tree. Upstream total preserved in filtersApplied.totalOutcomes only when the cap trims the list.",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / summary / descriptionPrevious value: -"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."New value: +"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. For a middle ground, keep full mode and cap the two lists that carry the bulk with outcomeLimit / adverseEventLimit."Output schema / properties / results / items / properties / filtersAppliedAdded value: +{
+ "additionalProperties": false,
+ "description": "What a cap trimmed on this study — present only when a cap actually reduced a list. Absent means the payload is the complete upstream set for the requested sections.",
+ "properties": {
+ "adverseEventLimit": {
+ "description": "Echo of the adverseEventLimit input — present only when the cap trimmed a list.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "outcomeLimit": {
+ "description": "Echo of the outcomeLimit input — present only when the cap trimmed the list.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "totalOtherEvents": {
+ "description": "Upstream other adverse event count before adverseEventLimit trimmed the list.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "totalOutcomes": {
+ "description": "Upstream outcome measure count before outcomeLimit trimmed the list.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "totalSeriousEvents": {
+ "description": "Upstream serious adverse event count before adverseEventLimit trimmed the list.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when a cap trimmed a list on at least one study; absent when nothing was trimmed, matching filtersApplied one level down. Which study and which list is named in that study’s filtersApplied.",
+ "type": "boolean"
+}clinicaltrials_find_eligible1 field changedInput schema / properties / conditions / minItemsRemoved value: -1clinicaltrials_get_field_values2 fields changedInput schema / properties / fields / anyOfPrevious value: -[
- {
- "description": "A single PascalCase field name.",
- "type": "string"
- },
- {
- "description": "Multiple PascalCase field names (at least one required).",
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single PascalCase field name.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple PascalCase field names (at least one required).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / fields / descriptionPrevious value: -"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."New value: +"PascalCase field name(s) to get value statistics for — an empty list is rejected, not treated as \"every field\". Examples: OverallStatus, Phase, StudyType, Sex, LeadSponsorClass. Use clinicaltrials_get_field_definitions with a query to find more field names."clinicaltrials_get_study_count9 fields changedInput schema / properties / conditionQuery / descriptionPrevious value: -"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."New value: +"Condition/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."Input schema / properties / interventionQuery / descriptionPrevious value: -"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."New value: +"Intervention/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."Input schema / properties / locationQuery / descriptionPrevious value: -"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."New value: +"Location 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."Input schema / properties / outcomeQuery / descriptionPrevious value: -"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."New value: +"Search 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."Input schema / properties / phaseFilter / anyOfPrevious value: -[
- {
- "description": "A single phase value.",
- "type": "string"
- },
- {
- "description": "Multiple phase values (OR).",
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single phase value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple phase values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / query / descriptionPrevious value: -"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."New value: +"General 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."Input schema / properties / sponsorQuery / descriptionPrevious value: -"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."New value: +"Sponsor/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."Input schema / properties / statusFilter / anyOfPrevious value: -[
- {
- "description": "A single status value.",
- "type": "string"
- },
- {
- "description": "Multiple status values (OR).",
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single status value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple status values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / titleQuery / descriptionPrevious value: -"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."New value: +"Search 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."clinicaltrials_get_study_results3 fields changedInput schema / properties / nctIds / anyOfPrevious value: -[
- {
- "description": "A single NCT ID.",
- "pattern": "^NCT\\d{8}$",
- "type": "string"
- },
- {
- "description": "Multiple NCT IDs (max 20).",
- "items": {
- "pattern": "^NCT\\d{8}$",
- "type": "string"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single NCT ID.",
+ "pattern": "^NCT\\d{8}$",
+ "type": "string"
+ },
+ {
+ "description": "Multiple NCT IDs (max 20).",
+ "items": {
+ "pattern": "^NCT\\d{8}$",
+ "type": "string"
+ },
+ "maxItems": 20,
+ "type": "array"
+ }
+]Input schema / properties / nctIds / descriptionPrevious value: -"One or more NCT IDs (max 20). E.g., \"NCT12345678\" or [\"NCT12345678\", \"NCT87654321\"]. Use summary=true for large batches to avoid large payloads."New value: +"One or more NCT IDs (max 20) — an empty list is rejected. E.g., \"NCT12345678\" or [\"NCT12345678\", \"NCT87654321\"]. Use summary=true for large batches to avoid large payloads."Input schema / properties / sections / anyOfPrevious value: -[
- {
- "description": "A single section name.",
- "enum": [
- "outcomes",
- "adverseEvents",
- "participantFlow",
- "baseline",
- "moreInfo"
- ],
- "type": "string"
- },
- {
- "description": "Multiple section names.",
- "items": {
- "enum": [
- "outcomes",
- "adverseEvents",
- "participantFlow",
- "baseline",
- "moreInfo"
- ],
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single section name.",
+ "enum": [
+ "outcomes",
+ "adverseEvents",
+ "participantFlow",
+ "baseline",
+ "moreInfo"
+ ],
+ "type": "string"
+ },
+ {
+ "description": "Multiple section names.",
+ "items": {
+ "enum": [
+ "outcomes",
+ "adverseEvents",
+ "participantFlow",
+ "baseline",
+ "moreInfo"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]clinicaltrials_search_studies11 fields changedInput schema / properties / conditionQuery / descriptionPrevious value: -"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."New value: +"Condition/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."Input schema / properties / fields / minItemsRemoved value: -1Input schema / properties / interventionQuery / descriptionPrevious value: -"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."New value: +"Intervention/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."Input schema / properties / locationQuery / descriptionPrevious value: -"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."New value: +"Location 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."Input schema / properties / nctIds / descriptionPrevious value: -"Filter to specific NCT IDs for batch lookups."New value: +"Filter 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."Input schema / properties / outcomeQuery / descriptionPrevious value: -"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."New value: +"Search 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."Input schema / properties / phaseFilter / anyOfPrevious value: -[
- {
- "description": "A single phase value.",
- "type": "string"
- },
- {
- "description": "Multiple phase values (OR).",
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single phase value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple phase values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / query / descriptionPrevious value: -"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."New value: +"General 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."Input schema / properties / sponsorQuery / descriptionPrevious value: -"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."New value: +"Sponsor/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."Input schema / properties / statusFilter / anyOfPrevious value: -[
- {
- "description": "A single status value.",
- "type": "string"
- },
- {
- "description": "Multiple status values (OR).",
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single status value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple status values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / titleQuery / descriptionPrevious value: -"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."New value: +"Search 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."clinicaltrials_get_study_count4 fields changedInput schema / properties / phaseFilter / anyOfPrevious value: -[
- {
- "description": "A single phase value.",
- "type": "string"
- },
- {
- "description": "Multiple phase values (OR).",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single phase value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple phase values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / phaseFilter / descriptionPrevious value: -"Filter by trial phase. Values: EARLY_PHASE1, PHASE1, PHASE2, PHASE3, PHASE4, NA."New value: +"Filter by trial phase. Omit to count all phases — an empty list is rejected, not treated as \"no filter\". Values: EARLY_PHASE1, PHASE1, PHASE2, PHASE3, PHASE4, NA."Input schema / properties / statusFilter / anyOfPrevious value: -[
- {
- "description": "A single status value.",
- "type": "string"
- },
- {
- "description": "Multiple status values (OR).",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single status value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple status values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / statusFilter / descriptionPrevious value: -"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."New value: +"Filter by study status. Omit to count 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."clinicaltrials_get_study_results2 fields changedInput schema / properties / sections / anyOfPrevious value: -[
- {
- "description": "A single section name.",
- "enum": [
- "outcomes",
- "adverseEvents",
- "participantFlow",
- "baseline",
- "moreInfo"
- ],
- "type": "string"
- },
- {
- "description": "Multiple section names.",
- "items": {
- "enum": [
- "outcomes",
- "adverseEvents",
- "participantFlow",
- "baseline",
- "moreInfo"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single section name.",
+ "enum": [
+ "outcomes",
+ "adverseEvents",
+ "participantFlow",
+ "baseline",
+ "moreInfo"
+ ],
+ "type": "string"
+ },
+ {
+ "description": "Multiple section names.",
+ "items": {
+ "enum": [
+ "outcomes",
+ "adverseEvents",
+ "participantFlow",
+ "baseline",
+ "moreInfo"
+ ],
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / sections / descriptionPrevious value: -"Filter which sections to return. Values: outcomes, adverseEvents, participantFlow, baseline, moreInfo. Omit for all sections."New value: +"Filter which sections to return. Values: outcomes, adverseEvents, participantFlow, baseline, moreInfo. Omit for all sections — an empty list is rejected, not treated as omission."clinicaltrials_search_studies7 fields changedInput schema / properties / fields / descriptionPrevious value: -"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."New value: +"PascalCase 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."Input schema / properties / fields / minItemsAdded value: +1Input schema / properties / phaseFilter / anyOfPrevious value: -[
- {
- "description": "A single phase value.",
- "type": "string"
- },
- {
- "description": "Multiple phase values (OR).",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single phase value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple phase values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / phaseFilter / descriptionPrevious value: -"Filter by trial phase. Values: EARLY_PHASE1, PHASE1, PHASE2, PHASE3, PHASE4, NA."New value: +"Filter 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."Input schema / properties / statusFilter / anyOfPrevious value: -[
- {
- "description": "A single status value.",
- "type": "string"
- },
- {
- "description": "Multiple status values (OR).",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single status value.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple status values (OR).",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / statusFilter / descriptionPrevious value: -"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."New value: +"Filter 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."Output schema / properties / nextPageToken / descriptionPrevious value: -"Token for the next page. Absent on last page."New value: +"Token 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."clinicaltrials_get_study_results1 field changedInput schema / properties / summary / descriptionPrevious value: -"Return condensed summaries instead of full data. Reduces payload from ~200KB to ~5KB per study. Summaries include outcome titles, types, timeframes, group counts, and top-level stats — omitting individual measurements, analyses, and per-group data."New value: +"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."clinicaltrials_get_field_definitions1 field changedOutput schema / properties / totalMatchesAdded value: +{
+ "description": "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.",
+ "type": "number"
+}clinicaltrials_get_study_count7 fields changedInput schema / properties / conditionQuery / descriptionPrevious value: -"Condition/disease-specific search. E.g., \"Type 2 Diabetes\", \"non-small cell lung cancer\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / interventionQuery / descriptionPrevious value: -"Intervention/treatment search. E.g., \"pembrolizumab\", \"cognitive behavioral therapy\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / locationQuery / descriptionPrevious value: -"Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / outcomeQuery / descriptionPrevious value: -"Search within outcome measure fields. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / query / descriptionPrevious value: -"General free-text search across all fields. Plain words plus AND, OR, NOT. `[ ]` are reserved (advancedFilter AREA[] only); `( )` group sub-expressions and work when matched; `,` acts as AND. For field-scoped searches, use the dedicated *Query parameters (conditionQuery, interventionQuery, etc.) or advancedFilter with AREA[FieldName]value."New value: +"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."Input schema / properties / sponsorQuery / descriptionPrevious value: -"Sponsor/collaborator name search. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / titleQuery / descriptionPrevious value: -"Search within study titles and acronyms only. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."clinicaltrials_search_studies8 fields changedInput schema / properties / conditionQuery / descriptionPrevious value: -"Condition/disease-specific search. E.g., \"Type 2 Diabetes\", \"non-small cell lung cancer\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / geoFilter / descriptionPrevious value: -"Geographic proximity filter. Format: distance(lat,lon,radius). E.g., \"distance(47.6062,-122.3321,50mi)\" for studies within 50 miles of Seattle. 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."New value: +"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."Input schema / properties / interventionQuery / descriptionPrevious value: -"Intervention/treatment search. E.g., \"pembrolizumab\", \"cognitive behavioral therapy\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / locationQuery / descriptionPrevious value: -"Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / outcomeQuery / descriptionPrevious value: -"Search within outcome measure fields. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / query / descriptionPrevious value: -"General free-text search across all fields. Plain words plus AND, OR, NOT. `[ ]` are reserved (advancedFilter AREA[] only); `( )` group sub-expressions and work when matched; `,` acts as AND. For field-scoped searches, use the dedicated *Query parameters (conditionQuery, interventionQuery, etc.) or advancedFilter with AREA[FieldName]value."New value: +"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."Input schema / properties / sponsorQuery / descriptionPrevious value: -"Sponsor/collaborator name search. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."Input schema / properties / titleQuery / descriptionPrevious value: -"Search within study titles and acronyms only. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."clinicaltrials_find_eligible5 fields changedOutput schema / properties / searchCriteria / descriptionPrevious value: -"Normalized search criteria applied to this eligibility query."New value: +"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)."Output schema / properties / searchCriteria / properties / advancedFilterAdded value: +{
+ "description": "The exact AREA[] advancedFilter (age range, plus sex/healthy-volunteer when constrained) sent upstream. Pass as advancedFilter to clinicaltrials_search_studies to reproduce the demographic constraints.",
+ "type": "string"
+}Output schema / properties / searchCriteria / properties / conditionQueryAdded value: +{
+ "description": "The exact queryCond string sent upstream (multi-word terms quoted, OR-joined). Pass as conditionQuery to clinicaltrials_search_studies to reproduce the full match set beyond the maxResults cap.",
+ "type": "string"
+}Output schema / properties / searchCriteria / properties / location / descriptionPrevious value: -"Location searched."New value: +"The exact queryLocn string sent upstream (city/state/country joined). Pass as locationQuery to clinicaltrials_search_studies to reproduce the location filter beyond the maxResults cap."Output schema / properties / searchCriteria / properties / statusFilterAdded value: +{
+ "description": "The status filter applied ([\"RECRUITING\"] when recruitingOnly). Pass as statusFilter to clinicaltrials_search_studies. Absent when recruitingOnly is false.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}clinicaltrials_search_studies2 fields changedOutput schema / properties / requestedFields / descriptionPrevious value: -"Echo of the explicit fields parameter — present only when the caller passed fields. Lifts the default truncation cap so all requested leaves render in full."New value: +"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."Output schema / properties / studies / descriptionPrevious value: -"Matching studies. Each entry is a nested ClinicalTrials.gov study record — top-level keys: protocolSection, derivedSection, hasResults, resultsSection, documentSection. Use clinicaltrials_get_field_definitions to explore the schema."New value: +"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."clinicaltrials_get_field_values2 fields changedOutput schema / properties / fieldStats / items / properties / multiValuedAdded value: +{
+ "description": "True when the field is array-typed (a study can carry several values, e.g. Phase, Condition), so the per-value studiesCount buckets sum above the study total. Use to avoid computing a percentage against the corpus.",
+ "type": "boolean"
+}Output schema / properties / fieldStats / items / properties / topValues / descriptionPrevious value: -"Values ranked by frequency (capped at 250 by the API). Present for ENUM/STRING fields."New value: +"Values ranked by frequency (capped at 250 by the API). Present for ENUM/STRING fields. When multiValued is true, studiesCount sums can exceed the study total."clinicaltrials_search_studies1 field changedInput schema / properties / geoFilter / descriptionPrevious value: -"Geographic proximity filter. Format: distance(lat,lon,radius). E.g., \"distance(47.6062,-122.3321,50mi)\" for studies within 50 miles of Seattle."New value: +"Geographic proximity filter. Format: distance(lat,lon,radius). E.g., \"distance(47.6062,-122.3321,50mi)\" for studies within 50 miles of Seattle. 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."clinicaltrials_get_field_values1 field changedInput schema / properties / fields / anyOfPrevious value: -[
- {
- "description": "A single PascalCase field name.",
- "type": "string"
- },
- {
- "description": "Multiple PascalCase field names.",
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single PascalCase field name.",
+ "type": "string"
+ },
+ {
+ "description": "Multiple PascalCase field names (at least one required).",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]clinicaltrials_get_study_count1 field changedOutput schema / properties / searchCriteria / descriptionPrevious value: -"Echo of active query/filter criteria applied to this count."New value: +"Echo of active query/filter criteria applied to this count, including sentinelFilterActive when the default unknown-enrollment exclusion is in effect."clinicaltrials_get_study_record7 fields changedInput schema / properties / locationLimit / descriptionPrevious value: -"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 whenever a cap is applied."New value: +"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."Input schema / properties / nearLocation / descriptionPrevious value: -"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. For broader geographic filtering across studies, use clinicaltrials_search_studies with geoFilter."New value: +"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."Input schema / properties / outcomeLimit / descriptionPrevious value: -"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 whenever a cap is applied."New value: +"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."Input schema / properties / referenceLimit / descriptionPrevious value: -"Optional cap on the number of references returned. Omit for no cap (full upstream list). Original total preserved in filtersApplied.totalReferences whenever a cap is applied. seeAlsoLinks are never capped."New value: +"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 / properties / filtersApplied / properties / locationLimit / descriptionPrevious value: -"Echo of the locationLimit input."New value: +"Echo of the locationLimit input — present only when the cap trimmed the list."Output schema / properties / filtersApplied / properties / outcomeLimit / descriptionPrevious value: -"Echo of the outcomeLimit input."New value: +"Echo of the outcomeLimit input — present only when the cap trimmed a list."Output schema / properties / filtersApplied / properties / referenceLimit / descriptionPrevious value: -"Echo of the referenceLimit input."New value: +"Echo of the referenceLimit input — present only when the cap trimmed the list."clinicaltrials_find_eligible1 field changedInput schema / properties / conditions / descriptionPrevious value: -"Medical conditions or diagnoses. E.g., [\"Type 2 Diabetes\", \"Hypertension\"]. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."New value: +"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."clinicaltrials_get_study_record3 fields changedInput schema / properties / referenceLimitAdded value: +{
+ "description": "Optional cap on the number of references returned. Omit for no cap (full upstream list). Original total preserved in filtersApplied.totalReferences whenever a cap is applied. seeAlsoLinks are never capped.",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / filtersApplied / properties / referenceLimitAdded value: +{
+ "description": "Echo of the referenceLimit input.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / filtersApplied / properties / totalReferencesAdded value: +{
+ "description": "Upstream reference count before referenceLimit was applied.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}clinicaltrials_search_studies1 field changedInput schema / properties / sort / descriptionPrevious value: -"Sort order. Format: FieldName:asc or FieldName:desc. E.g., \"LastUpdatePostDate:desc\", \"EnrollmentCount:desc\". Max 2 fields comma-separated. Use clinicaltrials_get_field_definitions to find sortable field names."New value: +"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."clinicaltrials_get_field_definitions4 fields changedOutput schema / properties / capAdded value: +{
+ "description": "The limit cap applied to this search (search mode only).",
+ "type": "number"
+}Output schema / properties / notice / descriptionPrevious value: -"Recovery guidance when search mode returns no matches — suggests alternative keywords."New value: +"Recovery guidance when search mode returns no matches, or a truncation note when results are capped."Output schema / properties / shownAdded value: +{
+ "description": "Number of fields returned (search mode only).",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when the field list was capped by the limit parameter (search mode only).",
+ "type": "boolean"
+}clinicaltrials_find_eligible1 field changedInput schema / properties / conditions / descriptionPrevious value: -"Medical conditions or diagnoses. E.g., [\"Type 2 Diabetes\", \"Hypertension\"]. Plain words only — reserved chars `[ ] ( ) ,` inside an entry will fail."New value: +"Medical conditions or diagnoses. E.g., [\"Type 2 Diabetes\", \"Hypertension\"]. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."clinicaltrials_get_study_count7 fields changedInput schema / properties / conditionQuery / descriptionPrevious value: -"Condition/disease-specific search. E.g., \"Type 2 Diabetes\", \"non-small cell lung cancer\". Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Condition/disease-specific search. E.g., \"Type 2 Diabetes\", \"non-small cell lung cancer\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / interventionQuery / descriptionPrevious value: -"Intervention/treatment search. E.g., \"pembrolizumab\", \"cognitive behavioral therapy\". Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Intervention/treatment search. E.g., \"pembrolizumab\", \"cognitive behavioral therapy\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / locationQuery / descriptionPrevious value: -"Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / outcomeQuery / descriptionPrevious value: -"Search within outcome measure fields. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Search within outcome measure fields. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / query / descriptionPrevious value: -"General free-text search across all fields. Plain words plus AND, OR, NOT only — reserved chars `[ ] ( ) ,` will fail. For field-scoped searches, use the dedicated *Query parameters (conditionQuery, interventionQuery, etc.) or advancedFilter with AREA[FieldName]value."New value: +"General free-text search across all fields. Plain words plus AND, OR, NOT. `[ ]` are reserved (advancedFilter AREA[] only); `( )` group sub-expressions and work when matched; `,` acts as AND. For field-scoped searches, use the dedicated *Query parameters (conditionQuery, interventionQuery, etc.) or advancedFilter with AREA[FieldName]value."Input schema / properties / sponsorQuery / descriptionPrevious value: -"Sponsor/collaborator name search. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Sponsor/collaborator name search. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / titleQuery / descriptionPrevious value: -"Search within study titles and acronyms only. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Search within study titles and acronyms only. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."clinicaltrials_search_studies7 fields changedInput schema / properties / conditionQuery / descriptionPrevious value: -"Condition/disease-specific search. E.g., \"Type 2 Diabetes\", \"non-small cell lung cancer\". Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Condition/disease-specific search. E.g., \"Type 2 Diabetes\", \"non-small cell lung cancer\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / interventionQuery / descriptionPrevious value: -"Intervention/treatment search. E.g., \"pembrolizumab\", \"cognitive behavioral therapy\". Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Intervention/treatment search. E.g., \"pembrolizumab\", \"cognitive behavioral therapy\". Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / locationQuery / descriptionPrevious value: -"Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Location search — city, state, country, or facility name. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / outcomeQuery / descriptionPrevious value: -"Search within outcome measure fields. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Search within outcome measure fields. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / query / descriptionPrevious value: -"General free-text search across all fields. Plain words plus AND, OR, NOT only — reserved chars `[ ] ( ) ,` will fail. For field-scoped searches, use the dedicated *Query parameters (conditionQuery, interventionQuery, etc.) or advancedFilter with AREA[FieldName]value."New value: +"General free-text search across all fields. Plain words plus AND, OR, NOT. `[ ]` are reserved (advancedFilter AREA[] only); `( )` group sub-expressions and work when matched; `,` acts as AND. For field-scoped searches, use the dedicated *Query parameters (conditionQuery, interventionQuery, etc.) or advancedFilter with AREA[FieldName]value."Input schema / properties / sponsorQuery / descriptionPrevious value: -"Sponsor/collaborator name search. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Sponsor/collaborator name search. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."Input schema / properties / titleQuery / descriptionPrevious value: -"Search within study titles and acronyms only. Plain words plus AND/OR/NOT only — reserved chars: [ ] ( ) ,"New value: +"Search within study titles and acronyms only. Plain words plus AND/OR/NOT. `[ ]` are reserved; `( )` group sub-expressions when matched; `,` acts as AND."clinicaltrials_get_study_results3 fields changedInput schema / properties / sections / anyOfPrevious value: -[
- {
- "description": "A single section name.",
- "enum": [
- "outcomes",
- "adverseEvents",
- "participantFlow",
- "baseline"
- ],
- "type": "string"
- },
- {
- "description": "Multiple section names.",
- "items": {
- "enum": [
- "outcomes",
- "adverseEvents",
- "participantFlow",
- "baseline"
- ],
- "type": "string"
- },
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "A single section name.",
+ "enum": [
+ "outcomes",
+ "adverseEvents",
+ "participantFlow",
+ "baseline",
+ "moreInfo"
+ ],
+ "type": "string"
+ },
+ {
+ "description": "Multiple section names.",
+ "items": {
+ "enum": [
+ "outcomes",
+ "adverseEvents",
+ "participantFlow",
+ "baseline",
+ "moreInfo"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / sections / descriptionPrevious value: -"Filter which sections to return. Values: outcomes, adverseEvents, participantFlow, baseline. Omit for all sections."New value: +"Filter which sections to return. Values: outcomes, adverseEvents, participantFlow, baseline, moreInfo. Omit for all sections."Output schema / properties / results / items / properties / moreInfoAdded value: +{
+ "additionalProperties": {},
+ "description": "Results metadata from moreInfoModule. Summary mode: limitationsAndCaveats, certainAgreement flags (piSponsorEmployee, restrictiveAgreement, restrictionType), and pointOfContact. Full mode: adds certainAgreement.otherDetails.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Clinical trial search and status from ClinicalTrials.gov
Provide structured access to ClinicalTrials.gov data for searching, retrieving, and analyzing clin…
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.
Scrape ClinicalTrials.gov studies by condition, sponsor, phase, status or location. Pay per row.
Add one secure layer between your agents and this server.
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.
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.
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.
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.