How do I use clinicaltrials-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@clinicaltrials-mcp Find recruiting Phase III breast cancer trials" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

clinicaltrials-mcp

by agents100x

Overview Schema Related Servers Score Discussions

Python

Remote

clinicaltrials-mcp

Conversational access to 400,000+ clinical trials — for pharma analysts, CRO teams, and health-tech builders.

A Python MCP server that connects Cursor, Claude Desktop, and any MCP-compatible client directly to ClinicalTrials.gov. Ask questions in plain English. Get clean, structured answers in seconds — no API keys, no setup, no parsing raw JSON.

PyPI version Python 3.12+ License: MIT

The Problem

ClinicalTrials.gov is the world's largest registry of clinical research — 400,000+ trials, decades of outcomes data, all publicly accessible via a free API.

But the API gives you this:

{
  "protocolSection": {
    "eligibilityModule": {
      "eligibilityCriteria": "Inclusion Criteria:\n\n* Willing to sign the informed consent form;\n* ≥18 years old;\n* Diagnosed histologically or cytologically with local advanced or metastatic HER2-positive malignant solid cancer...",
      "stdAges": ["ADULT", "OLDER_ADULT"]
    },
    "adverseEventsModule": {
      "eventGroups": [...],
      "seriousEvents": [...],
      "otherEvents": [...]
    }
  }
}

Every field is optional. Eligibility criteria are a single wall of free text. Adverse events are split across two arrays that reference a separate groups table by ID. Every trial returns a different shape.

To compare eligibility across 10 trials, you write 10 scripts — or spend two days copying into Excel. To find the adverse event profile of a completed study, you navigate five nested objects and cross-reference three tables. To do a competitive landscape analysis across a therapeutic area, you're looking at a week of work.

This is not a data problem. It is a tooling problem.

With clinicaltrials-mcp, the same work takes a conversation:

"Compare the eligibility criteria for these 5 NASH trials" "What were the Grade 3+ adverse events in NCT02142803?" "Find recruiting HER2-positive trials near Mumbai"

Seconds. Followed up. Drilled down. No scripts, no parsing, no Excel.

Related MCP server: clinicaltrialsgov-mcp-server

Install & Setup

Step 1 — Install

pip install clinicaltrials-mcp

No API key. No account. No configuration required.

Step 2 — Add to your MCP client

{
  "mcpServers": {
    "clinicaltrials": {
      "command": "uvx",
      "args": ["clinicaltrials-mcp"]
    }
  }
}

uvx runs the package without requiring it on your $PATH. If you don't have uv: pip install uv.

Restart your MCP client. The 5 tools appear automatically.

Running from source (contributors / developers)

git clone https://github.com/agents100x/clinicaltrials-mcp
cd clinicaltrials-mcp
uv sync

{
  "mcpServers": {
    "clinicaltrials": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/path/to/clinicaltrials-mcp",
        "clinicaltrials-mcp"
      ]
    }
  }
}

Where is the config file?

Client	Config file location
Claude Desktop (macOS)	`~/Library/Application Support/Claude/claude_desktop_config.json`
Claude Desktop (Windows)	`%APPDATA%\Claude\claude_desktop_config.json`
Cursor	`.cursor/mcp.json` or Settings → MCP
VS Code / forks	Settings → MCP Servers → Edit config

Restart the client after saving. The 5 tools appear automatically.

Sample Queries

Organised by real analyst workflows. All queries work in plain English — no syntax required.

Competitive Intelligence

"Show me recruiting Phase III trials for breast cancer"
"Find all active Phase II Alzheimer's trials in Europe"
"What NASH trials completed in the last 2 years?"
"Are there any recruiting trials for KRAS-mutant lung cancer?"
"Show me TERMINATED trials for diabetes — I want to know what failed"

The last query uses the status override: "...status='TERMINATED'" — WITHDRAWN and TERMINATED trials are excluded by default, but you can always ask for them explicitly.

