ClinicalTrials.gov MCP Server

Quick Verdict

ClinicalTrials.gov MCP Server is an open-source community project maintained by cyanheads. It translates the official ClinicalTrials.gov REST API v2 into Model Context Protocol tools for compatible clients. As of July 21, 2026, the current release is v2.8.2, with seven read-only tools, one study resource, and one trial-landscape prompt. It is not an MCP product published, reviewed, or endorsed by the National Library of Medicine, the National Institutes of Health, or ClinicalTrials.gov. The upstream registry is official; this wrapper and its hosted endpoint are not.

The server is useful for public trial discovery, structured extraction, and research workflows with human review. It must not be treated as a diagnostic service, a treatment recommendation engine, or an automated eligibility decision. Its candidate-matching tool narrows records using age, sex, conditions, and location, but protocol criteria can be nuanced, outdated, or incompletely represented in structured fields. A trial site and qualified clinician must make the real eligibility determination.

Best For

• Clinical research, drug intelligence, and medical information teams connecting public registry data to an MCP research assistant.
• Analysts extracting protocols, outcomes, adverse events, and locations by NCT identifier while retaining source records for verification.
• Engineering teams able to self-host, control logs, restrict client permissions, and establish medical review procedures.
• Researchers building reproducible landscape analyses from counts, filters, field definitions, and explicit query dates.
• It is not suitable for uploading identifiable medical records or automating triage, diagnosis, prescribing, emergency care, or enrollment decisions.

Key Features

• Study search: full-text and field queries for conditions, interventions, sponsors, locations, status, and phase, with pagination, sorting, selected fields, and geographic distance filters.
• Record and result retrieval: fetch full study records by NCT ID and extract posted outcomes, adverse events, participant flow, and baseline characteristics. Summary and section filters reduce unnecessary context.
• Counts and schema discovery: count matching studies without downloading all records, inspect valid field values, and navigate field definitions before constructing an automated query.
• Candidate matching: rank recruiting studies against limited demographics and conditions. The output is a research shortlist, not confirmation that a person qualifies.
• Flexible deployment: local bunx or npx stdio, Streamable HTTP, and Docker, with optional authentication, structured logging, and OpenTelemetry for controlled deployments.
• Read-only upstream access: tools query the registry rather than changing it, which reduces mutation risk but does not remove confidentiality, interpretation, or supply-chain risk.

Use Cases

A research team can count trials for a condition by phase and geography, inspect the outcome fields of selected studies, build an NCT-linked evidence table, or monitor recruiting records for a documented public query. A patient-support application can use coarse, de-identified criteria to prepare questions for a trial coordinator, provided every result is clearly presented as a candidate and linked back to the official record.

Do not send names, telephone numbers, medical record identifiers, genomic information, images, complete histories, or free-text clinical notes to the community-hosted endpoint. Even a combination of age, rare disease, and precise location may re-identify someone. Collect only what the query requires, generalize location where possible, document consent and purpose, and evaluate whether self-hosting is required.

Registry data is public, but it is not necessarily complete, current, independently validated, or comparable across studies. Sponsor-submitted status and contact information can lag. Missing results do not prove a treatment failed, and a populated result field does not establish clinical significance. Preserve NCT IDs, query dates, filters, missing fields, and reviewer decisions rather than presenting a model summary as primary evidence.

Pricing

The wrapper is licensed under Apache-2.0, and the ClinicalTrials.gov API does not require an API key. The community-hosted endpoint and local package have no software subscription fee. Self-hosting still incurs compute, networking, monitoring, security review, dependency maintenance, and incident-response costs. Release v2.8.2 corrected a recovery hint in field-definition lookup; consult repository releases rather than assuming this page guarantees compatibility.

Use public hosting only to evaluate non-sensitive queries. For patient-related, confidential strategy, or regulated workflows, review the source, pin a release, and operate it inside an approved environment. Include the MCP client, model provider, gateway, observability stack, and storage in the total cost and data-flow review.

Pros

• Seven focused tools cover search, counts, schema discovery, records, results, and candidate matching.
• Result section filters and compact summaries limit oversized payloads before they enter model context.
• The official upstream API is public and keyless, while local stdio can keep the wrapper and its logs under organizational control.
• Read-only, structured calls are easier to audit than unconstrained browsing or copied registry text.
• Apache-2.0 source code supports inspection and institution-specific deployment.
• Explicit NCT identifiers make it practical to return to the official record for human verification.

Cons

• It is an unofficial community wrapper; U.S. government agencies do not guarantee its security, support, or hosted availability.
• ClinicalTrials.gov alone does not cover every national registry, journal article, regulator decision, or real-world evidence source.
• Candidate matching is limited by structured criteria, terminology, fuzzy upstream search, and record freshness.
• A hosted intermediary adds logging, cross-border, retention, and third-party processing concerns.
• MCP output can still be omitted, misread, or incorrectly summarized by the selected model.
• Users need domain knowledge to distinguish registry metadata from clinical evidence and medical advice.

Alternatives

FAQ

Is this the official ClinicalTrials.gov MCP server?

No. Cyanheads maintains this unofficial community wrapper. It reads the official API, but neither the code nor the public hosted endpoint represents a U.S. government agency.

Can it confirm that a patient qualifies for a trial?

No. It can produce candidates from limited fields. A trial team must evaluate the complete protocol, records, tests, timing, and clinical circumstances.

May I send patient records to the public hosted endpoint?

That is not a safe default. Avoid identifiable health information, minimize and de-identify every query, and use an approved controlled deployment only after privacy and compliance review.

Does read-only mean there is no security risk?

No. Read-only means the tool does not modify ClinicalTrials.gov. Query text, logs, model context, dependencies, and generated conclusions can still expose data or cause harm.

Does v2.8.2 require a ClinicalTrials.gov API key?

No. The upstream v2 API is public, though rate limits, outages, timeouts, and changing fields still require operational handling.

Can extracted results be used directly for treatment decisions?

No. Registry records are not individualized medical advice. Review publications, regulator materials, protocol limitations, and the official record with qualified professionals.

Bottom Line

ClinicalTrials.gov MCP Server is a practical structured bridge between public trial data and MCP clients. Search, schema discovery, and compact result extraction can shorten research work, but its durable role is an unofficial read-only research connector, not a clinical system or eligibility authority. Evaluate it first with non-sensitive public queries. If it enters a regulated workflow, self-host an audited and pinned release, map every processor and log, preserve source identifiers and query dates, and require qualified people to verify the official record before any patient-facing conclusion.