Skip to main content
Glama
cliwant

mcp-sam-gov

clinicaltrials_search_studies

Read-only

Search federally-registered clinical-research studies by sponsor, condition, location, status, or funder type, then retrieve trial IDs and titles for detailed review.

Instructions

Search federally-registered clinical-research studies with LEAD-SPONSOR / COLLABORATOR / FUNDING-SOURCE enrichment (keyless; clinicaltrials.gov/api/v2/studies). Filters: query.term (broad free-text), sponsor (→query.spons, fuzzy NAME search), condition (→query.cond), location (→query.locn), overallStatus (frozen 14-value enum), funderType (frozen 4-value enum nih/fed/industry/other), pageSize (1..1000), pageToken (OPAQUE cursor). Returns { studies:[{ nctId, briefTitle, orgStudyId, organization:{name,class}, leadSponsor:{name,class}, collaborators:[{name,class}], fundingClass, overallStatus, startDate, studyType, phases, conditions }] } (briefSummary EXCLUDED — use clinicaltrials_get_study) + honest _meta. HONESTY: countTotal=true ALWAYS sent → totalAvailable = EXACT uncapped total (NEVER studies.length; missing/non-number totalCount → schema_drift). Pagination is OPAQUE cursor (nextCursor = nextPageToken back as pageToken; terminal = token absent; bad token → HTTP 400 THROWS). funderType re-validated in handler — UNLISTED value silently returns totalCount:0 at HTTP 200 (fake-empty trap) → invalid_input pre-fetch. funderType is an OVERLAPPING facet (counts MUST NOT be summed). MULTI-WORD query.term/sponsor/condition is AND-conjunctive (all tokens must co-occur — disclosed). Registered trial is NOT a federal award; leadSponsor.name is FREE TEXT (not a UEI) → NOMINAL name match only — disclosed every response. Genuine totalCount:0 → complete:true/total:0; bad overallStatus/pageToken → HTTP 400/404 THROWS; outage/5xx THROWS. Feed nctId to clinicaltrials_get_study.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sponsorNoLead-sponsor / collaborator NAME search (→ query.spons; a fuzzy full-text name search, NOT an exact-entity join — the name is free text, not a UEI). MULTI-WORD is AND-conjunctive. LIVE-CONFIRMED to narrow. e.g. 'Pfizer'.
locationNoStudy-location filter (→ query.locn), e.g. a country or city. LIVE-CONFIRMED to narrow. e.g. 'Germany'.
pageSizeNoStudies per page, 1..1000, default 20 (ClinicalTrials.gov clamps a larger request to 1000).
conditionNoCondition / disease filter (→ query.cond). MULTI-WORD is AND-conjunctive. LIVE-CONFIRMED to narrow. e.g. 'diabetes'.
pageTokenNoOpaque continuation cursor — pass back the _meta.nextCursor from the previous page. Pagination is a cursor, NOT a numeric offset (offset/nextOffset are null); nextCursor:null means the last page. A bad token loud-fails at HTTP 400.
funderTypeNoFunding-source facet (→ aggFilters=funderType:<v>) — the FEDERAL-funding axis. A frozen 4-value enum: nih, fed, industry, other (the B2G-relevant nih/fed narrow to federally-sponsored trials). An UNLISTED value silently returns totalCount:0 at HTTP 200 (a fake-empty trap), so it is rejected pre-fetch (invalid_input). funderType is an OVERLAPPING facet — counts MUST NOT be summed into a total.
query.termNoBroad free-text search across the study record. MULTI-WORD is AND-conjunctive — ALL tokens must co-occur ('breast cancer' = breast AND cancer; disclosed in _meta.notes). LIVE-CONFIRMED to narrow. e.g. 'cancer'.
overallStatusNoRecruitment/overall status (→ filter.overallStatus). A frozen 14-value enum (COMPLETED, RECRUITING, TERMINATED, …); an unlisted value LOUD-fails at HTTP 400 upstream, so it is rejected pre-fetch. LIVE-CONFIRMED to narrow. e.g. 'RECRUITING'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already indicate readOnlyHint and openWorldHint, and the description adds rich behavioral context: honest countTotal, opaque cursor pagination, loud-failure on bad tokens, fake-empty trap for unlisted funderType, AND-conjunctive multi-word tokens, nominal name matching, and error/outage behavior. This far exceeds what annotations convey.

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

Conciseness4/5

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

The description is long but densely packed with essential behavioral details, and it is front-loaded with the core purpose. It is structured logically (filters, returns, honesty, pagination, facet caveats, errors, routing). While not concise in length, every sentence adds value, though a bit of redundancy exists (e.g., 'LIVE-CONFIRMED to narrow' repeated), so it earns a 4.

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?

Despite having no output schema, the description fully specifies the return structure, pagination, error modes, facet semantics, and handoff to clinicaltrials_get_study. Combined with the annotations, an agent has everything needed to call this tool correctly and interpret results, including edge cases like fake-empty and overlapping facets.

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

Parameters4/5

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

Schema coverage is 100% with each parameter well-documented, so the baseline is 3. The description adds extra value by clarifying live-confirmed narrowing, funderType overlapping facet semantics and its pre-fetch rejection, and the opaque cursor behavior, which go beyond the schema. However, much of the parameter meaning is already in the schema, so a 4 reflects the added nuance without over-scoring.

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 searches federally-registered clinical-research studies with sponsor/collaborator/funding enrichment. It explicitly distinguishes itself from the sibling clinicaltrials_get_study by noting the briefSummary is excluded and to use that tool instead, making purpose and differentiation clear.

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?

Provides explicit guidance on when to use the tool: for search with various filters, and when to hand off to clinicaltrials_get_study for full study details. It also explains pagination and error behavior, leaving no ambiguity about usage versus alternatives.

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

Deploy Server

Other Tools