Patient Eligibility & Site Feasibility (CRO Teams)

"Get the full eligibility criteria for NCT04280341"
"Find recruiting HER2-positive breast cancer trials near Mumbai, India"
"Find Type 2 Diabetes trials recruiting near Bangalore, India"
"Are there any recruiting immunotherapy trials near London?"

Note on site status: Results are filtered by overall trial status. Always verify the specific site's recruitment status at clinicaltrials.gov before contacting a site.

Protocol Comparison (Medical Writers / Researchers)

"Compare NCT04280341 and NCT02142803 on eligibility criteria"
"Compare the design and timeline of NCT04280341 and NCT03817944"
"Compare the endpoints of these three pembrolizumab trials: NCT04280341, NCT03817944, NCT02142803"

Focus the comparison with compare_on:

"...compare on design" — phase, randomisation, blinding, arms
"...compare on eligibility" — inclusion/exclusion criteria side by side
"...compare on endpoints" — primary and secondary outcomes
"...compare on timeline" — start dates, completion dates, enrollment targets
"...compare on locations" — countries and site counts

Results & Safety Review

"What were the adverse events reported in NCT02142803?"
"Show me all Grade 1 and above adverse events for NCT02142803"
"Give me a quick summary of the primary outcome of NCT02142803"
"What were the participant flow and dropout reasons in NCT02142803?"

Results options:

Default shows serious adverse events only (Grade 3+)
"...include all grades" → adds Grade 1/2 events
"...summary only" → returns just the primary outcome in 2–3 lines, useful for scanning many trials

Edge Cases the Tool Handles Cleanly

"Get results for NCT03444521"
→ Returns: "Trial completed in 2022 but no results posted — this is common,
   ~60% of completed trials never post results. It does not mean the trial failed."

"Find recruiting trials for Niemann-Pick disease near Paris"
→ Returns: helpful no-results message with suggestions to broaden the search

"Find terminated trials for a condition"
→ Requires explicit status override — the tool tells you exactly how

The 5 Tools

Tool	What It Does	Key Design Decision
`search_trials`	Search by condition, phase, status, location	WITHDRAWN + TERMINATED excluded by default — always explained, always overridable
`get_trial_details`	Full structured summary by NCT ID	Eligibility always verbatim — never paraphrased
`compare_trials`	Side-by-side comparison of 2–5 trials	`compare_on` param: all, design, eligibility, endpoints, timeline, locations
`get_trial_results`	Outcomes, AEs, participant flow	AE grade note top + bottom; 4-case no-results handling
`find_recruiting_near`	Recruiting trials near a location	City → country location rings, honest about CT.gov's city-level data

Why This Is Different

Every other ClinicalTrials.gov MCP passes raw JSON from the API to the LLM and calls it done.

This is a workflow tool, not an API wrapper:

Outputs designed around what analysts do — not what the API can return
Opinionated defaults — RECRUITING sorts first, Grade 3+ AEs shown, status filter always explained
Honest about data gaps — ~60% of completed trials never post results; we say so every time
Verbatim eligibility criteria — never paraphrased, too risky to interpret clinical text
Verification by design — NCT hyperlinks appear at the top and bottom of every trial detail

Limitations

Data is self-reported by sponsors on ClinicalTrials.gov — not independently verified by us
~60% of completed trials have no posted results on CT.gov
Trial status and site data may lag real-world updates by weeks
Location filtering is city/country level — no GPS radius search available
Not all trials in the world are registered on CT.gov

Data returned by this tool should never be used directly in regulatory submissions, publications, or clinical decisions without independent verification at clinicaltrials.gov.

Full scope and data disclaimer: DISCLAIMER.md

How It Works

