Herb Tcm

@pipeworx/herb-tcm

HERB 2.0 中药知识库——涵盖草药、成分、基因靶点、疾病、引用 PubMed 的论文和 GEO 转录组实验，数据实时代理自 herb.ac.cn。每条关系记录都标有 evidence_tier，确保统计预测不会被误认为疗效证明。

这是 Pipeworx 的一部分——一个将 AI Agent 连接到 1881+ 个实时数据源的 MCP 网关。这是一个独立的非官方集成，与上游提供方无关联、未获其背书，也非由其发布。

工具

• herb_search(keyword, category?) — 将名称解析为 id。接受汉字、拼音、英文／拉丁文名称、基因名称／别名、疾病名称，或 HERB id 本身。category 可选 herb / ingredient / target / disease（默认值为 herb）。
• herb_browse(category, page?, page_size?) — 分页浏览完整的草药／成分／靶点／疾病列表（分别有 7,263 / 49,258 / 12,933 / 28,212 条记录）。
• herb_detail(id, category, limit?, offset?, sections?) — 获取某个 id 的完整记录：成分组成、传统用途摘要，以及所有预测或有文献支持的靶点／疾病关系，每条关系都带有 evidence_tier。关系表采用分页方式（fleet #1399——未经分页的热门草药记录达到 806 KB）：每张表以 {total, offset, limit, returned, truncated, rows} 的形式返回，其中 total 是上游的真实记录总数，truncated: true 表示还有更多记录，因此不会把 25 条记录的分页结果误认为总共只有 25 条。limit 默认值为 25（沿用该包中 herb_papers 的惯例），最大值为 200；offset 用于分页；sections（例如 ["summary","herb_ingredient"]）可在不拉取数千条预测疾病记录的情况下获取成分组成；未知的区段名称会明确报错，而不是悄无声息地返回空结果。之所以选择客户端切片，而不是仅使用 sections 的设计，是因为 detail_api 不支持服务端分页（无论如何，一次上游调用都会返回所有内容），因此切片不会增加成本，而返回结构也能让调用方清楚了解结果。ingredient_alias（一个简短的同义词列表）始终不分页。
• herb_papers(drug_type?, experiment_type?, sort_by?, limit?, offset?) — 列出引用 PubMed 的文献，每篇都标有 human_clinical 或 laboratory。
• herb_paper_detail(paper_id) — 获取一篇文献的书目信息，以及文中报告的具体靶点／疾病。
• herb_experiments(drug_type?, species?, experiment_type?, limit?, offset?) — 列出存储在 GEO 中的草药／成分与对照组之间的转录组实验。
• herb_experiment_detail(experiment_id) — 获取一项实验的差异表达结果：上调／下调基因、富集的 GO／KEGG 术语、连接图谱命中次数。evidence_tier 始终为 computational_prediction。

证据等级

每条关系记录都属于以下某个等级：

等级	含义
traditional_use	来自该草药类似药典的摘要（功能／主治／归经）。属于历史用法，并非临床试验。
human_clinical	一篇经 PubMed 引用的论文，HERB 分配的“Experiment type”包含“Clinical Experiment”——研究对象为人类。
laboratory	一篇经 PubMed 引用的论文，仅研究细胞或动物。
computational_prediction	统计富集或数据库交叉引用，没有临床或实验确认。这是一种假设，并非该草药／成分具有任何治疗作用的证据。
compositional_fact	“该成分存在于该草药中”——这是成分事实，完全不是疗效主张。

herb_target／herb_disease（包含 p-value 和 FDR_BH 列的统计富集）、ingredient_target／ingredient_disease／target_disease（没有临床依据的整理性交叉引用），以及每条 herb_experiment_detail 记录，均属于 computational_prediction。 drug_paper_target／drug_paper_disease（经 PubMed 引用）则根据每篇所引论文自身的“Experiment type”划分为 human_clinical 或 laboratory——具体方法请参阅下文的数据来源。

身份验证

无需密钥。herb.ac.cn 无需账号、令牌或付费；其公开数据向所有人提供。

数据源

• http://herb.ac.cn/chedi/api/ — herb.ac.cn 是一个 umi 单页应用，没有 REST 接口（所有路径都返回相同的约 900 字节外壳）。真正的 API 是这个 POST 端点，通过请求体中的 func_name 字段进行分发；该字段是在网站自己的 JS bundle（http://herb.ac.cn/static/umi.js）中发现的。已于 2026-09-08 确认的七个动词：search_api、detail_api、browse_api、paper_api、paper_detail_api、experiment_api、experiment_detail_api。

给接手者的备注：

