Skip to main content
Glama
jlucasmcrell

Apify Public Data & Leads

ClinicalTrials.gov Study Search

clinical_trials_search
Read-only

Search ClinicalTrials.gov for studies by condition, intervention, sponsor, or keyword. Returns recruitment status, phase, enrollment, sponsor, and site location.

Instructions

Search the official ClinicalTrials.gov registry for interventional and observational studies by condition, intervention, sponsor, or free-text keyword. Returns recruitment status, phase, enrollment, sponsor, and site location detail for each matching study.

Behavioral Transparency:

  • Execution: Network call executed synchronously in the cloud via Apify Actor 'captainhandsome/clinical-trials-search'.

  • Side Effects: Reads public sources and creates a billed Actor run and dataset on your Apify account.

  • Authentication: Requires APIFY_TOKEN environment variable.

  • Latency & Limits: Typical run duration is 10-30 seconds; timeout capped at 120 seconds.

Usage Guidelines:

  • When to use: Use for medical research surveillance, competitive drug-pipeline tracking, patient-recruitment intelligence, or sponsor and trial-portfolio analysis.

  • When NOT to use: Do not use for FDA drug/device approvals or adverse-event data, environmental compliance records, campaign finance, or corporate registry lookups.

  • Named alternatives: Use 'openfda_search' for FDA drug and device safety/approval data, 'epa_facility_search' for environmental compliance, 'fec_campaign_finance_search' for political campaign funding, or 'french_company_search' for the French corporate registry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoOptional overall recruitment status filter. Omit to return studies in any status.
conditionYesKeywords, condition, intervention, sponsor name, or other free-text search expression accepted by ClinicalTrials.gov (e.g. 'Alzheimer disease', 'semaglutide', 'Mayo Clinic').
max_resultsNoMaximum number of study records to retrieve. Defaults to 10.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
runNo
errorNo
statusYes
resultsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed29 schema fields changedv1.1.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedOutput schema / properties / error
      Added value: +{
      +  "type": "object"
      +}
    • removedOutput schema / properties / results / description
      Removed value: -"Collection of ClinicalTrials.gov study records matching the search."
    • changedOutput schema / properties / results / items / properties / conditions / description
      Previous value: -"Comma-separated medical conditions the study addresses."New value: +"Diseases or conditions studied, as written by the sponsor, comma separated."
    • addedOutput schema / properties / results / items / properties / conditions / title
      Added value: +"Conditions"
    • changedOutput schema / properties / results / items / properties / conditions / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / results / items / properties / enrollment / description
      Previous value: -"Actual or estimated participant enrollment count."New value: +"Number of participants enrolled or targeted."
    • addedOutput schema / properties / results / items / properties / enrollment / title
      Added value: +"Enrollment"
    • changedOutput schema / properties / results / items / properties / enrollment / type
      Previous value: -"integer"New value: +[
      +  "integer",
      +  "null"
      +]
    • changedOutput schema / properties / results / items / properties / nct_id / description
      Previous value: -"Unique ClinicalTrials.gov study identifier."New value: +"Unique ClinicalTrials.gov study identifier, the primary key for this record."
    • addedOutput schema / properties / results / items / properties / nct_id / title
      Added value: +"NCT ID"
    • changedOutput schema / properties / results / items / properties / nct_id / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / results / items / properties / phase / description
      Previous value: -"Trial phase, e.g. PHASE1, PHASE2, PHASE3."New value: +"Trial phase or phases, for example PHASE2 or PHASE2, PHASE3. NA means a trial without FDA-defined phases."
    • addedOutput schema / properties / results / items / properties / phase / title
      Added value: +"Phase"
    • changedOutput schema / properties / results / items / properties / phase / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / results / items / properties / sponsor / description
      Previous value: -"Lead sponsor organization name."New value: +"Organization responsible for the overall conduct of the study."
    • addedOutput schema / properties / results / items / properties / sponsor / title
      Added value: +"Lead Sponsor"
    • changedOutput schema / properties / results / items / properties / sponsor / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / results / items / properties / status / description
      Previous value: -"Current overall recruitment status, e.g. RECRUITING or COMPLETED."New value: +"Current recruitment status of the study, for example RECRUITING or COMPLETED."
    • addedOutput schema / properties / results / items / properties / status / title
      Added value: +"Overall Status"
    • changedOutput schema / properties / results / items / properties / status / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • addedOutput schema / properties / results / items / properties / title / title
      Added value: +"Title"
    • changedOutput schema / properties / results / items / properties / title / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • addedOutput schema / properties / results / items / properties / url / title
      Added value: +"Source record URL"
    • changedOutput schema / properties / results / items / properties / url / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / results / items / required
      Removed value: -[
      -  "nct_id",
      -  "title"
      -]
    • addedOutput schema / properties / run
      Added value: +{
      +  "type": "object"
      +}
    • addedOutput schema / properties / status
      Added value: +{
      +  "enum": [
      +    "success",
      +    "empty_unverified",
      +    "partial",
      +    "error"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "results"
      -]New value: +[
      +  "results",
      +  "status"
      +]
  2. Addedv1.0.11

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond annotations by disclosing that execution is a synchronous network call via a specific Apify Actor, that it creates a billed Actor run and dataset on the user's Apify account, that APIFY_TOKEN is required, and that typical latency is 10-30 seconds with a 120-second timeout. This is rich, actionable behavioral context that annotations alone do not provide.

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 well-organized into purpose, behavioral transparency, and usage guidelines sections. It front-loads the core function, then adds necessary operational detail without fluff. Every sentence earns its place, and the length is justified by the cloud-execution and side-effect disclosures.

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?

The description covers execution model, side effects, authentication, latency caps, use cases, exclusions, and alternative tools. An output schema exists, so return-value structure need not be spelled out. For a tool with network execution and billing side effects, 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.

Parameters3/5

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

Schema description coverage is 100%, so the input schema fully documents all three parameters with types, defaults, ranges, and examples. The description's mention of searchable dimensions broadly echoes the 'condition' parameter without adding meaning beyond the schema. Baseline 3 is appropriate given the schema already carries the 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 states a specific verb ('Search'), a specific resource ('official ClinicalTrials.gov registry'), and the scope of searchable entities (condition, intervention, sponsor, free-text keyword). It also lists the return fields, making the tool's purpose unmistakable and differentiating it from generic search tools.

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

Usage Guidelines5/5

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

The description provides explicit 'When to use' and 'When NOT to use' guidance, and names concrete sibling alternatives for adjacent domains such as openfda_search, epa_facility_search, and fec_campaign_finance_search. This gives an agent clear routing logic based on the user's intent.

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