mcpField
N
NeKo Biological Network Builder

NeKo Biological Network Builder

ローカル
github.com/marcorusc科学・教育20今日更新

NeKo Biological Network Builder について

NeKo Biological Network Builderは、生物シグナルネットワークの構築と整理を行う研究者向けMCPサーバーです。パスウェイデータベースやSIFファイルからネットワークを作成し、分岐するトポロジー履歴を保持しながら、連結性分析やMaBoSSへの検証付き受け渡しを支援します。

主な機能

  1. 01OmniPathまたはSIGNORからネットワークを構築
  2. 02SIFネットワークの読み込みと整理
  3. 03相互作用の絞り込みと経路検索
  4. 04連結成分の分析と修復案の確認
  5. 05分岐履歴の移動と状態比較
  6. 06BNETおよびMaBoSS向けハンドオフの出力

活用シーン

  1. 01シード遺伝子からシグナルネットワークを構築
  2. 02孤立ノードと連結成分の確認
  3. 03トポロジー編集前後の状態比較
  4. 04シミュレーション用ネットワークをMaBoSSへ受け渡し

MCP 対応

MCPクライアントにネットワークの構築、編集、分析、履歴管理、出力ツールを提供します。MaBoSS MCPサーバーで取り込める、整合性保護付きのNeKo-to-MaBoSSハンドオフを作成できます。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"marcorusc-neko": {
"command": "uvx",
"args": [
"mcp-biomodelling-servers"
]
}
}
}
起動コマンドuvx mcp-biomodelling-servers

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
pypimcp-biomodelling-servers2.5.2

ツール

22

掲載時のツール一覧 · 今日に更新

パラメーター型必須説明
labelanyいいえ任意の人間が読み取れるモデルラベル。
set_as_defaultbooleanいいえ作成したセッションをアクティブなデフォルトに設定します。

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

NeKo MCP サーバー

NeKo サーバーは、Model Context Protocol(MCP)を通じてシグナル伝達ネットワークを構築、キュレーション、分析、エクスポートします。 NeKo を使用して、キュレーション済みの相互作用データベースまたは既存の SIF ファイルからネットワークを構築し、トポロジーの変更を NeKo ネイティブの分岐履歴に保持します。

このサーバーは Python パッケージ mcp-biomodelling-servers として配布され、stdio 経由で通信します。型付きで整合性が保護されたハンドオフにより、完成した NeKo ネットワークを MaBoSS MCP サーバーに渡します。

インストールと起動

3 つのバイオモデリングサーバーをすべてインストールします。

python -m pip install mcp-biomodelling-servers

インストールした NeKo サーバーを起動します。

mcp-neko-server

または、隔離された環境で実行します。

uvx --from mcp-biomodelling-servers mcp-neko-server

分岐履歴リソースのレンダリングには、外部の Graphviz dot 実行ファイルが必要です。Graphviz のセットアップ、サポート対象の Python バージョン、完全な MCP クライアント設定、ソースチェックアウトの手順については、リポジトリの README を参照してください。

セッションとネットワーク状態

モデリング仮説ごとに、専用の NeKo セッションを使用してください。create_session() で開始し、返された session_id を保持して、以降の呼び出しに明示的に渡します。新しく作成したセッションは自動的にデフォルトとして選択されません。以降の呼び出しで ID を省略できるようにするには、set_default_session() を呼び出してください。

{
  "label": "TP53-MYC resistance network"
}
  • list_sessions は、アクティブなインメモリセッション、ネットワークの規模、現在のデフォルト、履歴保持の設定を報告します。
  • list_artifact_sessions は、現在または以前のサーバープロセスによってエクスポートされたファイルを検出します。
  • status は、1 つのセッションのノード数と相互作用数を返します。
  • reset_network は、セッションとその設定を保持したまま、現在のネットワークを破棄します。
  • delete_session は、インメモリセッションを完全に削除します。

