Skip to main content
Glama
Aki894

mcp-ClinicalTrial

by Aki894
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

ClinicalTrials.gov 不良事件对照 MCP 服务器

一个用于分析临床试验不良事件数据的MCP（Model Context Protocol）服务器，专为药物安全性评估和不良事件对照分析设计。通过ClinicalTrials.gov API v2提供临床试验数据的智能分析功能。

功能特性

  • 临床试验搜索: 使用ClinicalTrials.gov API v2搜索临床试验数据

  • 不良事件对照分析: 对比分析特定药物与安慰剂/阳性对照药的不良事件风险

  • 安全性特征分析: 提供药物安全性的基线参考和证据补强

  • 剂量-反应关系: 分析不同剂量下的风险差异验证

  • 研究详情获取: 获取特定NCT ID的详细临床试验信息

Related MCP server: OpenFDA MCP Server

可用工具

1. search_clinical_trials

搜索临床试验，支持多种查询条件。

参数:

  • condition (string): 医疗条件或疾病，如 "lung cancer", "diabetes"

  • intervention (string): 药物或干预措施名称，如 "Vemurafenib", "chemotherapy"

  • outcome (string): 结果指标，如 "overall survival", "adverse events"

  • sponsor (string): 研究赞助方，如 "National Cancer Institute"

  • status (string): 研究状态，如 "RECRUITING", "COMPLETED"

  • location (string): 研究地点，如 "New York", "United States"

  • nct_id (string): 特定NCT ID，如 "NCT04267848"

  • pageSize (number): 返回记录数限制 (1-1000)

  • countTotal (boolean): 是否统计总数

2. get_study_details

获取特定临床试验的详细信息。

参数:

  • nct_id (string, 必需): 研究的NCT ID，如 "NCT04267848"

3. compare_adverse_events

核心功能: 对比分析特定药物的不良事件数据，提供基线参考和安全性评估。

参数:

  • drug_name (string, 必需): 要分析的药物名称

  • control_type (string): 对照类型

    • "placebo": 与安慰剂对比（默认）

    • "active_control": 与其他药物对比

    • "dose_comparison": 不同剂量对比

  • condition (string): 医疗条件，用于聚焦搜索

  • limit (number): 分析的研究数量限制 (1-50)

4. analyze_safety_profile

核心功能: 分析药物的安全性特征，提供风险评估和剂量-反应关系。

参数:

  • drug_name (string, 必需): 要分析的药物名称

  • condition (string): 医疗条件背景

  • include_completed_only (boolean): 仅包含已完成的研究（默认true）

  • limit (number): 分析的研究数量限制 (1-100)

核心功能说明

不良事件对照分析

本服务器的核心功能是通过对比分析特定药物临床试验中的不良事件数据，为药物安全性特征提供科学依据：

  1. 基线参考: 与安慰剂或阳性对照药的风险对比

  2. 证据补强: 不同剂量下的风险差异验证

  3. 风险评估: 基于多项研究的综合安全性分析

  4. 统计分析: 不良事件发生率、严重程度分级等

API数据源

安装和运行

本地开发

# 安装依赖
npm install

# 开发模式运行
npm run dev

# 构建
npm run build

# 生产模式运行
npm start

Ubuntu服务器部署

1. 环境准备

# 更新系统
sudo apt update && sudo apt upgrade -y

# 安装Node.js 18+
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs

# 验证安装
node --version
npm --version

2. 部署MCP服务器

# 创建项目目录
mkdir -p ~/mcp-servers/clinicaltrials
cd ~/mcp-servers/clinicaltrials

# 上传项目文件（使用scp或git clone）
# 方法1: 使用git
git clone <your-repo-url> .

# 方法2: 使用scp从本地上传
# scp -r /path/to/mcp-openfda/* user@your-server:~/mcp-servers/openfda/

# 安装依赖
npm install

# 构建项目
npm run build

# 测试运行
npm start

3. 使用PM2管理进程（推荐）

# 全局安装PM2
sudo npm install -g pm2

