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., "@ChiCTR MCP Server search for KRAS G12D clinical trials from 2024"
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.
ChiCTR MCP Server 是一个基于 Model Context Protocol (MCP) 的临床试验查询服务，专门用于查询中国临床试验注册中心 (ChiCTR) 的临床试验信息。
当前版本: v2.0.2
✅ 修复详情空对象缓存命中问题（自动失效并重查）
✅ 进一步提升详情查询的有效内容获取稳定性
✅ 修复 Cherry Studio 场景下 ./cache 路径导致的启动失败（ENOENT）
✅ 默认缓存路径调整为 ~/.chictr/cache/chictr_cache.db
✅ 增加 /tmp/chictr/cache/chictr_cache.db 兜底路径
✅ 新增请求编排层（限速/重试/熔断）
✅ 新增 Session 池化与生命周期回收
✅ 新增挑战状态机与恢复工具（get_access_state / prepare_verification_session / resume_after_verification）
✅ 新增双层缓存（L1 内存 + L2 SQLite）与 get_cache_stats_v2
✅ 更新 README，添加多维度搜索示例
✅ 添加版本升级指南
✅ 提供 Cherrystudio 缓存清除方案
✅ 新增按注册号搜索（registration_number 参数）
✅ 新增按年份搜索（year 参数，默认当前年份）
✅ 所有搜索参数改为可选
✅ 修复详情查询 400 错误（使用正确的 project_id）
✅ 修复分页功能，支持多页结果获取
✅ 支持代理配置（HTTP_PROXY/HTTPS_PROXY）
✅ 增加验证码检测与友好错误提示
Related MCP server: Clinical Trials MCP Server
频繁请求可能触发滑动验证码，建议使用代理或增加请求间隔
headless 模式下无法手动处理验证码
stdio: 标准输入输出通信（默认）
http: HTTP REST API 服务（计划中）
sse: Server-Sent Events 实时通信服务（计划中）
MCP 协议兼容: 完全支持 Model Context Protocol 标准
多维度搜索: 支持按标题关键词、注册号、年份搜索
详细信息: 提供临床试验的完整详细信息
高性能: 内置智能缓存机制，提升查询速度
反爬虫处理: 使用浏览器自动化技术应对网站防护机制
将以下内容放入你的 MCP 客户端配置文件：
{
"mcpServers": {
"chictr": {
"command": "npx",
"args": ["-y", "chictr-mcp-server@latest"]
}
}
}如果你已全局安装（npm i -g chictr-mcp-server），可用更短配置：
{
"mcpServers": {
"chictr": {
"command": "chictr-mcp-server"
}
}
}npm installnpm run buildnpm start
# 或
node dist/index.js
# 带参数启动（未来版本支持）
# node dist/index.js --transport=http --port=3000搜索临床试验，支持按标题关键词、注册号、年份进行搜索
// 按关键词搜索
{
"name": "search_trials",
"arguments": {
"keyword": "KRAS",
"max_results": 20
}
}
// 按注册号搜索
{
"name": "search_trials",
"arguments": {
"registration_number": "ChiCTR2500111173"
}
}
// 按年份搜索
{
"name": "search_trials",
"arguments": {
"year": 2024,
"max_results": 20
}
}
// 组合搜索
{
"name": "search_trials",
"arguments": {
"keyword": "KRAS",
"year": 2024,
"max_results": 10
}
}参数说明：
keyword (可选): 注册题目关键词
registration_number (可选): 临床试验注册号
year (可选): 注册年份，默认当前年份
max_results (可选): 最大返回结果数，默认20
查询试验详情
{
"name": "get_trial_detail",
"arguments": {
"registration_number": "ChiCTR2500108082"
}
}获取缓存统计信息
{
"name": "get_cache_stats",
"arguments": {}
}清除所有缓存
{
"name": "clear_cache",
"arguments": {}
}获取双层缓存统计（L1 + L2 SQLite）
{
"name": "get_cache_stats_v2",
"arguments": {}
}获取运行时编排指标（限速/重试/挑战计数/会话统计）
{
"name": "get_runtime_metrics",
"arguments": {}
}获取访问状态机信息（NORMAL/SUSPECTED/CHALLENGED/COOLDOWN/RECOVERY）
{
"name": "get_access_state",
"arguments": {}
}创建人工验证会话
{
"name": "prepare_verification_session",
"arguments": {
"target_url": "https://www.chictr.org.cn/searchproj.html",
"timeout_ms": 300000
}
}人工验证完成后恢复访问状态
{
"name": "resume_after_verification",
"arguments": {
"verification_id": "verify_xxx"
}
}# 全局安装
npm install -g chictr-mcp-server
# 或者直接使用 npx（推荐）
npx -y chictr-mcp-server# 启动 STDIO 服务
chictr-mcp-server
# 或使用 npx
npx -y chictr-mcp-server
# 带参数启动（未来版本支持）
# chictr-mcp-server --transport=http --port=3000
# chictr-mcp-server --transport=sse --port=3000
# chictr-mcp-server --helpTypeScript: 类型安全的 JavaScript 超集
Playwright: 浏览器自动化工具
Cheerio: 服务器端 jQuery 实现
Node-Cache: 高性能缓存库
SQLite (better-sqlite3): 持久化二级缓存
MCP SDK: Model Context Protocol 官方 SDK
如果您需要使用代理访问 ChiCTR，可以通过环境变量配置：
# 设置 HTTP 代理
export HTTP_PROXY=http://your-proxy-server:port
# 或者 HTTPS 代理
export HTTPS_PROXY=http://your-proxy-server:port
# 然后启动服务
npx -y chictr-mcp-server{
"mcpServers": {
"chictr": {
"command": "npx",
"args": ["-y", "chictr-mcp-server"],
"env": {
"HTTP_PROXY": "http://your-proxy-server:port"
}
}
}
}注意：
代理配置是可选的，大多数情况下不需要
如果频繁触发验证码，建议使用代理或更换 IP
本项目不提供代理服务，需要用户自行准备
{
"mcpServers": {
"chictr": {
"command": "npx",
"args": ["-y", "chictr-mcp-server@latest"]
}
}
}npm install -g chictr-mcp-server{
"mcpServers": {
"chictr": {
"command": "chictr-mcp-server"
}
}
}{
"mcpServers": {
"chictr": {
"type": "http",
"url": "http://localhost:3000/mcp"
}
}
}{
"mcpServers": {
"chictr": {
"type": "sse",
"url": "http://localhost:3000/mcp"
}
}
}要测试 MCP 服务，您可以使用以下命令：
npx @modelcontextprotocol/inspector npx -y chictr-mcp-server需要提前安装 @modelcontextprotocol/inspector
npm install -g @modelcontextprotocol/inspector
智能缓存: 搜索结果缓存 5 分钟，详情数据缓存 10 分钟
浏览器自动化: 使用 Playwright 模拟真实浏览器行为
反爬虫处理: 内置 User-Agent 和延迟机制
# 搜索最近 6 个月的 KRAS G12D 相关试验
{
"name": "search_trials",
"arguments": {
"keyword": "KRAS G12D",
"months": 6,
"max_results": 10
}
}# 查询注册号为 ChiCTR2500108082 的试验详情
{
"name": "get_trial_detail",
"arguments": {
"registration_number": "ChiCTR2500108082"
}
}{
"results": [
{
"registration_number": "ChiCTR2500108082",
"title": "谷氨酰胺联合奥沙利铂、卡培他滨（XELOX）和贝伐珠单抗一线治疗KRAS G12D基因突变型晚期结直肠癌的单臂Ⅱ期探索性研究",
"study_type": "干预性研究",
"registration_date": "2025/08/25",
"institution": "浙江大学医学院附属第二医院"
}
]
}{
"compilerOptions": {
"target": "ES2022",
"module": "Node16",
"outDir": "./dist",
"rootDir": "./src"
}
}搜索结果缓存: 5 分钟 (300 秒)
详情数据缓存: 10 分钟 (600 秒)
ChiCTR MCP Server 当前支持 STDIO 通信方式，可以轻松集成到任何支持 MCP 协议的应用中：
通过标准输入输出与客户端通信，适用于大多数 MCP 客户端。
通过 HTTP REST API 与客户端通信，支持跨网络访问。
端点: http://localhost:3000/mcp
方法: POST
Content-Type: application/json
通过 Server-Sent Events 与客户端通信，支持实时推送。
端点: http://localhost:3000/mcp
事件类型: message
MIT License
如有问题，请提交 GitHub Issue。
本项目使用中国临床试验注册中心 (ChiCTR) 的公开数据，感谢 ChiCTR 为医学研究做出的贡献。 特别感谢小胰宝和 小x宝社区的❤️贡献与付出，用爱心与人工智能为癌症/罕见病患者及其家庭提供支持！
清除所有缓存数据
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. '清除所有缓存数据' implies a destructive mutation (clearing all cache), but it doesn't specify whether this action is reversible, requires authentication, has side effects (e.g., temporary slowdown), or returns confirmation. For a mutation tool with zero annotation coverage, this is a significant gap in safety and operational 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?
The description is a single, efficient sentence ('清除所有缓存数据') with zero waste. It's front-loaded with the core action and resource, making it immediately understandable. No extraneous words or structural issues are 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's complexity (destructive mutation with no parameters) and lack of annotations/output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions needed, confirmation process, or impact on system performance. For a tool that clears all cache data, this minimal description leaves critical operational gaps.
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 tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, as there are none. It appropriately focuses on the tool's action without redundant parameter details, meeting the baseline for zero-parameter tools.
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 '清除所有缓存数据' (Clear all cache data) clearly states the tool's action and resource with a specific verb ('清除' - clear) and target ('所有缓存数据' - all cache data). It distinguishes from sibling tools like 'get_cache_stats' (read-only) and 'search_trials' (different resource), though it doesn't explicitly mention these distinctions. The purpose is unambiguous but lacks explicit sibling differentiation.
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 alternatives. It doesn't mention prerequisites (e.g., admin permissions), consequences (e.g., performance impact), or when to avoid it (e.g., during peak usage). With siblings like 'get_cache_stats' for monitoring, the description fails to help the agent choose between read and write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取缓存统计信息，包括搜索缓存和详情缓存的命中率等
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While it mentions what statistics are retrieved (hit rates for search and detail caches), it doesn't disclose important behavioral traits like whether this requires authentication, rate limits, what format the statistics are returned in, or whether this is a read-only operation. The description is minimal and lacks operational 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?
The description is a single, efficient sentence that states the purpose without unnecessary elaboration. It's appropriately sized for a zero-parameter tool that retrieves statistics, though it could be slightly more structured by explicitly stating it's a read operation.
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 no parameters, no annotations, and no output schema, the description provides basic purpose information but lacks important context. For a statistics retrieval tool, it should ideally mention the format of returned data, whether it's real-time or cached statistics, and any authentication requirements. The description is minimally adequate but has clear gaps.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this (empty object).
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: '获取缓存统计信息' (get cache statistics) with specific mention of '搜索缓存和详情缓存的命中率等' (hit rates for search cache and detail cache). It uses a specific verb ('获取' - get) and resource ('缓存统计信息' - cache statistics), though it doesn't explicitly distinguish from sibling tools like clear_cache.
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 alternatives. There's no mention of when this tool should be used, when it shouldn't, or how it relates to sibling tools like clear_cache, get_trial_detail, or search_trials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据注册号查询临床试验的完整详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| registration_number | Yes | 临床试验注册号，如 'ChiCTR2400084905' |
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 this is a query operation, implying it's likely read-only and non-destructive, but doesn't explicitly confirm this or describe other traits like error handling, rate limits, authentication needs, or what constitutes '完整详细信息' (complete detailed information) in the response. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple lookup tool and front-loaded with the core functionality, making it easy to parse quickly.
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's low complexity (one required parameter, no nested objects) and high schema coverage, the description is adequate but has clear gaps. It lacks output schema information, so the agent doesn't know what '完整详细信息' entails in the response. Combined with no annotations and minimal behavioral context, this leaves the description incomplete for optimal agent use, though it meets minimum viability for a simple query tool.
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 description adds minimal semantic context beyond the input schema. It mentions the parameter '注册号' (registration number), which aligns with the schema's 'registration_number' property. However, with 100% schema description coverage (the schema already documents the parameter as '临床试验注册号，如 'ChiCTR2400084905''), the description doesn't provide additional details like format examples or usage nuances. This meets the baseline score of 3 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据注册号查询临床试验的完整详细信息' (Query complete detailed information of clinical trials based on registration number). It specifies the verb ('查询' - query) and resource ('临床试验的完整详细信息' - complete detailed information of clinical trials), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_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.
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 'search_trials' or clarify scenarios where this tool is preferred (e.g., for looking up specific trials by exact registration number versus broader searches). There's also no information about prerequisites or exclusions, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索ChiCTR临床试验。支持按标题关键词、注册号、年份进行搜索，返回试验列表。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | 注册题目关键词，如 'KRAS G12C'、'胰腺癌' 等（可选） | |
| registration_number | No | 临床试验注册号，如 'ChiCTR2500111173'（可选） | |
| year | No | 注册年份，如 2024、2025，默认为当前年份（可选） | |
| max_results | No | 最大返回结果数，默认20 |
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. While it mentions the search functionality and return format (trial list), it lacks important behavioral details: whether this is a read-only operation (implied but not stated), any rate limits, authentication requirements, pagination behavior beyond max_results, or what happens when no results are found. The description provides basic functional information but misses key operational 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?
The description is appropriately concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the main action (searching ChiCTR clinical trials) followed by the search criteria and return format. There's no wasted language, though it could potentially benefit from slightly more detail given the lack of annotations and output schema.
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 a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. While it covers the basic 'what', it lacks important context: what the returned trial list contains, how results are ordered, whether all parameters are optional (implied but not stated), error conditions, or any limitations of the search functionality. The absence of output schema means the description should ideally provide some indication of return format.
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 description mentions the three main search parameters (title keywords, registration number, year) which aligns with the input schema's properties. However, with 100% schema description coverage, the schema already provides excellent parameter documentation including examples and defaults. The description adds minimal value beyond what's in the schema - it confirms the parameter purposes but doesn't provide additional context about parameter interactions, search logic, or edge cases.
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: searching ChiCTR clinical trials with specific search criteria (title keywords, registration number, year) and returning a list of trials. It uses specific verbs ('搜索' - search, '返回' - return) and identifies the resource (ChiCTR临床试验). However, it doesn't explicitly differentiate from sibling tools like 'get_trial_detail' which likely retrieves detailed information about a specific trial rather than searching multiple trials.
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 alternatives. While it mentions what the tool does, it doesn't indicate when it's appropriate to use search_trials versus get_trial_detail (which presumably gets details for a specific trial) or other siblings. There's no mention of prerequisites, limitations, or typical use cases beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.1clear_cacheget_cache_statsget_trial_detailsearch_trialsEach tool has a clearly distinct purpose with no overlap: clear_cache removes data, get_cache_stats retrieves performance metrics, get_trial_detail fetches a single trial by ID, and search_trials finds multiple trials based on criteria. An agent can easily differentiate these functions.
All tool names follow a consistent verb_noun pattern in snake_case: clear_cache, get_cache_stats, get_trial_detail, and search_trials. This uniformity makes the set predictable and easy to understand.
With 4 tools, the count is reasonable for a ChiCTR trials server, covering core operations like search and detail retrieval. It feels slightly thin but not inadequate, as it supports basic workflows without bloat.
The toolset covers search and detail retrieval for trials, plus cache management, but lacks update or creation tools for trials, which might be expected in a full CRUD lifecycle. This gap could limit agent actions in dynamic scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Clinical trial search and status from ClinicalTrials.gov
Provide structured access to ClinicalTrials.gov data for searching, retrieving, and analyzing clin…
Search ClinicalTrials.gov — find studies, retrieve results, match patients to eligible trials.
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PancrePal-xiaoyibao/chictr-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server