set_default_params() は、完了処理のデフォルト値をセッションごとに保存します。プレビューとグローバルな完了処理ではすべてのデフォルト値が再利用されます。add_nodes(autoconnect=true) では、符号とコンセンサスのフィルターが再利用されます。

推奨ワークフロー

データベースを使用してネットワークを構築する場合は、次の順序で進めてください。

  1. create_session() を呼び出し、ID を保持します。
  2. 必要に応じて、set_default_params() で再利用可能な接続設定を構成します。
  3. create_network(...) でネットワークを構築します。
  4. remove_bimodal_interactions() で曖昧なエッジをキュレーションし、適切な場合は remove_undefined_interactions() も実行します。
  5. analyze_connectivity() で接続性を確認します(孤立ノードと完全な連結成分の分類)。
  6. 修復が必要な場合は、変更を伴う接続戦略を選択する前に preview_connection_impact() を呼び出します。
  7. 結果のトポロジーとエビデンスを調べます。
  8. 履歴ツールを使用して、新しい状態を以前の候補と比較します。
  9. export_neko_handoff(...) で整合性が保護された MaBoSS ハンドオフをエクスポートします。

反復的な構築中は、verbosity="summary" を推奨します。実際のノード、相互作用、パス、またはエビデンスが必要な場合にのみ、preview または full を使用してください。

ネットワークの構築

create_network() は、次の 2 つのキュレーション済みデータベースバックエンドに対応しています。

  • omnipath(デフォルト)
  • signor

シード遺伝子からネットワークを作成します。

{
  "list_of_initial_genes": ["EGFR", "KRAS", "TP53", "AKT1"],
  "database": "omnipath",
  "max_len": 2,
  "path_policy": "one_shortest",
  "reuse_policy": "discovered_paths",
  "only_signed": true,
  "consensus": true,
  "session_id": "SESSION_ID",
  "verbosity": "summary"
}

構築パラメーターは次のとおりです。

パラメーター説明
max_len最大パス長。1 ~ 4 の範囲です
path_policyone_shortest、all_shortest、または all_bounded
reuse_policynone、discovered_paths、または induced_subgraph
only_signedtrue の場合、符号付き相互作用のみを保持します
consensustrue の場合、複数のキュレーション済みソースからの支持を必須とします
verbositysummary、preview、または full

構築時に外部の生物学的データベースをクエリする場合があり、数分かかることがあります。データベースのリソースとネットワークの準備中、ツールは MCP の進捗状況を報告します。

代わりに既存の SIF を使用することもできます。

{
  "list_of_initial_genes": [],
  "sif_file": "/absolute/path/input.sif",
  "database": "omnipath",
  "session_id": "SESSION_ID",
  "verbosity": "summary"
}

sif_file と併せて、追加のシード遺伝子を指定できます。正常に完了できない呼び出しによって、セッションにすでに保存されている有効なネットワークが置き換えられることはありません。

トポロジーの編集とキュレーション

ノードと相互作用の追加または削除
  • add_nodes は1回の呼び出しで1つ以上の遺伝子を追加し、デフォルトでは、新しい各遺伝子をネットワーク内の既存の直接の隣接ノードに自動接続します(低コスト。複数ステップの経路は検索しません)。スキップするには autoconnect=false を設定します。
  • remove_gene はノードと、接続されているすべてのエッジを削除します。
  • remove_interaction は指定された有向エッジのみを削除します。

破壊的な編集を行う前に、現在のネットワークを確認してください。

{
  "session_id": "SESSION_ID",
  "verbosity": "preview",
  "max_rows": 50
}

list_genes_and_interactions を呼び出します。

遺伝子シンボルは、確認ツールが返す識別子と一致させてください。 remove_interaction(node_A, node_B) は node_A → node_B を削除します。逆方向のエッジは削除しません。

相互作用の符号をキュレーションする
  • remove_bimodal_interactions は、活性化と阻害の両方として報告されたエッジを削除します。
  • remove_undefined_interactions は、ブール型の活性化または阻害に対応付けられない効果を持つエッジを削除します。