• 仅支持 http，且托管在中国 — 本次会话中测得每次调用耗时 200 毫秒至 1.5 秒，但请预期会有延迟和偶尔无法访问的情况；从我们的角度来看，多个 .cn 数据源都已知不稳定。这是已知情况，不是 bug — 请报告问题，不要频繁重试。
• 每个响应都以 text/html 提供，包括成功响应 — 不要根据 Content-Type 进行分支判断。判断“没有此 ID”的唯一可靠信号是 HTTP 状态：错误的 key_id/label/paper_key_id/drug_GSE_id 会返回 HTTP 500，并附带 HTML“Internal Server Error”页面；未知的 func_name 会返回 HTTP 200，正文为字面值 null。 @pipeworx/shared 中的 parseJson/httpError 可以处理这两种情况。
• 所有表格中的单元格要么是普通值，要么是 {link, title} / {style, title} — 差异表达表格中的表头单元格也采用这种形式（{filterable, sortable, title}）。src/index.ts 中的 tableToRows 会将所有形式解包为普通字符串/数字。
• detail_api 需要 三个参数，而不只是 ID：key_id、label（必须与 ID 的类别一致 — HERB… ID 需要 label: "Herb" 等）以及 v（网站自己的 UI 会以这个名称再次传入 ID；省略该参数未经过测试，也不值得冒险）。
• drug_paper_target/drug_paper_disease 行（位于 herb_detail 中）带有论文 ID，但不包含该论文自身的实验类型；被引用的草药可能关联 20 到 100 多篇论文。herb_detail 不会针对每篇论文单独调用一次 paper_detail_api（这会对响应缓慢的主机造成不礼貌的多路请求），而是额外调用一次不带过滤条件的 paper_api — 它会返回 HERB 的完整参考索引，约 2,000 行，其中包含每个 ID 的“Experiment type”，然后通过内存查找来确定对应类别。工具调用之间不会缓存任何结果；每次 herb_detail 需要这些数据时，都会实时重新获取。
• Ingredient_alias（位于成分的 detail_api 响应中）不是表格 — 它是一个单元素数组，其中包含一个由分号连接的同义词字符串。将其当作表格处理会引发错误（table[0].map is not a function）；请改用 ; 分割。
• experiment_detail_api 的 Experiment_detail 字段比预期多嵌套一层：它是一个仅含一个键的对象，键名为“HBEXP000001 Data Detail”（实验 ID 加固定后缀），其值为 { data: {...} }。差异表达/GO/KEGG/CMAP 表格都位于该唯一值的 data 字段下 — src/index.ts 使用 Object.values(...)[0]?.data 获取它，而不是拼接键名，因为任何地方都没有记录确切的后缀。
• paper_api 和 experiment_api 不支持服务器端分页 — 每次调用都会在单个响应中返回完整的筛选结果列表（不带筛选条件时约 2,000 篇论文 / 约 1,000 个实验）。herb_papers/herb_experiments 在客户端使用 limit/offset 进行切片；更具体的 drug_type/experiment_type 筛选条件可以减少 herb.ac.cn 自身需要计算并发送的数据。
• 许可：已由 Bruce 于 fleet #1389（2026-09-08）确认 — 按请求实时进行代理调用属于客户端，而非发布者，因此无需像批量复制数据集那样获得明确的再利用许可。此 pack 必须保持为代理：不得批量下载、不得创建完整的本地镜像，也不得缓存 herb.ac.cn 数据的完整副本。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "herb-tcm": {
      "url": "https://gateway.pipeworx.io/herb-tcm/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/herb-tcm/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall，以及网关范围内的其他工具。因此，你看到的工具数量会多于此表中的数量：单个工具包端点目前会列出大约 30 个共享工具，以及该工具包自身的工具。连接的 initialize 响应会说明其确切范围，也是当天情况的权威答案。

这是有意为之，并非意外复用。元工具可以让限定范围的连接回答此工具包未涵盖的问题——通过 ask_pipeworx 在整个目录中路由——无需添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义耗费的上下文超过路由带来的价值，请改为连接一次完整网关，而不是连接多个工具包端点。

也可以连接完整的 Pipeworx 网关，直接列出每个工具包的工具，而不只是此工具包的工具：

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

两个 URL 都连接到同一个网关和相同的 1881+ 个数据源。唯一的区别是直接列出哪个工具包的工具；无论连接哪个端点，ask_pipeworx 都能访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/herb_tcm_herb_search \
  -H 'Content-Type: application/json' \
  -d '{"keyword":"banlangen","category":"herb"}'

首次调用无需账户。检查任意工具：GET https://gateway.pipeworx.io/v1/tools/herb_tcm_herb_search。查找工具：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账户）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账户，也无需通过网关往返：

{
  "mcpServers": {
    "herb-tcm": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-herb-tcm"]
    }
  }
}

也可以直接运行，以确认它能正常启动：

npx -y @pipeworx/mcp-herb-tcm

它通过 stdin/stdout 使用 MCP 通信，并针对仅此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。使用相同的源代码和工具，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗的英语提问，而不是直接调用工具——此方式既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Herb Tcm data" })

网关会自动选择合适的工具并填入参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT