Who Ictrp

io.github.pipeworx-iov0.1.0更新於 Oct 10, 2026

WHO ICTRP — the International Clinical Trials Registry Platform search

已驗證Streamable HTTP可網頁執行Data & AnalyticsKnowledge & Memory

概覽

AI 產生的概覽

檢索 WHO ICTRP 臨床試驗入口網站,涵蓋 ClinicalTrials.gov 與 WHO 各主要註冊庫,並可傳回單一試驗的完整紀錄。

功能
提供兩個工具:ictrp_search 可依自由文字查詢,也可依疾病、介入措施、贊助者或來源註冊庫篩選,傳回試驗編號、來源註冊庫、招募狀態、註冊日期、是否已公布結果及紀錄連結;ictrp_trial 依註冊庫編號傳回單一試驗的完整紀錄,包括標題、贊助者、狀態、研究設計與分期、招募國家、疾病、介入措施、結局、納入條件、樣本數、日期、資金來源及倫理審查狀態。回應帶有 data_as_of 時間戳記,試驗紀錄另含 last_refreshed_on。
適用情境
適合需要查找美國以外註冊的臨床試驗,尤其是中國、日本、印度或伊朗註冊庫的試驗,或需要取得某項試驗的 WHO 試驗註冊資料集。README 建議與 clinicaltrials、isrctn 和 anzctr 等套件搭配使用。
執行需求
使用供應商閘道上的遠端 streamable HTTP 端點;此套件端點未宣告需要帳號、API 金鑰或環境變數。文件另提供透過 npx 執行的本機 stdio 方式,需要 Node.js。需要能連線至閘道與 WHO 入口網站的網路。
安裝前請注意
此端點也會暴露閘道共用的中繼工具,例如 ask_pipeworx、discover_tools、search_within、remember 和 recall,因此列出的工具數量多於本套件本身的工具。README 說明此整合為獨立且非官方;入口網站沒有 JSON API,只能讀取公開的結果頁與紀錄頁;XML/CSV 匯出未被使用,因其條款限制商業用途。紀錄中包含聯絡人及倫理委員會聯絡方式,但工具不會傳回這些內容。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Who Ictrp,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。

其他 MCP 客戶端

把它新增到你客戶端的 mcpServers 設定中。

{
  "mcpServers": {
    "who-ictrp": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/who-ictrp/mcp"
    }
  }
}

README

@pipeworx/who-ictrp

WHO International Clinical Trials Registry Platform (trialsearch.who.int): one search across ClinicalTrials.gov and the WHO primary registries (ChiCTR, jRCT, CTRI, IRCT, DRKS, ANZCTR, ISRCTN, EU CTR/CTIS and more), plus the WHO Trial Registration Data Set for any one trial. It is the practical way to find Chinese, Japanese, Indian and Iranian trials next to the rest.

Part of Pipeworx — an MCP gateway connecting AI agents to 1764+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Tools

  • ictrp_search({query?, condition?, intervention?, sponsor?, registry?, recruiting_only?, limit?}) — trials matching a free-text query (titles, conditions, interventions, with WHO synonym expansion) and/or condition / intervention / sponsor fields. Each row carries the trial id, the source registry (code and name), recruitment status, registration date, whether results are posted and the ICTRP record URL. registry keeps only one source registry (ChiCTR, CTRI, IRCT, DRKS, jRCT, CT.gov, …). A search with no matches returns total_trials: 0 with the query used.
  • ictrp_trial({trial_id}) — the full record for one trial by its registry id: source registry and its record URL, titles, primary sponsor, status, study type and design, phase, countries of recruitment, conditions, interventions, outcomes, eligibility, sample size, dates, funding sources, secondary ids, ethics review status. An id ICTRP does not know returns found: false.

Every response carries data_as_of (the time the portal was read). ICTRP itself refreshes from the registries weekly; ictrp_trial returns last_refreshed_on for the record.