これらの操作により、その後の BNET エクスポートは簡素化されますが、科学的なトポロジーは変更されます。適用後は、影響を受けたネットワークとその履歴を確認してください。

トポロジーとエビデンスの確認

このサーバーでは、簡潔なテキスト形式と JSON ネイティブの構造化結果の両方を利用できます。

  • list_genes_and_interactions は、ノードと有向相互作用のレコードを返します。
  • filter_interactions は、ネットワークを変更せずに、効果、ソース、またはターゲットで絞り込みます。
  • find_paths は、上限のある長さまでの2つの遺伝子間の有向経路を報告します。
  • get_references は、1つまたは2つの遺伝子が関与する相互作用の文献エビデンスを返します。
  • status は現在の次元を報告します。

たとえば、アポトーシスをターゲットとする阻害エッジを確認します。

{
  "effect": ["inhibition"],
  "target": "Apoptosis",
  "session_id": "SESSION_ID",
  "verbosity": "preview",
  "format": "markdown",
  "max_rows": 50
}

filter_interactions(format="json") は、モデルが読み取り可能なテキスト形式を変更します。ツールの構造化結果は、それとは独立して引き続き利用できます。

接続性の監査と修復

analyze_connectivity() は、孤立ノード(接続エッジのないノード)と、ネットワークの連結成分の完全な分割を報告します。BNET または引き継ぎ用にエクスポートする前に使用してください。

変更候補を調査する

preview_connection_impact() は、アクティブなネットワークを変更せずに、修復の方向性候補を評価します。

方法結果
hubs修復の方向付けに役立つ可能性がある、高次数の遺伝子を順位付けします
relax_max_len保存されている最大経路長を増やす処理をシミュレートします
unsigned符号なし相互作用を許可する処理をシミュレートします

例:

{
  "method": "relax_max_len",
  "session_id": "SESSION_ID",
  "verbosity": "preview",
  "format": "markdown"
}

シミュレーション方法はコピー上で動作します。予測された変更はセッションに反映されません。

選択した戦略を適用する

研究課題に合ったトポロジーと経路/再利用ポリシーを選ぶには、NeKo の簡潔な 接続戦略ガイド を参照してください。

bridge_components() は、指定した2つのグループを接続します。

{
  "comp_a": ["EGFR", "KRAS"],
  "comp_b": ["TP53", "BAX"],
  "max_len": 2,
  "mode": "OUT",
  "only_signed": true,
  "consensus": true,
  "session_id": "SESSION_ID"
}

comp_a/comp_b には遺伝子シンボルを指定する必要があります(たとえば、analyze_connectivity() の出力にあるコンポーネントの nodes リストから取得します)。数値の component_id は指定できません。analyze_connectivity() が各コンポーネントについて報告するこの ID は、レポート上のラベルであり、有効な遺伝子名ではありません。

mode は OUT、IN、または ALL です。

connect_targeted_nodes() は以下をサポートします。

  • connect_to_upstream_nodes;
  • connect_subgroup。

apply_global_connection() は以下をサポートします。

  • complete_connection。明示的な path_policy と reuse_policy を指定します。
  • connect_network_radially。direction="OUT" または "IN" を指定します。
  • connect_as_atopo。strategy_mode="radial" または "complete" を指定し、トポロジーのアンカーとして遺伝子シンボルの outputs リストを任意で指定できます。この戦略は、ネットワークが宣言されたすべての出力に接続されるまでループするため、大規模なネットワークではコストに上限がありません。

データベースを利用する接続ツールは、実行コストが高くなる場合があります。complete_connection はすべてのノードペアに対して O(N^2) であり、connect_as_atopo のコストには上限がありません。選択した各戦略の実行後に、コンポーネントを再確認し、履歴の状態を比較してください。

分岐するネットワーク履歴

NeKo は、対応するトポロジー変更操作のスナップショットを自動的に記録します。MCP サーバーはこのネイティブ履歴を直接公開するため、元に戻す、やり直す、チェックアウトする、比較するといった操作でも、NeKo のネットワーク状態が正確に保持されます。