# 创建PM2配置文件
cat > ecosystem.config.js << 'EOF'
module.exports = {
  apps: [{
    name: 'mcp-clinicaltrials',
    script: 'dist/index.js',
    cwd: '/home/ubuntu/mcp-servers/clinicaltrials',
    instances: 1,
    autorestart: true,
    watch: false,
    max_memory_restart: '1G',
    env: {
      NODE_ENV: 'production'
    }
  }]
}
EOF

# 启动服务
pm2 start ecosystem.config.js

# 设置开机自启
pm2 startup
pm2 save

# 查看状态
pm2 status
pm2 logs mcp-clinicaltrials

4. 配置防火墙（如果需要网络访问）

# 如果需要通过网络访问，可以配置nginx反向代理
sudo apt install nginx

# 创建nginx配置
sudo tee /etc/nginx/sites-available/mcp-clinicaltrials << 'EOF'
server {
    listen 80;
    server_name your-domain.com;  # 替换为你的域名或IP
    
    location / {
        proxy_pass http://localhost:3000;  # 如果MCP服务器监听3000端口
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}
EOF

# 启用站点
sudo ln -s /etc/nginx/sites-available/mcp-clinicaltrials /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

远程调用配置

方法1: 通过SSH隧道

在客户端机器上创建SSH隧道：

# 创建SSH隧道，将本地端口转发到服务器
ssh -L 3000:localhost:3000 user@your-server-ip

# 然后在MCP客户端配置中使用 localhost:3000

方法2: 网络MCP服务器

如果需要通过网络直接访问，需要修改MCP服务器以支持网络传输：

// 在src/index.ts中添加网络传输支持
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";

// 替换stdio传输为网络传输
const transport = new SSEServerTransport("/message", response);

方法3: 使用Docker部署

# 创建Dockerfile
cat > Dockerfile << 'EOF'
FROM node:18-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

COPY dist/ ./dist/
COPY src/ ./src/

EXPOSE 3000

CMD ["npm", "start"]
EOF

# 构建和运行
docker build -t mcp-clinicaltrials .
docker run -d -p 3000:3000 --name mcp-clinicaltrials-server mcp-clinicaltrials

使用示例

在Claude Desktop中配置

在Claude Desktop的配置文件中添加：

{
  "mcpServers": {
    "clinicaltrials": {
      "command": "node",
      "args": ["/path/to/mcp-clinicaltrials/dist/index.js"],
      "env": {}
    }
  }
}

远程服务器配置

{
  "mcpServers": {
    "clinicaltrials": {
      "command": "ssh",
      "args": [
        "user@your-server-ip",
        "cd ~/mcp-servers/clinicaltrials && node dist/index.js"
      ],
      "env": {}
    }
  }
}

API使用示例

// 搜索肺癌相关的临床试验
await searchClinicalTrials({
  condition: "lung cancer",
  intervention: "pembrolizumab",
  status: "COMPLETED",
  pageSize: 10
});

// 获取特定研究的详细信息
await getStudyDetails("NCT04267848");

// 对比分析药物不良事件（核心功能）
await compareAdverseEvents({
  drug_name: "pembrolizumab",
  control_type: "placebo",
  condition: "lung cancer",
  limit: 20
});

// 分析药物安全性特征（核心功能）
await analyzeSafetyProfile({
  drug_name: "pembrolizumab",
  condition: "cancer",
  include_completed_only: true,
  limit: 50
});

使用场景

药物安全性评估

  • 新药上市前的安全性数据收集

  • 已上市药物的安全性监测

  • 药物不良反应的对照分析

临床研究支持

  • 临床试验设计中的安全性参考

  • 竞品药物的安全性对比

  • 监管申报的支持数据

学术研究

  • 药物流行病学研究

  • 安全性Meta分析

  • 药物警戒研究

注意事项

  1. API限制: ClinicalTrials.gov API有速率限制，建议合理控制请求频率

  2. 数据准确性: 返回的数据仅供参考，不应作为最终医疗决策依据

  3. 数据完整性: 并非所有临床试验都有完整的不良事件数据

  4. 统计意义: 建议结合专业统计分析工具进行深入分析

  5. 监管合规: 使用数据时请遵守相关法规要求

故障排除

常见问题

  1. 连接失败: 检查网络连接和防火墙设置

  2. 权限错误: 确保Node.js进程有适当的文件权限

  3. 端口冲突: 检查端口是否被其他服务占用

日志查看

# PM2日志
pm2 logs mcp-clinicaltrials

# 系统日志
sudo journalctl -u nginx -f

技术架构

  • API版本: ClinicalTrials.gov API v2

  • 数据格式: JSON (符合OpenAPI 3.0规范)

  • 认证方式: 无需认证（公开API）

  • 响应格式: 标准化JSON响应

  • 错误处理: 完整的错误捕获和处理机制

许可证

GPL-3.0 License

Available Tools

5 tools
ae_pipeline_ragA

Advanced RAG pipeline for adverse events analysis. Fetches, extracts, chunks, retrieves and summarizes clinical trial data in one call to prevent LLM response truncation.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoNatural language query about adverse events. Example: 'gastrointestinal bleeding risk vs placebo'
drugNoDrug name to focus the analysis on. Example: 'Vemurafenib'
conditionNoMedical condition context. Example: 'melanoma', 'cancer'
top_kNoNumber of most relevant text chunks to return (1-10)
filtersNoAdditional filters for data retrieval

TDQS

A3.5/5.0
Behavior2/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 of behavioral disclosure. It mentions the tool performs multiple steps 'in one call' to prevent truncation, which is useful context, but lacks critical details like whether it's read-only or mutative, what permissions are needed, rate limits, error handling, or what the output looks like. For a complex pipeline tool with zero annotation coverage, this is a significant gap.

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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the second explaining the key benefit ('in one call to prevent LLM response truncation'). Every sentence earns its place, though it could be slightly more concise by combining ideas.

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

Completeness2/5

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

Given the tool's complexity (a multi-step RAG pipeline), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, performance, or output format, leaving significant gaps for an AI agent to understand how to invoke it correctly and interpret results.

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 all 5 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain how parameters interact or provide additional examples). Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose with specific verbs ('fetches, extracts, chunks, retrieves and summarizes') and resource ('clinical trial data'), and distinguishes it from siblings by emphasizing it's an 'Advanced RAG pipeline for adverse events analysis' that handles everything 'in one call to prevent LLM response truncation'—unlike the more focused sibling tools.

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 clear context for when to use this tool ('for adverse events analysis' and 'to prevent LLM response truncation'), implying it's a comprehensive alternative to multiple calls. However, it doesn't explicitly state when not to use it or name specific sibling alternatives for comparison, which would elevate it to a 5.

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