Use alongside clinicaltrials (the US registry's own API, richer for NCT trials), isrctn and anzctr.

Auth

Keyless.

Data sources

The portal has no JSON API. Things the next person would otherwise rediscover:

  • Search is a WebForms postback. GET the page for its __VIEWSTATE, __EVENTVALIDATION and the ApplicationGatewayAffinity cookies, then POST the whole form back with TextBox1 + Button1=Search (basic) or the ctl00$ContentPlaceHolder1$txt… fields + btnSearch (advanced). Posting a control the page did not render (e.g. a page size on the first POST) fails event validation and 302s to /NoAccess.aspx.
  • Page size is a second postback. __EVENTTARGET=DropDownList1, DropDownList1=100 (basic) or ctl00$ContentPlaceHolder1$ddlPageSize (advanced). 100 is the maximum.
  • The advanced search renders no pager, so a field search returns at most the newest 100 trials; the response says so in note when there are more. The basic search pages with __EVENTTARGET=GridView1, __EVENTARGUMENT=Page$N; with a registry filter the tool scans up to 5 pages (500 trials).
  • The result count wording changes: "407 records for 385 trials found" vs "1 trial found". A record is one registry entry; a trial groups the entries that cite each other as secondary ids.
  • Country is not filterable. The advanced search's country filter is a two-step listbox postback and its free-text box did not change the result count when tested (stroke: 18,749 records with and without "China"). Use registry for China/Japan/India/Iran, or ictrp_trial's countries.
  • The XML/CSV export is not used. It sits behind an "I agree" to terms that restrict commercial use of the downloaded data; this pack only reads the public result and record pages.
  • An unknown trial id answers HTTP 200 with the empty record template.
  • Records include contact persons (names, addresses, phone numbers, emails), including the ethics committee's contact. The tool does not return them.
  • Edge-probed 2026-10-09 from a throwaway wrangler dev --remote Worker: GET 200, search POST 200 ("407 records for 385 trials found for: psilocybin"), record page 200. No bot challenge on any of the three.

Quick Start

Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):

json
{  "mcpServers": {    "who-ictrp": {      "url": "https://gateway.pipeworx.io/who-ictrp/mcp"    }  }}

What this endpoint actually serves

tools/list at https://gateway.pipeworx.io/who-ictrp/mcp returns the tools in the table above plus the shared Pipeworx meta-tools — ask_pipeworx, discover_tools, search_within, remember/recall and the rest of the gateway-wide set. So the tool count you see is larger than this table: a single-pack endpoint currently lists roughly 30 shared tools alongside the pack's own. The connection's initialize response states its exact scope, and is the authoritative answer for a given day.

This is deliberate, not multiplexing by accident. The meta-tools are what let a scoped connection answer a question this pack does not cover — via ask_pipeworx, which routes across the whole catalog — without you adding a second MCP server. There is currently no way to mount a pack endpoint without them; if the extra schemas cost you more context than the routing is worth, connect to the full gateway once rather than to several pack endpoints.

Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:

json
{  "mcpServers": {    "pipeworx": {      "url": "https://gateway.pipeworx.io/mcp"    }  }}

Both URLs reach the same gateway and the same 1764+ data sources. The only difference is which pack's tools are listed directly; ask_pipeworx reaches all of them from either one.

No MCP client? Call it over HTTP

bash
curl -X POST https://gateway.pipeworx.io/v1/tools/ictrp_search \  -H 'Content-Type: application/json' \  -d '{"condition":"stroke","registry":"ChiCTR","limit":10}'

No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/ictrp_search. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.

Standalone (no gateway account)

This package also runs as a local stdio MCP server — no Pipeworx account, no gateway round-trip:

json
{  "mcpServers": {    "who-ictrp": {      "command": "npx",      "args": ["-y", "@pipeworx/mcp-who-ictrp"]    }  }}

Or run it directly to confirm it starts:

bash
npx -y @pipeworx/mcp-who-ictrp

It speaks MCP over stdin/stdout and answers initialize/tools/list/tools/call for only this pack's tools — none of the shared meta-tools the gateway connection above adds. Same source, same tools, no ask_pipeworx routing.

Using with ask_pipeworx

Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:

ask_pipeworx({ question: "your question about Who Ictrp data" })

The gateway picks the right tool and fills the arguments automatically.

More

License

MIT

來源:README.md,提交 f5cc764

工具

0
工具後設資料尚未被收錄。

版本歷史

1
  1. v0.1.0最新Oct 10, 2026