Artificial Intelligence

Rebuilding ClinicalTrials.gov with AI: A Natural Language Interface Powered by LLMs

By Posted byTanya

ClinicalTrials.gov contains one of the most important public biomedical datasets in the world.

And yet… using it well still requires:

  • Knowing the API
  • Understanding filter syntax
  • Manually constructing advanced queries
  • Interpreting dense protocol output

I wanted to change that.

So I built RareTrials MCP Explorer — a system that lets you query ClinicalTrials.gov using plain English.

Not a chatbot glued onto search.
Not keyword matching.
But a structured, tool-aware natural language interface.

The Core Idea

The goal was simple: Take a free-form question and turn it into a precise, valid, structured ClinicalTrials.gov query — automatically.

There’s a huge difference between:

  • “Use AI to summarize results”
  • and
  • “Use AI to select the correct backend tool, generate correct parameters, and execute the right workflow.”

This project focuses on the second.

Step 1: Don’t Scrape — Use MCP

Instead of directly calling the API everywhere in the app, I used the open-source clinicaltrialsgov-mcp-server.

This MCP (Model Context Protocol) server wraps ClinicalTrials.gov and exposes structured tools like:

  • clinicaltrials_search_studies
  • clinicaltrials_analyze_trends
  • clinicaltrials_compare_studies
  • clinicaltrials_find_eligible_studies

That separation matters.

  • The UI doesn’t need to know API internals
  • Tool contracts are explicit
  • Logic stays modular
  • The model doesn’t hallucinate endpoints

The MCP layer acts as a controlled bridge between natural language and real data.

Step 2: Make the Model Choose the Tool

Most AI integrations stop at: “Extract keywords.” That’s not enough.

I designed a structured prompt that forces the model to:

  • Select the correct tool
  • Extract only valid parameters
  • Conform to strict JSON rules
  • Never include disallowed fields
  • Pick exactly one analysis type
  • Default required eligibility fields properly

For example, if someone asks:

“Which countries have the most Alzheimer’s trials?”

The model must output:

{
  "tool": "clinicaltrials_analyze_trends",
  "query": "Alzheimer's",
  "analysisType": "countByCountry"
}

Not a paragraph. Not multiple analysis types. Not a malformed filter. This transforms the LLM from “chat assistant” into a routing and parameter engine.

Step 3: Guardrails Everywhere

ClinicalTrials.gov can return massive result sets. So I added:

  • Hard limits for aggregation (>5,000 results triggers narrowing guidance)
  • Query rephrase detection if no valid condition is extracted
  • Filter validation syntax checks
  • Required field enforcement for eligibility searches
  • Age eligibility post-filtering logic
  • Structured error surfacing from the MCP server

The goal was reliability — not demo-ware.

Step 4: Handle MCP Properly (Including Streaming)

The MCP server supports both JSON and Server-Sent Events (SSE).

Some HTTP clients fail when handling duplicate transfer headers. So I built a minimal JSON-RPC client that:

  • Handles streaming responses
  • Parses SSE correctly
  • Maintains session IDs
  • Surfaces structured errors cleanly
  • Resets safely when needed

This ensures production stability instead of “works sometimes.”

Step 5: Design for Clarity

Raw API output is overwhelming. So I built structured result renderers:

🔍 Search View

  • Status indicators
  • Phase chips
  • Location previews
  • Eligibility age checks
  • Expandable summaries

📊 Analysis View

  • Phase distribution
  • Status breakdown
  • Geographic spread
  • Sponsor type analysis
  • Share percentages

⚖️ Comparison View

  • Side-by-side structured attributes
  • Masking
  • Study type
  • Sponsor
  • Sites

🎯 Eligibility View

  • Match scoring
  • Reasons for match
  • Criteria snippet preview

Why This Matters

ClinicalTrials.gov is public.  But public does not mean accessible. Researchers, biotech teams, and patient advocates still manually export data, aggregate in spreadsheets, and write custom scripts to answer simple questions. Natural language + structured tools changes that. It turns a massive database into an analytical interface.

The Bigger Pattern

This project demonstrates a broader architecture:

LLM → strict tool selection → structured backend → guarded execution → curated rendering

That pattern can apply to regulatory intelligence, competitive analysis, public datasets, financial data, and more. The breakthrough isn’t “AI answers questions.” It’s AI reliably selecting the correct system behavior.

Final Thought

Clinical trial intelligence shouldn’t require API fluency. If natural language can become a safe, structured interface to biomedical data, the barrier to insight drops dramatically. If you’re building with structured data, MCP, or healthcare analytics, I’d love to connect. Imagine this across FDA data, PubMed, SEC filings, payer policies, or real-world evidence datasets. If you’re sitting on structured data that deserves a better interface, let’s build it.

Posted byTanya •