Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Unofficial Clinical Trials MCP Server search for phase 3 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.
A comprehensive Model Context Protocol (MCP) server that provides access to the ClinicalTrials.gov API, enabling researchers, clinicians, and developers to access real-time clinical trial data programmatically.
Developed by Augmented Nature
The Clinical Trials MCP server exposes the full ClinicalTrials.gov API v2.0.4 functionality through 18 specialized MCP tools, allowing you to search, analyze, and retrieve detailed information about clinical trials worldwide directly from your MCP-enabled environment.
Related MCP server: aria-mcp-server
search_studies - General search with comprehensive filters (condition, intervention, location, phase, status, age, sex)
get_study_details - Detailed study information by NCT ID with complete metadata
search_by_condition - Condition-focused search with eligibility criteria
search_by_location - Geographic-based search with distance radius filtering
search_by_sponsor - Organization and sponsor-based search with sponsor type filtering
search_by_intervention - Treatment, drug, and intervention-focused search
get_recruiting_studies - Currently recruiting trials with active contact information
search_by_date_range - Temporal search by study start and completion dates
get_studies_with_results - Completed trials with published results
search_rare_diseases - Specialized search for rare diseases and orphan conditions
get_pediatric_studies - Pediatric-specific trials for children and adolescents
search_international_studies - Multi-country international trials
get_similar_studies - Find studies similar to a reference NCT ID by condition, sponsor, or phase
search_by_primary_outcome - Search by primary outcome measures and endpoints
search_by_eligibility_criteria - Advanced eligibility filtering with inclusion/exclusion keywords
get_study_timeline - Timeline analysis with current, completed, and upcoming studies
get_trial_statistics - Aggregate statistics and analytics with grouping capabilities
Real-time data access (updated daily Monday-Friday)
NCT ID validation with regex patterns
Comprehensive JSON Schema validation
Geographic coordinate data for study locations
Contact information for recruiting studies
Robust error handling and timeout protection
Node.js 16+ (install from nodejs.org)
No API key required (ClinicalTrials.gov API is publicly accessible)
Navigate to your MCP directory:
cd ~/Documents/Claude/MCP # or your preferred MCP directoryThe server is already built and configured:
ls clinical-trials-server/
# Should show: build/ src/ package.json tsconfig.json README.mdVerify build:
cd clinical-trials-server
ls build/
# Should show: index.js (executable)Add this to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"clinical-trials": {
"command": "node",
"args": ["path/to/clinical-trials-server/build/index.js"],
"autoApprove": [
"search_studies",
"get_study_details",
"search_by_condition",
"search_by_location",
"get_recruiting_studies",
"search_by_sponsor",
"search_by_intervention",
"get_trial_statistics"
]
}
}
}Note: Replace path/to/clinical-trials-server with the absolute path to your server directory.
{
"condition": "cancer",
"phase": "PHASE3",
"status": "RECRUITING",
"pageSize": 10
}{
"nctId": "NCT05882279"
}{
"country": "United States",
"city": "Boston",
"distance": 50,
"pageSize": 5
}{
"condition": "diabetes",
"ageRange": "CHILD",
"recruitmentStatus": "RECRUITING"
}{
"condition": "alzheimer",
"location": "California",
"pageSize": 5
}{
"nctId": "NCT12345678",
"similarityType": "CONDITION",
"pageSize": 10
}{
"minAge": "18 Years",
"maxAge": "65 Years",
"sex": "ALL",
"healthyVolunteers": false,
"condition": "hypertension",
"inclusionKeywords": "medication",
"exclusionKeywords": "pregnant"
}{
"groupBy": "phase",
"filters": {
"condition": "diabetes",
"status": "RECRUITING"
}
}Common Parameters:
pageSize - Number of results (1-100, default: 10)
condition - Medical condition or disease
phase - Study phase: PHASE1, PHASE2, PHASE3, PHASE4, NA
status - Recruitment status: RECRUITING, NOT_YET_RECRUITING, COMPLETED, etc.
Location Parameters:
country - Country name
state - State or province
city - City name
distance - Search radius in miles (1-500)
Eligibility Parameters:
sex - ALL, FEMALE, MALE
age - CHILD, ADULT, OLDER_ADULT
minAge/maxAge - Age ranges (e.g., "18 Years", "65 Years")
healthyVolunteers - Boolean for healthy volunteer acceptance
Date Parameters:
startDateFrom/startDateTo - Study start date range (YYYY-MM-DD)
completionDateFrom/completionDateTo - Completion date range (YYYY-MM-DD)
All tools return structured JSON data including:
Study metadata (NCT ID, title, status, phase, sponsor)
Location information with geographic coordinates
Eligibility criteria and contact information
Timeline data and key dates
Comprehensive search criteria documentation
All NCT IDs must follow the pattern: NCT######## (NCT followed by 8 digits)
The server includes comprehensive error handling for:
Network Issues: 30-second timeout protection with retry logic
Invalid Parameters: JSON Schema validation with descriptive error messages
API Errors: Proper HTTP status code handling and error reporting
Missing Data: Graceful handling of optional fields and missing information
Rate Limiting: Built-in request throttling and error recovery
Common error responses include:
{
"error": "Clinical Trials API error: Invalid NCT ID format",
"isError": true
}# Install dependencies
npm install
# Build TypeScript to JavaScript
npm run build
# Development with watch mode
npm run watchclinical-trials-server/
├── src/
│ └── index.ts # Main server implementation (all tools)
├── build/
│ └── index.js # Compiled executable
├── package.json # Dependencies and scripts
├── tsconfig.json # TypeScript configuration
└── README.md # This file@modelcontextprotocol/sdk - MCP server framework
axios - HTTP client for API requests
TypeScript for type safety and development
API Endpoint: https://clinicaltrials.gov/api/v2 Data Updates: Monday through Friday (excluding federal holidays) Coverage: 400,000+ studies from 220+ countries Data Quality: Official FDA/NIH registry with verified information
Server Connection Issues:
# Test server manually
cd clinical-trials-server
node build/index.js
# Should show: "Clinical Trials MCP server running on stdio"Invalid NCT ID Errors:
Ensure NCT IDs follow format: NCT########
Example: NCT05882279 ✓, nct123 ✗
No Results Returned:
Check search criteria - try broader terms
Some filters may be too restrictive
Verify spelling of conditions and interventions
Timeout Issues:
Server has 30-second timeout protection
Large result sets may take time to process
Reduce pageSize for faster responses
Patient Recruitment: Find actively recruiting trials for specific conditions
Competitive Analysis: Research similar studies by sponsors or interventions
Site Selection: Identify optimal locations for new studies
Regulatory Research: Access FDA-approved study protocols and outcomes
Academic Research: Analyze clinical trial trends and statistics
Patient Care: Help patients find appropriate treatment options
This server provides access to publicly available clinical trial data from ClinicalTrials.gov. Users should:
Follow institutional policies for clinical research
Respect patient privacy and confidentiality
Use data for legitimate research and healthcare purposes
Cite ClinicalTrials.gov as the data source in publications
MIT License - See LICENSE file for details
Data Source: ClinicalTrials.gov (https://clinicaltrials.gov) API Documentation: https://clinicaltrials.gov/data-api/api Server Version: 0.1.0
Find clinical trials specifically designed for children and adolescents
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Pediatric condition or disease | |
| ageRange | No | Specific pediatric age range | |
| recruitmentStatus | No | Filter by recruitment status | |
| pageSize | No | Number of results to return (default 10, max 50) |
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 only states the population focus but does not disclose limitations, typical behavior, or side effects beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the purpose with no redundant information. Every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and many siblings, the description is too minimal. It lacks details on return format, pagination, default filters, or usage boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'clinical trials' with a specific population 'children and adolescents'. It distinguishes itself from general sibling tools like search_studies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_studies or get_recruiting_studies. It does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently recruiting clinical trials with contact information
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Medical condition to filter by | |
| location | No | Geographic location (city, state, country) | |
| ageGroup | No | Age group eligibility | |
| pageSize | No | Number of results to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states 'Get currently recruiting clinical trials with contact information', which is straightforward but lacks detail on pagination (implied by pageSize), result limits, or output structure. Behavior is transparent enough for a basic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with key action and resource. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 optional parameters and no output schema, the description does not explain how parameters interact, what fields are returned (e.g., contact information format), or any limitations. Insufficient for a tool returning detailed data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the verb 'Get', resource 'currently recruiting clinical trials', and includes 'with contact information', distinguishing it from sibling tools that focus on specific aspects like pediatric or results. However, it could be more specific about what 'contact information' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus the many sibling search and get tools, such as search_studies or get_study_details. The description does not mention prerequisites, filters, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find clinical trials similar to a specific study by NCT ID
| Name | Required | Description | Default |
|---|---|---|---|
| nctId | Yes | NCT ID of the reference study (e.g., NCT00000419) | |
| similarityType | No | Type of similarity to search for | CONDITION |
| pageSize | No | Number of results to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that it finds similar trials but does not explain what 'similar' means, whether the operation is read-only, or any side effects. This leaves significant gaps for the AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is very concise and directly communicates the tool's main purpose. While it could benefit from a bit more structure, it is efficient and has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description provides a basic understanding of what the tool does. However, it does not mention what the tool returns (e.g., a list of study IDs or details), which would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for each parameter including constraints (pattern, enum, min/max). The description adds no additional meaning beyond what the schema already provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds clinical trials similar to a specific study by NCT ID. This is a specific verb+resource combination that distinguishes it from sibling tools like search_by_condition or get_recruiting_studies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It is implied that it is useful when you have an NCT ID and want similar studies, but no exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find completed clinical trials that have published results
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Medical condition to filter by | |
| intervention | No | Treatment or intervention to filter by | |
| completedAfter | No | Find studies completed after this date (YYYY-MM-DD) | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only repeats the purpose without detailing aspects like filtering behavior, pagination, error handling, or side effects. The agent learns nothing beyond the basic scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core purpose without any extraneous words. It is front-loaded and effective for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should hint at return values, but it does not. With 4 input parameters and no explanation of their combined effect or result structure, the description leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters; the description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Find' and the specific resource 'completed clinical trials that have published results'. It distinguishes from sibling tools like `get_recruiting_studies` or `get_pediatric_studies` by focusing on completed trials with results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding completed trials with published results, but does not explicitly state when to use this tool versus alternatives from the sibling list, nor does it provide any exclusions or context about prerequisite states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific clinical trial
| Name | Required | Description | Default |
|---|---|---|---|
| nctId | Yes | NCT ID of the study (e.g., NCT00000419) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose any behavioral traits such as data freshness, permissions, rate limits, or what happens if the study is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the purpose, though it could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description is minimal. It lacks information about the return format or what constitutes 'detailed information', which would help the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a description and pattern for nctId. The tool description adds no additional meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'detailed information about a specific clinical trial'. This distinguishes it from sibling tools like 'get_pediatric_studies' which are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose implies it is for retrieving details given an NCT ID, but no exclusionary context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed timeline and milestone information for studies
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Condition to filter studies | |
| sponsor | No | Sponsor to filter studies | |
| phase | No | Study phase filter | |
| timelineType | No | Type of timeline analysis | CURRENT |
| pageSize | No | Number of results to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the general purpose without mentioning side effects, authentication needs, rate limits, pagination, or response structure. The tool retrieves data without indicating whether it's read-only or has any impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the tool's purpose. It is appropriately sized, though a bit more detail could be included without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 5 parameters (including optional filters and pagination) and no output schema, the description is incomplete. It does not explain the output format, pagination behavior, or how filters affect results. More context is needed for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The tool description adds no additional meaning beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'detailed timeline and milestone information for studies.' It sets proper expectations for the tool's functionality, though doesn't explicitly differentiate from the sibling tool 'get_study_details' which might also include timeline data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_study_details' or 'search_studies'. The description lacks context on appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate statistics about clinical trials
| Name | Required | Description | Default |
|---|---|---|---|
| groupBy | No | Field to group statistics by | |
| filters | No | Optional filters to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Get aggregate statistics' without explaining what statistics are returned (e.g., counts, percentages), whether the operation is read-only, or any side effects. This is insufficient for a tool with no other behavioral metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not front-load critical information, and while it is not verbose, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There are 16 sibling tools, yet the description provides no differentiation. The tool has no output schema, so the description should clarify what 'aggregate statistics' means, but it does not. Given the complexity of nested parameters and lack of required fields, more explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description does not add extra meaning beyond the schema, but since the schema already explains the parameters, a score of 3 is appropriate as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'aggregate statistics about clinical trials', making the purpose explicit. However, it does not explicitly distinguish itself from sibling tools like 'get_study_details' or the various search tools, though the concept of aggregate statistics implies a different usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context or prerequisites for use, leaving the agent to infer from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for clinical trials focusing on specific medical conditions
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | Medical condition, disease, or syndrome | |
| phase | No | Study phase filter | |
| recruitmentStatus | No | Filter by recruitment status | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as pagination behavior, rate limits, or what happens when no results are found. For a search tool, these are important.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but lacking structure. It does not front-load key details or organize information for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 16 sibling tools and no output schema, the description is incomplete. It does not explain return format, pagination, or how results are ordered, nor does it differentiate from similar search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions on all parameters, so baseline is 3. The description adds no additional meaning beyond the schema, offering no extra context for parameters like phase or recruitmentStatus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for clinical trials by medical condition. However, it does not differentiate from many sibling search tools like search_by_date_range or search_by_intervention, which also search clinical trials with different filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With 16 sibling tools including many other search functions, the lack of selection criteria is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search clinical trials by start or completion date range
| Name | Required | Description | Default |
|---|---|---|---|
| startDateFrom | No | Start date from (YYYY-MM-DD format) | |
| startDateTo | No | Start date to (YYYY-MM-DD format) | |
| completionDateFrom | No | Primary completion date from (YYYY-MM-DD format) | |
| completionDateTo | No | Primary completion date to (YYYY-MM-DD format) | |
| condition | No | Optional condition filter | |
| pageSize | No | Number of results to return (default 10, max 100) |
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 only states the basic functionality without disclosing behavioral traits such as pagination, read-only nature, rate limits, or return value details. The presence of a pageSize parameter implies pagination but is not explained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key verb and resource. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description is too brief. It does not explain how date ranges interact (e.g., inclusive/exclusive), how the condition filter integrates, or what the default behavior is. The description leaves significant gaps about usage expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all parameters. The description adds minimal value beyond restating the date range focus. It does not provide additional semantic context like date inclusivity or combination logic with the optional condition filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for clinical trials by date range, using a specific verb ('Search') and resource ('clinical trials'). It effectively differentiates from sibling tools that focus on other criteria like condition, location, or study type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description clarifies that the tool filters by start or completion date, it does not provide explicit guidance on when to use this tool versus siblings, nor does it mention any prerequisites or alternatives. The context is clear but lacks direct comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced search based on detailed eligibility criteria
| Name | Required | Description | Default |
|---|---|---|---|
| minAge | No | Minimum age (e.g., "18 Years", "6 Months") | |
| maxAge | No | Maximum age (e.g., "65 Years", "12 Years") | |
| sex | No | Sex eligibility | |
| healthyVolunteers | No | Whether study accepts healthy volunteers | |
| condition | No | Medical condition filter | |
| exclusionKeywords | No | Keywords that should NOT appear in eligibility criteria | |
| inclusionKeywords | No | Keywords that should appear in eligibility criteria | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only says 'Advanced search' without disclosing whether the tool is read-only, what it returns, or any side effects. Safety, rate limits, or destructive potential are unaddressed. This leaves agents guessing about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase, which is under-specified rather than concise. While it is short, it lacks informative content. A concise description would efficiently convey key details in a few sentences; this description omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain what 'advanced search' entails, how results are returned, or any context about eligibility criteria searching. The agent receives no meaningful completion of the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds no additional meaning beyond the schema, such as relationships between parameters or formatting hints. It does not enhance understanding of how to use the parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Advanced search based on detailed eligibility criteria,' which identifies the verb (search) and resource (eligibility criteria). However, it remains vague and does not distinguish from sibling tools like search_by_condition or search_studies, which also involve eligibility criteria. A more specific statement about what makes this 'advanced' would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling search tools. For instance, it does not mention prerequisites, limitations, or scenarios where search_by_condition would be more appropriate. The agent has no basis to choose this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search clinical trials by intervention or treatment type
| Name | Required | Description | Default |
|---|---|---|---|
| intervention | Yes | Intervention, drug, device, or treatment name | |
| interventionType | No | Type of intervention | |
| phase | No | Study phase filter | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the search intent without explaining what the tool returns, whether pagination is applied, or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the verb 'Search' and the resource. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should clarify what the tool returns (e.g., study IDs, summaries). It does not. Additionally, with 4 parameters and no behavioral context, the description is too minimal to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters, including enumerated types for interventionType and phase. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches clinical trials by intervention or treatment type, using a specific verb and resource. However, it does not differentiate from sibling tools like search_by_condition or search_by_location, which also search clinical trials by other criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling search tools (e.g., search_by_condition, search_by_eligibility_criteria). The description does not mention alternatives or context that would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find clinical trials by geographic location
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country name | |
| state | No | State or province | |
| city | No | City name | |
| facilityName | No | Name of medical facility or institution | |
| distance | No | Search radius in miles (when using city) | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the purpose without disclosing behavioral traits such as whether the tool is read-only, what happens with missing parameters, or any side effects. This is insufficient for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it could be slightly improved by front-loading the core action and listing key parameters, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description is too minimal. It does not explain how parameters like 'distance' relate to 'city', how results are ordered, or what the default behavior is. This leaves the agent with incomplete context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with clear descriptions for each parameter. The tool description adds no additional meaning beyond what is already in the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds clinical trials by geographic location, which is a specific verb+resource combination. However, it does not differentiate from sibling tools like 'search_international_studies' or 'search_studies', which could also involve location filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or scenarios where other search tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search clinical trials by primary outcome measures or endpoints
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | Primary outcome or endpoint to search for | |
| condition | No | Optional condition filter | |
| phase | No | Study phase filter | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It only states the search action but does not disclose behavior such as pagination, sorting, or whether results are filtered by date. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that conveys the core purpose. It is front-loaded and contains no filler, but could be slightly expanded with minimal context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description does not explain return values or behavior. It omits details on optional parameters (condition, phase, pageSize) that could be useful for an agent. Incomplete for a search tool with 4 parameters and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. Description adds no extra meaning beyond the schema; it repeats the main parameter 'outcome'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Search' and the resource 'clinical trials', and specifies the criterion 'by primary outcome measures or endpoints'. This distinguishes it from sibling tools like 'search_by_condition' or 'search_by_intervention'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Among many sibling search tools, no explicit context or when-not-to-use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search clinical trials by sponsor or organization
| Name | Required | Description | Default |
|---|---|---|---|
| sponsor | Yes | Sponsor name or organization (e.g., "Pfizer", "National Cancer Institute") | |
| sponsorType | No | Type of sponsor | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Search clinical trials by sponsor or organization' with no disclosure of behavioral traits such as pagination, result format, or side effects. This is insufficient for an agent to understand behavior beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word contributes to the core purpose. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about results, return structure, or limitations. It does not explain what the search returns or how to interpret results. For a tool with 3 parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description. The tool description does not add meaning beyond the schema. For baseline, score 3 is appropriate; the description merely restates the purpose without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search clinical trials by sponsor or organization'. It uses a specific verb ('search') and resource ('clinical trials'), and the 'by sponsor' qualifier distinguishes it from sibling tools like search_by_condition or search_by_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage through the description of filtering by sponsor, but lacks explicit conditions or exclusions. For a search tool with many siblings, this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find multi-country international clinical trials
| Name | Required | Description | Default |
|---|---|---|---|
| condition | No | Medical condition to filter by | |
| excludeCountry | No | Country to exclude from results (e.g., "United States") | |
| includeCountry | No | Country that must be included in results | |
| minCountries | No | Minimum number of countries involved | |
| phase | No | Study phase filter | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral transparency burden but only says 'Find', which is too vague. It does not disclose pagination behavior, result ordering, or any side effects. The schema covers parameters but not runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified for a search tool with 6 parameters. It earns its place but lacks front-loaded structure or elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 optional parameters, no annotations, no output schema), the description is incomplete. It does not explain how to combine filters, what results look like, or provide examples, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described in the input schema. The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find multi-country international clinical trials' clearly states the tool's purpose with a specific verb and resource, emphasizing the multi-country aspect. While it distinguishes from siblings like get_pediatric_studies, it could be more precise about what qualifies as an international study.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_by_condition or search_by_location. The description lacks explicit context, exclusions, or examples, leaving the agent to infer usage from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search clinical trials for rare diseases and orphan conditions
| Name | Required | Description | Default |
|---|---|---|---|
| rareDisease | Yes | Rare disease or orphan condition name | |
| recruitmentStatus | No | Filter by recruitment status | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'search clinical trials' but doesn't mention default pagination, result sorting, or any side effects. This is insufficient for an AI agent to understand behavior beyond basic input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It is appropriately sized but could benefit from more structure (e.g., listing key behaviors).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and many sibling tools, the description is too sparse. It doesn't explain what the results contain, any default filtering, or how it differs from similar search tools, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes parameters. The description adds no additional meaning beyond restating the focus on rare diseases, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches clinical trials, specifically for rare diseases and orphan conditions, which distinguishes it from sibling tools that search by condition generally or other criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like search_by_condition or search_studies. The description does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for clinical trials with various filters
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | General search term (condition, intervention, etc.) | |
| condition | No | Medical condition or disease | |
| intervention | No | Treatment, drug, or intervention | |
| location | No | Geographic location (city, state, country) | |
| phase | No | Study phase (PHASE1, PHASE2, PHASE3, PHASE4, NA) | |
| status | No | Recruitment status | |
| sex | No | Sex eligibility | |
| age | No | Age group | |
| pageSize | No | Number of results to return (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility and only says 'search.' It does not disclose whether results are paginated, if there are rate limits, or any data freshness details. The behavioral transparency is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, but it is too minimal and lacks structure. While front-loaded, it does not earn its place by adding sufficient value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description should explain filter combination logic and output format. It omits critical context like pagination and how filters interact, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and enums. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search for clinical trials with various filters,' which clearly indicates the verb and resource. However, it does not differentiate this tool from sibling tools like search_by_condition or search_by_intervention, making it vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this general search versus the many specialized sibling tools. It lacks explicit context for when-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but 'search_studies' is a general search that may overlap with the more specific search tools (e.g., search_by_condition). However, descriptions help differentiate them.
All tools follow a consistent verb_noun pattern: 'get_' for retrieval and 'search_' for queries. No mixing of conventions.
17 tools cover a broad range of clinical trial queries without being excessive. The count is well-scoped for a query-focused server.
The tool set covers major search dimensions (condition, location, sponsor, etc.) and details. Missing search by phase or combined filters, but overall comprehensive for read-only access.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
ClinicalTrials MCP — wraps ClinicalTrials.gov API v2 (free, no auth)
Provide structured access to ClinicalTrials.gov data for searching, retrieving, and analyzing clin…
Clinical trial search and status from ClinicalTrials.gov
Search ClinicalTrials.gov — find studies, retrieve results, match patients to eligible trials.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Augmented-Nature/ClinicalTrials-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
