Herb Tcm

@pipeworx/herb-tcm

HERB 2.0 の中医薬ナレッジベースです。生薬、成分、遺伝子ターゲット、疾患、PubMed に引用された論文、GEO のトランスクリプトーム実験を、herb.ac.cn からリアルタイムにプロキシし、すべての関連行に evidence_tier タグを付けることで、統計的な予測が有効性の証明と誤認されないようにしています。

Pipeworx の一部です。AI エージェントを 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?) — 1 つの 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"]）を使うと、数千件の予測疾患データを取得せずに組成を取得できます。また、未知のセクション名は何も返さずに黙って処理するのではなく、明示的にエラーになります。detail_api にはサーバー側のページ分割がなく（上流への 1 回の呼び出しで、ページ分割に関係なくすべて返されます）、スライスを追加してもコストが増えず、レスポンスの形式によって呼び出し側が誤認しにくくなるため、sections のみを使う設計ではなく、クライアント側でスライスする方式を採用しました。小さな同義語リストである ingredient_alias はページ分割されません。
• herb_papers(drug_type?, experiment_type?, sort_by?, limit?, offset?) — PubMed に引用された文献のリストを取得します。各文献には human_clinical または laboratory のタグが付いています。
• herb_paper_detail(paper_id) — 1 件の文献について、書誌レコードと、報告されている具体的なターゲット／疾患を取得します。
• herb_experiments(drug_type?, species?, experiment_type?, limit?, offset?) — GEO に登録された、生薬／成分と対照を比較するトランスクリプトーム実験のリストを取得します。
• herb_experiment_detail(experiment_id) — 1 件の実験の差次的発現解析の結果を取得します。発現上昇／低下した上位の遺伝子、エンリッチメント解析で得られた 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 値と 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 は、リクエストボディの func_name フィールドで処理を振り分けるこの POST エンドポイントです。サイト独自の JS バンドル（http://herb.ac.cn/static/umi.js）で見つかりました。2026-09-08 に実際の動作を確認した7つの動詞は、search_api、detail_api、browse_api、paper_api、paper_detail_api、experiment_api、experiment_detail_api です。

次の担当者へのメモ：

• http のみで、中国のホストです。このセッションでは1回の呼び出しに200ms～1.5秒かかりましたが、遅延や断続的なアクセス不能が予想されます。こちらの環境からは、いくつかの .cn ソースで不安定さが確認されています。これは既知の種類の問題であり、バグではありません。何度もリトライするのではなく、報告してください。
• 成功した場合も含め、すべてのレスポンスは text/html として配信されます。Content-Type に基づいて処理を分岐しないでください。「該当する ID がない」ことを示す唯一の信頼できるシグナルは HTTP ステータスです。不正な key_id／label／paper_key_id／drug_GSE_id は、HTML の「Internal Server Error」ページとともに HTTP 500 を返します。不明な func_name は、本文がそのまま null の HTTP 200 を返します。@pipeworx/shared の parseJson／httpError がどちらの形式にも対応します。
• すべてのテーブルのセルは、単純な値か {link, title}／{style, title} のいずれかです。差次的発現テーブルのヘッダーセルでさえ、この形式（{filterable, sortable, title}）で返されます。src/index.ts の tableToRows は、すべての形式を単純な文字列／数値に展開します。
• detail_api には ID だけでなく、3つのパラメーターが必要です。key_id、label（ID のカテゴリと一致する必要があります。HERB… ID には label: "Herb" など）、および v です（サイトの UI は同じ名前で ID を再度渡します。省略した場合はテストしておらず、リスクを冒す価値はありません）。
• drug_paper_target／drug_paper_disease の行（herb_detail 内）には Paper ID は含まれていますが、その論文自体の実験タイプは含まれていません。また、引用されたハーブは20～100件以上の論文を参照する場合があります。低速なホストに対して論文ごとに paper_detail_api を呼び出すのは不適切なため、herb_detail は追加で1回だけ、フィルターなしの paper_api を呼び出します。これにより、各 ID の「Experiment type」を含む HERB の全参照インデックス（約2,000行）が返され、そのデータをメモリ上で検索して分類を解決します。ツール呼び出しをまたいだキャッシュは行われず、herb_detail が必要とするたびに毎回ライブで再取得します。
• （成分の detail_api レスポンス内の）Ingredient_alias はテーブルではありません。セミコロンで結合された同義語の文字列を1つだけ含む配列です。テーブルとして扱うと例外が発生します（table[0].map is not a function）。代わりに ; で分割してください。
• experiment_detail_api の Experiment_detail フィールドは、想定より1階層深くネストされています。キーがちょうど1つのオブジェクトで、そのキー名は「HBEXP000001 Data Detail」（実験 ID と固定の接尾辞）です。その値は { data: {...} } です。差次的発現／GO／KEGG／CMAP のテーブルは、その値の data フィールド内にあります。正確な接尾辞はどこにも記載されていないため、src/index.ts はキー文字列を組み立てるのではなく、Object.values(...)[0]?.data で取得します。
• paper_api と experiment_api にはサーバー側のページネーションがありません。各呼び出しで、フィルターに一致する全リスト（フィルターなしの場合、論文約2,000件／実験約1,000件）が1つのレスポンスで返されます。herb_papers／herb_experiments は limit／offset を使ってクライアント側で分割します。drug_type／experiment_type のフィルターをより絞り込むと、herb.ac.cn 自身が処理して送信するデータ量を減らせます。
• ライセンス：Bruce が fleet #1389（2026-09-08）で確認済みです。リクエストごとに実行するライブのプロキシ呼び出しはクライアントであり、データセットを一括コピーする場合とは異なり、明示的な再利用許可は不要です。このパックはプロキシとして維持する必要があります。一括ダウンロード、完全なローカルミラー、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":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を使います。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージは、ローカルの 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