analyze_safety_profileC

Analyze safety profile of a drug by extracting and comparing adverse events data across multiple clinical trials. Provides risk assessment and dose-response relationships.

ParametersJSON Schema
NameRequiredDescriptionDefault
drug_nameYesName of the drug to analyze
conditionNoMedical condition context
include_completed_onlyNoOnly include completed studies with results
limitNoMaximum number of studies to analyze

TDQS

C2.9/5.0
Behavior2/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 of behavioral disclosure. It mentions 'extracting and comparing adverse events data' and 'provides risk assessment and dose-response relationships', which gives some insight into what the tool does. However, it lacks details on permissions, rate limits, data sources, whether it's read-only or mutative, response format, or error handling—critical for a tool with potential complexity.

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 concise and front-loaded, stating the core purpose in the first sentence. The second sentence adds value by specifying outputs (risk assessment, dose-response relationships). Both sentences earn their place, with no wasted words, though it could be slightly more structured for clarity.

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

Completeness2/5

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

Given the complexity (analyzing drug safety across trials), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like data sources, permissions, or response format, and while it mentions outputs, it doesn't detail them. For a tool with 4 parameters and potential for rich analysis, more context is needed to guide effective use.

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%, meaning all parameters are documented in the schema. The description adds no specific parameter semantics beyond what's in the schema (e.g., it doesn't explain 'drug_name' or 'condition' further). However, it implies the scope of analysis (across clinical trials), which loosely relates to parameters but doesn't provide additional value. Baseline 3 is appropriate given high schema coverage.

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 states the tool's purpose: 'Analyze safety profile of a drug by extracting and comparing adverse events data across multiple clinical trials.' It specifies the verb (analyze), resource (safety profile of a drug), and method (extracting/comparing adverse events data). However, it doesn't explicitly differentiate from sibling tools like 'compare_adverse_events' or 'search_clinical_trials', which appear related to similar domains.

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

Usage Guidelines2/5

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 alternatives. It doesn't mention sibling tools like 'compare_adverse_events' or 'search_clinical_trials', nor does it specify prerequisites, contexts where it's preferred, or exclusions. Usage is implied through the description but not explicitly stated.

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

compare_adverse_eventsC

Compare adverse events between treatment and control groups for a specific drug across clinical trials. Provides baseline reference and evidence for drug safety analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault
drug_nameYesName of the drug to analyze for adverse events
control_typeNoType of control comparison: placebo (vs placebo), active_control (vs other drugs), dose_comparison (different doses)placebo
conditionNoMedical condition to focus the search. Example: 'cancer', 'diabetes'
limitNoMaximum number of studies to analyze

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'compares adverse events' and 'provides baseline reference and evidence' but doesn't specify what format the comparison takes, whether it performs statistical analysis, how it aggregates data across trials, or what the output looks like. For a tool with 4 parameters and no annotations, this leaves significant behavioral gaps.

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 appropriately concise with two sentences that directly address purpose and value. The first sentence clearly states what the tool does, and the second explains its utility. There's no wasted verbiage, though it could be slightly more structured with explicit usage guidance.

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

Completeness2/5

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

For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the comparison output looks like, how results are presented, whether statistical significance is calculated, or how data from multiple trials is synthesized. The description leaves too many behavioral questions unanswered for effective agent use.

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 all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'drug_name' relates to 'condition' filtering or what 'limit' controls precisely). Baseline 3 is appropriate when the schema does the heavy lifting.

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 states the tool's purpose: comparing adverse events between treatment and control groups for a specific drug across clinical trials. It specifies the verb ('compare') and resource ('adverse events'), but doesn't explicitly differentiate from sibling tools like 'analyze_safety_profile' or 'search_clinical_trials', which might have overlapping functionality.

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

Usage Guidelines2/5

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

The description provides minimal guidance on when to use this tool, stating it 'provides baseline reference and evidence for drug safety analysis' but offering no explicit when/when-not criteria or alternatives. It doesn't mention how this differs from sibling tools like 'analyze_safety_profile' or when to choose one over the other.

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

get_study_detailsB

Get detailed information about a specific clinical trial by NCT ID

ParametersJSON Schema
NameRequiredDescriptionDefault
nct_idYesNCT ID of the study. Example: 'NCT04267848'

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't mention potential errors (e.g., invalid NCT ID), rate limits, authentication needs, or what happens if the study isn't found. This leaves significant gaps for a tool that likely interacts with an external database.

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 a single, efficient sentence that front-loads the core purpose ('Get detailed information') without any wasted words. It directly addresses what the tool does and how to identify the resource, making it highly concise and well-structured.

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

Completeness3/5

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

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter context, but lacks details on return values, error handling, or behavioral traits, which are important for a read operation in a clinical context.

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 input schema has 100% description coverage, with the parameter 'nct_id' well-documented in the schema. The description adds no additional meaning beyond implying the parameter is required for lookup, so it meets the baseline of 3 without compensating for any gaps.

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 states the verb 'Get' and the resource 'detailed information about a specific clinical trial', specifying the identifier type 'by NCT ID'. It distinguishes from siblings like 'search_clinical_trials' by focusing on retrieval of a single study rather than searching. However, it doesn't explicitly mention what details are included, keeping it at a 4.

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 implies usage when you have a specific NCT ID, contrasting with 'search_clinical_trials' for broader queries. However, it lacks explicit guidance on when not to use it (e.g., for multiple studies) or alternatives beyond the sibling name, making it only implied rather than explicit.

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

search_clinical_trialsC

Search clinical trials using ClinicalTrials.gov API v2. Returns study information including protocols, interventions, and outcomes.