Claude or Cursor
      |
      | MCP tool call over stdio
      |
  server.py      — registers 5 tools, routes calls, catches all errors gracefully
      |
  client.py      — async httpx client for CT.gov API v2 (public, no auth required)
      |
  ClinicalTrials.gov  — public REST API, 400,000+ registered trials
      |
  formatters.py  — transforms raw JSON into clean, structured markdown
      |
Claude or Cursor — reads formatted output and responds to the user

Stack: Python 3.12+ · MCP Python SDK · httpx · uv

Contributing

git clone https://github.com/agents100x/clinicaltrials-mcp
cd clinicaltrials-mcp
uv sync
uv run pytest tests/ -m "not integration"   # offline unit tests, ~0.3s
uv run pytest tests/                         # full suite including live API

Bug reports and pull requests welcome at github.com/agents100x/clinicaltrials-mcp/issues.

License

MIT — see LICENSE for details.

Built by agents100x.

Available Tools

5 tools

compare_trialsA

Compare 2 to 5 clinical trials side by side. Produces structured tables for design, timeline, locations, endpoints, and eligibility criteria. Use compare_on to focus on one category.

ParametersJSON Schema

Name	Required	Description	Default
`nct_ids`	Yes	List of 2 to 5 NCT identifiers to compare.
`compare_on`	No	What to compare. Options: 'all' (default), 'design', 'timeline', 'locations', 'endpoints', 'eligibility'.	all

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the output (structured tables) but does not disclose behavioral traits like idempotency, rate limits, or auth requirements. The description is adequate but lacks depth for a complete behavioral picture.

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

Conciseness5/5

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

Two sentences, front-loaded with purpose, no fluff. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately describes output as structured tables with listed categories. However, it misses behavioral context like whether it is read-only or if results are cached. Almost complete for a comparison tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds minimal value beyond schema, only reiterating the purpose of 'compare_on'. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool compares 2 to 5 clinical trials side by side, producing structured tables for specified categories. It distinguishes from sibling tools like 'get_trial_details' (single trial) and 'search_trials' (search) by focusing on comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on using the 'compare_on' parameter to focus on a category, but does not explicitly state when to use this tool over siblings (e.g., when comparing multiple trials vs. getting details of one). This leaves some ambiguity.

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

find_recruiting_nearA

Find actively recruiting trials for a condition near a location. Results are grouped by location ring: trials in the queried city first, then elsewhere in the country. Location is city/country level — CT.gov has no GPS radius data. IMPORTANT: filtered by overall trial status, not individual site status. A site in your city may still show 'Not yet recruiting' even if the trial is recruiting globally. Always verify the specific site status at clinicaltrials.gov.

ParametersJSON Schema

Name	Required	Description
`condition`	Yes	Disease or condition, e.g. 'Type 2 diabetes'.
`location`	Yes	City and/or country, e.g. 'Bangalore, India' or 'Germany'.
`phase`	No	Optional phase filter: 'PHASE1', 'PHASE2', 'PHASE3', 'PHASE4'.
`max_results`	No	Maximum results per ring. Default 10, maximum 50.

TDQS

A4.1/5.0

Behavior5/5

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

No annotations provided, so the description carries full burden. It clearly discloses key behavioral traits: grouping by location rings, city/country-level limitation, and the critical distinction between trial-level and site-level recruitment status. This adds significant context beyond the input schema.

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

Conciseness5/5

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

Extremely concise: two clear sentences plus a necessary caution. Front-loaded with the main purpose, then key behavioral details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and four parameters, the description covers the tool's behavior well, including limitations and a critical caveat. Could mention pagination or error handling, but for a straightforward search tool this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add significant per-parameter semantics beyond what the schema already provides (e.g., condition, location, phase, max_results). The note about location granularity is helpful but not new parameter-level detail.

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

Purpose4/5

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

Clearly states the tool finds actively recruiting trials for a condition near a location, including grouping by location rings. However, it does not explicitly distinguish from sibling tools like search_trials or get_trial_results, which could be used for broader or different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides important usage guidance: location is city/country level, no GPS radius, and warns about overall trial status vs site status. Does not explicitly state when not to use or list alternatives, but the caveat is valuable for correct usage.

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