状態を一覧表示する

list_network_history() は以下を返します。

  • 正確な現在の状態 ID
  • 保持されている状態 ID
  • 親子関係
  • 各状態のノード数とエッジ数
  • 設定された保持上限

状態 ID は識別子であり、リスト内の位置ではありません。移動や比較の前に、必ず list_network_history() から取得してください。

移動する

単一の navigate_network_history() ツールを使用します。

{
  "action": "checkout",
  "state_id": 3,
  "session_id": "SESSION_ID"
}

対応している操作は次のとおりです。

操作state_id の動作
undo親へ移動します。state_id は省略する必要があります
redo子へ移動します。曖昧さのない子が 1 つの場合、ID は省略できます
checkout保存済みの指定状態へ移動します。state_id が必須です

移動しても、ほかの保存済み状態は削除されません。古い状態をチェックアウトしてから変更すると、NeKo は以前の未来の状態を保持し、新しいトポロジーを別のブランチに記録します。

移動せずに比較する

compare_network_states(state_a, state_b) は、現在チェックアウトされている状態を変更せずに、追加および削除されたノードと相互作用を報告します。

{
  "state_a": 2,
  "state_b": 5,
  "session_id": "SESSION_ID"
}
保持を設定する

set_network_history_limit(max_states) は、セッションごとのポリシーを設定します。

  • null は無制限の履歴を保持します
  • 整数は 2 以上でなければなりません
  • 構築前に設定したポリシーは、ネットワーク作成時に適用されます
  • 上限を引き下げると、古いスナップショットが即座に、かつ取り消し不能な形で削除される場合があります

上限を引き下げる前に list_network_history() を呼び出してください。

履歴をレンダリングする

以下を読み取ります。

neko://session/{session_id}/history

これにより、NeKo のインライン SVG 履歴図を含む読み取り専用の HTML が取得できます。このリソースはチェックアウトされている状態を変更しません。レンダリングには Graphviz の dot 実行ファイルが必要です。見つからない場合、リソースは対処方法を示すレンダリングエラーを返します。

エクスポートと MaBoSS への受け渡し

単独エクスポート

export_network(format="sif") は、単独で使用できるタブ区切りの相互作用ネットワークを書き出します。export_network(format="bnet") は、MaBoSS 用のブールモデルを書き出します。

BNET のエクスポートには、連結したネットワークが 1 つ必要です。ブール規則で無効な名前を正規化し、名前が変更されたノードと、識別子の正規化後に削除された重複規則を報告します。list_bnet_files() を使用すると、セッション内の BNET アーティファクトを確認できます。

検証済みの NeKo から MaBoSS への転送

次の手順が MaBoSS MCP サーバーでのシミュレーションの場合は、export_neko_handoff() を使用してください。

{
  "biological_context": "EGFR-driven survival and apoptosis decision",
  "output_nodes": ["Apoptosis", "Proliferation"],
  "artifact_prefix": "egfr_decision_v1",
  "session_id": "SESSION_ID"
}

この転送では、以下が行われます。

  • 連結したネットワークと空でない biological_context が必要です
  • サニタイズ済みの BNET と、バージョン管理された JSON マニフェストを書き出します
  • 正確なブールノード、宣言された出力、ノード名の変更、削除された重複、パッケージのバージョン、セッションの来歴、現在の NeKo 履歴状態を記録します
  • 両方のファイルをアーティファクトの整合性メタデータで保護します
  • 指定された元の NeKo 出力名を、対応する正確なサニタイズ済み BNET 名に変換します
  • 既存のアーティファクトのペアへの上書きを拒否します

保持する転送ごとに、新しい artifact_prefix を選択してください。output_nodes は省略できますが、その場合、MaBoSS でシミュレーションを実行する前に小さな出力セットを選択する必要があります。

