mcpField
D
devtu-auto-discover-apis

devtu-auto-discover-apis

github.com/mims-harvard開発1.8k383 回インストール2 日前に更新
リポジトリ

devtu-auto-discover-apis について

ToolUniverse のライフサイエンス API 対応範囲を拡張・保守する開発者向けのワークフロー型スキルです。カバレッジ分析から API の発見、ツール作成、検証、統合までを案内し、各段階に人による承認を設けています。

主な機能

  1. 01ToolUniverse の対応範囲の分析
  2. 02ライフサイエンス API の検索と評価
  3. 03API ツールと設定の作成
  4. 04スキーマと統合テストの検証
  5. 05ブランチと Git PR の準備

活用シーン

  1. 01領域別の API 対応計画
  2. 02新しい API の ToolUniverse ツール化
  3. 03既存ツールの品質監査
  4. 04関連 API ツールの一括提出

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mims-harvard/tooluniverse --skill devtu-auto-discover-apis

インストール後、Claude Code で/devtu-auto-discover-apisを入力して読み込まれたか確認します。

同梱ファイルreferences/tool-templates.mdreferences/validation-guide.md

詳細

ライフサイエンス API の自動検出とツール作成

ライフサイエンス API を検出、作成、検証し、ToolUniverse に統合します。

4 段階のワークフロー

Gap Analysis → API Discovery → Tool Creation → Validation → Integration
     ↓              ↓               ↓              ↓            ↓
  Coverage      Web Search      devtu-create   devtu-fix    Git PR

検出、作成、検証、および PR の前に、人による承認ゲートを設けます。

フェーズ 1：検出とギャップ分析

1.1 現在のカバレッジを分析する

ToolUniverse を読み込み、ツールをドメイン別（ゲノミクス、プロテオミクス、創薬、臨床、オミクス、イメージング、文献、パスウェイ、システム生物学）に分類します。カテゴリごとの数を数えます。

1.2 ギャップのあるドメインを特定する
  • 重大なギャップ：カテゴリ内のツールが 5 個未満
  • 中程度のギャップ：ツールが 5～15 個あり、重要なサブカテゴリが不足
  • 新興のギャップ：まだ取り上げられていない新技術

よくあるギャップ：シングルセルゲノミクス、メタボロミクス、患者レジストリ、微生物ゲノミクス、マルチオミクス統合、合成生物学、毒性学。

1.3 API をウェブ検索する

ギャップのある各ドメインについて、複数のクエリを実行します。

  1. "[domain] API REST JSON" — API を直接検索
  2. "[domain] public database" — データベースを検索
  3. "[domain] API 2025 OR 2026" — 最近のリリースを検索
  4. "[domain] database" site:nar.oxfordjournals.org — NAR Database Issue を検索

抽出する情報：ベース URL、エンドポイント、認証方式、パラメーターのスキーマ、レート制限。

1.4 スコアを付け、優先順位を決める
基準最大ポイント
ドキュメントの品質20
API の安定性15
認証の簡便さ15
カバレッジ15
メンテナンス10
コミュニティ10
ライセンス10
レート制限5

優先度：高（>=70）、中（50-69）、低（<50）。

1.5 検出レポートを作成する

カバレッジ分析、スコア付きの優先候補、実装ロードマップをまとめます。

フェーズ 2：ツールの作成

各 API について、Skill(skill="devtu-create-tool") を使用するか、以下のパターンに従います。

アーキテクチャの決定
  • 複数のエンドポイント → 複数オペレーションのツール（単一クラス、複数の JSON ラッパー）
  • 単一のエンドポイント → 単一オペレーションでも可
主な手順
  1. テンプレートに従ってツールクラスを設計します — references/tool-templates.md を参照
  2. oneOf return_schema を含む JSON 設定を作成します
  3. 実際のテスト例を見つけます（List エンドポイントを使用 → ID を抽出 → 検証）
  4. default_config.py に登録します
重要な要件
  • return_schema は oneOf（成功スキーマとエラースキーマ）を必ず含める必要があります
  • test_examples では実在する ID を使用する必要があります（プレースホルダーは禁止）
  • ツール名は 55 文字以下にします
  • run() 内で例外を発生させないでください — エラー辞書を返します
  • すべての HTTP リクエストにタイムアウト（30s）を設定します

フェーズ 3：検証

詳細なガイド：references/validation-guide.md

簡易検証チェックリスト
  1. スキーマ：oneOf 構造、データラッパー、エラーフィールド
  2. プレースホルダー：test_examples に TEST/DUMMY/PLACEHOLDER が含まれていない
  3. 読み込み：3 段階の確認（クラスの登録、設定の登録、ラッパーの生成）
  4. 統合テスト：python scripts/test_new_tools.py [api_name] -v → 100% 合格

失敗を修正するには、Skill(skill="devtu-fix-tool") を使用します。

フェーズ 4：統合

Skill(skill="devtu-github") を使用するか、以下の手順に従います。

  1. ブランチを作成します：feature/add-[api-name]-tools
  2. ツールのファイルと default_config.py をステージングします
  3. 内容がわかるメッセージを付けてコミットします
  4. プッシュし、検証結果を添えて PR を作成します

処理パターン

パターン使用する場面
バッチ（複数の API → 1 つの PR）同じドメイン、似た構造
反復（一度に 1 つの API）複雑な認証、独自のパターン
検出のみ（レポート、ツールなし）ロードマップの策定
検証のみ（既存のものを監査）PR レビュー、品質チェック

参考資料

コメント

Markdown 対応