get_trial_detailsA

Get a full structured summary of one clinical trial by NCT ID. Returns: overview, what's being studied, verbatim eligibility criteria, site locations, and whether results have been posted. NCT ID hyperlink appears at the top and bottom for easy verification.

ParametersJSON Schema

Name	Required	Description	Default
`nct_id`	Yes	The NCT identifier, e.g. 'NCT02142803'. Case-insensitive.

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It transparently lists the types of data returned (overview, eligibility, sites, results) and the hyperlink feature. It does not mention error handling, rate limits, or whether it requires authentication, but for a read-only retrieval tool, the level of detail is good.

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

Conciseness5/5

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

The description is two sentences: the first states the core purpose, the second lists what's included. No redundant phrases, every word adds value. It is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and low complexity, the description covers the main return data points adequately. It could mention data source or behavior on missing NCT ID, but for a single-parameter retrieval tool, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single parameter (nct_id with example and case-insensitivity). The description does not add additional semantics beyond restating that it's by NCT ID. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool retrieves a full structured summary of one clinical trial by NCT ID. It lists the specific components returned (overview, eligibility criteria, site locations, results), which distinguishes it from siblings like search_trials (multiple trials) or compare_trials (comparison). The mention of an NCT ID hyperlink adds value.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: use when you have an NCT ID and want a detailed summary. However, the description does not explicitly state when to use this over siblings (e.g., search_trials for broad search, get_trial_results for results only). No exclusions or alternatives are mentioned.

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

get_trial_resultsA

Fetch posted results for a clinical trial: participant flow, baseline characteristics, primary and secondary outcomes, and adverse events. Handles 4 cases: results posted, trial ongoing, completed but no results posted, and NCT ID not found. Adverse events default to serious events (Grade 3+) only.

ParametersJSON Schema

Name	Required	Description	Default
`nct_id`	Yes	The NCT identifier, e.g. 'NCT02142803'.
`summary_only`	No	If true, return only the primary outcome in 2–3 lines. Default false.
`ae_grade`	No	Adverse event filter. '3+' (default): serious events only. 'all': serious + Grade 1/2 events. 'serious': SAEs only.	3+

TDQS

A4.1/5.0

Behavior4/5

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

The description discloses the tool's behavior for four distinct cases and the default adverse event filtering, which adds value beyond the schema. However, it lacks details on error handling or other behavioral traits, though no annotations exist to carry that burden.

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

Conciseness5/5

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

The description is concise, with two sentences that front-load the main purpose and efficiently cover key details like the four cases and default AE grade.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description adequately explains what the tool returns (components of results and cases), making it complete for an agent to understand the tool's function.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds minimal extra meaning beyond the schema. It restates the default for ae_grade but does not significantly enhance understanding of parameter semantics.

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

Purpose5/5

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

The description clearly states the tool fetches posted results for a clinical trial, listing specific components like participant flow, baseline characteristics, and outcomes, distinguishing it from siblings like get_trial_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indirectly implies usage by listing the four cases it handles, but it does not explicitly state when to use this tool versus alternatives like get_trial_details or compare_trials.

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

search_trialsA

Search ClinicalTrials.gov for trials matching a condition. Returns a ranked list with status, phase, sponsor, site count, and a brief summary. WITHDRAWN and TERMINATED trials are excluded by default — pass status= to override. Results are ordered with RECRUITING trials first.

ParametersJSON Schema