返されたマニフェストのパスを MaBoSS の import_neko_handoff() に渡してください。代わりに、単独の BNET パスを MaBoSS の bnet_to_bnd_and_cfg() に渡すこともできますが、この方法では型付きの科学的コンテキストと来歴マニフェストは保持されません。

ツールリファレンス

カテゴリツール
セッションcreate_session, list_sessions, list_artifact_sessions, set_default_session, status, reset_network, delete_session
構築と編集create_network, set_default_params, add_nodes, remove_gene, remove_interaction
キュレーションremove_bimodal_interactions, remove_undefined_interactions
検査とエビデンスlist_genes_and_interactions, filter_interactions, find_paths, get_references, analyze_connectivity, analyze_gene_set
接続戦略preview_connection_impact, bridge_components, connect_targeted_nodes, apply_global_connection
分岐履歴list_network_history, navigate_network_history, compare_network_states, set_network_history_limit
エクスポートとアーティファクトexport_network, export_neko_handoff, list_bnet_files, clean_generated_files

リソースとプロンプト

名前または URI内容
docs://neko/agent_manual推奨されるエージェントのワークフローと運用ルール
neko://session/{session_id}/historyインライン SVG HTML 形式の分岐履歴
neko_workflow_promptMCP プロンプトとしての運用マニュアル

構造化出力とエラー

検査、セッション、履歴、エクスポート、ハンドオフの各ツールは、簡潔でモデルが読み取りやすいテキストに加えて、構造化された JSON ネイティブの結果を返します。これにより、MCP ホストは Markdown を解析することなく、正確なノード、相互作用、状態 ID、次元、パス、来歴、アーティファクトのメタデータを利用できます。

無効な識別子、前提条件の不足、未対応の戦略、データベース操作の失敗、接続されていないエクスポート、その他のモデリング上の失敗は、復旧方法の案内を伴う MCP ツールエラーとして返されます。引数を修正するか、指定された前提条件を実行して、同じセッションで再試行してください。

アーティファクトのクリーンアップ

clean_generated_files(session_id=...) は、選択したセッションのエクスポート済みアーティファクトを削除しますが、メモリ内のネットワークはリセットしません。この操作は破壊的です。再現性のために必要な SIF、BNET、またはハンドオフファイルは、実行前に保持してください。

ネットワーク状態とアーティファクトの両方を破棄する場合は、delete_session() を呼び出す前に、生成されたファイルをクリーンアップしてください。

参考資料

ODE 構築用ハンドオフをエクスポートする

export_biomass_handoff(biological_context, artifact_prefix="neko_to_biomass", session_id=...) は、ネットワーク JSON と整合性保護された neko-to-biomass マニフェストを書き出します。元のノード識別子、安定したエッジ ID、 すべての参照、および利用可能なメカニズム/データベース/コンテキスト列を保持します。同一の相互作用が重複している場合、参照リストは統合されます。 接続されていない相互作用と符号のない相互作用も、エビデンスのキュレーションに利用できます。

BioMASS の import_neko_handoff を使用してマニフェストをインポートします。呼び出し元のエージェントはその後、文献を読み、エビデンスまたは明示的な仮定を伴う反応を提案します。このエクスポートでは、速度則や速度論的パラメーターは割り当てられません。既存の export_neko_handoff は、引き続き MaBoSS 用のブールモデルをエクスポートします。

アーティファクトは、共有キャッシュルートまたは MCP_BIOMODELLING_ARTIFACT_ROOT にある NeKo/<session_id> 名前空間に保存されます。従来のパッケージ内アーティファクトも、その保存場所とともに一覧表示されます。ルート README のアーティファクト保存セクションを参照してください。

create_network は、SIF のインポートで任意の parent_manifest と derived_from を受け付けます。親マニフェストには、SIF エクスポートから生成された検証済みの .lineage.json を指定します。編集済みのコピーには、変更されていない親 SIF を特定するために derived_from が必要です。SIF/BNET エクスポートでは、ハンドオフの承認とは無関係に、同じ場所にある .lineage.json ファイルにソースハッシュが保持されます。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。