ParametersJSON Schema
NameRequiredDescriptionDefault
conditionNoMedical condition or disease. Example: 'lung cancer', 'diabetes'
interventionNoDrug or intervention name. Example: 'Vemurafenib', 'chemotherapy'
outcomeNoOutcome measure. Example: 'overall survival', 'adverse events'
sponsorNoStudy sponsor. Example: 'National Cancer Institute'
statusNoStudy status. Example: 'RECRUITING', 'COMPLETED'
locationNoStudy location. Example: 'New York', 'United States'
nct_idNoSpecific NCT ID. Example: 'NCT04267848'
pageSizeNoMaximum number of records to return (1-1000)
countTotalNoWhether to count total number of studies

TDQS

C2.9/5.0
Behavior2/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 of behavioral disclosure. It mentions the API version (v2) and that it 'returns study information including protocols, interventions, and outcomes,' but lacks details on rate limits, authentication needs, pagination behavior, error handling, or whether it's read-only or destructive. For a search tool with 9 parameters and no annotations, this 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.

Conciseness4/5

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

The description is concise and front-loaded, consisting of two clear sentences that state the tool's purpose and what it returns. There's no wasted verbiage, though it could be slightly more structured (e.g., by explicitly listing key use cases).

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

Completeness3/5

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

Given the complexity (9 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return scope but lacks behavioral details, usage context, and output format explanations. Without annotations or output schema, the agent must infer much from the schema alone, leaving gaps in understanding.

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 description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how parameters interact or provide search syntax). This meets the baseline for high schema coverage but doesn't enhance understanding.

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 states the tool's purpose: 'Search clinical trials using ClinicalTrials.gov API v2.' It specifies the action (search) and resource (clinical trials), and mentions the data source (ClinicalTrials.gov API v2). However, it doesn't explicitly differentiate from sibling tools like 'get_study_details' or 'analyze_safety_profile', which prevents a perfect score.

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

Usage Guidelines2/5

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 alternatives. It doesn't mention sibling tools like 'get_study_details' (for specific studies) or 'analyze_safety_profile' (for safety analysis), nor does it specify prerequisites or exclusions. This leaves the agent without contextual usage instructions.

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

B3.3/5.0
Disambiguation4/5

Most tools have distinct purposes, but there is some potential overlap between 'analyze_safety_profile' and 'compare_adverse_events' as both involve adverse events analysis. The descriptions help differentiate them, with one focusing on overall safety profiling and the other on group comparisons, but an agent might initially confuse their scopes.

Naming Consistency3/5

The naming conventions are mixed, with tools using verb_noun patterns like 'search_clinical_trials' and 'get_study_details', but others like 'ae_pipeline_rag' and 'analyze_safety_profile' deviate with acronyms or noun-heavy structures. This inconsistency reduces predictability, though the names remain generally readable.

Tool Count5/5

With 5 tools, the count is well-scoped for a clinical trial server, covering search, retrieval, and analysis functions. Each tool appears to earn its place without redundancy, providing a focused set for typical agent workflows in this domain.

Completeness4/5

The tool set covers core operations like search, retrieval, and analysis of clinical trial data, with good lifecycle coverage from finding trials to detailed analysis. A minor gap exists in update or management functions, but this is reasonable for a read/analysis-focused server, and agents can work around it effectively.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • aria-mcp-server

    pkotecha-eng
    A
    license
    A
    quality
    C
    maintenance
    Clinical research MCP server providing real-time access to PubMed (35M+ papers) and ClinicalTrials.gov (400K+ trials). Built for trial coordinators and life sciences teams. No API key required.
    3
    3
    MIT

  • OpenFDA MCP Server

    Augmented-Nature
    F
    license
    B
    quality
    C
    maintenance
    A comprehensive MCP server that provides access to U.S. FDA public datasets via the openFDA API, enabling querying of drug adverse events, labeling, recalls, approvals, shortages, NDC directory, and medical device regulatory data.
    10
    21

  • DrugWise

    VidyasreeJayaprasad
    F
    license
    B
    quality
    B
    maintenance
    An MCP server that provides AI-assisted clinical decision support for medication safety, integrating trusted biomedical sources to detect drug interactions and suggest therapeutic alternatives.
    5
    1

Latest Blog Posts

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/Aki894/mcp-ClinicalTrial'

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