Name	Required	Description
`condition`	Yes	Disease or condition to search for, e.g. 'breast cancer', 'Type 2 diabetes'.
`location`	No	Optional. City, state, or country to filter by, e.g. 'India', 'Boston', 'Germany'.
`phase`	No	Optional. Trial phase: 'PHASE1', 'PHASE2', 'PHASE3', 'PHASE4'. Omit for all phases.
`status`	No	Optional. Override the default status filter. Pass a single CT.gov status value e.g. 'RECRUITING', 'COMPLETED', 'TERMINATED'. Default excludes WITHDRAWN and TERMINATED.
`max_results`	No	Number of results to return. Default 10, maximum 50.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that withdrawn/terminated trials are excluded by default and that results are ordered with recruiting first. However, it does not mention rate limits, authentication, or whether the search is paginated, which are relevant for a network search tool.

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

Conciseness5/5

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

Three sentences, no fluff. Front-loaded with purpose, then key details. Every sentence contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description includes what fields are returned (status, phase, sponsor, site count, brief summary). It covers default filtering and ordering. It lacks mention of error handling or empty results, but is otherwise complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context for the 'status' parameter (default exclusion behavior) and mentions result ordering, but does not significantly enhance the meaning of other parameters beyond what the schema already provides.

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

Purpose4/5

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

The description clearly identifies the verb 'Search' and resource 'ClinicalTrials.gov for trials matching a condition', and lists fields returned. It implicitly distinguishes from siblings like 'find_recruiting_near' by mentioning ordering with RECRUITING first, but does not explicitly contrast with other siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states default behavior (exclusion of WITHDRAWN/TERMINATED) and how to override with status, but does not explicitly state when to use this tool versus alternatives like 'compare_trials' or 'find_recruiting_near', nor does it mention prerequisites or context.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: searching, getting details, getting results, comparing, and finding recruiting trials by location. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., search_trials, get_trial_details) using underscores, making them predictable and easy to understand.

Tool Count5/5

5 tools cover the essential operations for clinical trials access without being excessive or insufficient, making the server well-scoped.

Completeness4/5

The set covers searching, details, results, comparison, and location-based filtering. Minor gaps like advanced filters or site-specific status do not hinder primary workflows.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MedPrice AI A
io.github.medprice-ai
Hosted MCP server exposing US hospital procedure cost data to AI assistants
Biology & Medicine Finance
52
Quallaa
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
Airbyte Agents
io.github.airbytehq
Let AI agents query data and act across all your business apps via MCP.
Data Platforms AI & Machine Learning RAG Systems
2
pixserp A
com.pixserp
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Search Browser Automation
12

Related MCP Servers

Mutation Clinical Trial
Health & Wellness RAG Systems Search
pickleton89
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables Claude Desktop to search clinicaltrials.gov for matching clinical trials based on genetic mutations provided in natural language queries.
Updated a year ago (2025-07-21 16:03 UTC)
1
MIT
clinicaltrialsgov-mcp-server
Bioinformatics Biology & Medicine Research & Data
cyanheads
A
license
A
quality
B
maintenance
Empowers AI agents with direct access to the official ClinicalTrials.gov database, enabling programmatic searching, retrieval, and analysis of clinical study data through a Model Context Protocol interface.
Updated 12 days ago (2026-08-21 22:39 UTC)
7
2,715
91
Apache 2.0
ClinicalTrials.gov MCP Server
Biology & Medicine Research & Data Open Data
aafjes
F
license
Not graded
quality
D
maintenance
Enables searching and retrieving information from the ClinicalTrials.gov database of over 400,000 clinical studies, including trial details, eligibility criteria, locations, and results across 220+ countries.
Updated 9 months ago (2025-12-04 04:00 UTC)
5
Clinical Trials MCP Server
Biology & Medicine Search Research & Data
PancrePal-xiaoyibao
A
license
B
quality
D
maintenance
Enables searching and querying clinical trials from ClinicalTrials.gov with intelligent filtering for recruiting studies, geographic search, and detailed trial information including contacts and eligibility criteria.
Updated 8 months ago (2026-01-02 11:16 UTC)
3
10
6
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/agents100x/clinicaltrials-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server