4da-mcp-server

@4da/mcp-server

AI コーディングエージェント向けのアップグレードインテリジェンスです。 エージェントが依存関係を更新する前に、現在のバージョンから希望するバージョンへの変更内容、影響を受けるファイル、更新によって修正される脆弱性を、手元のロックファイルからマシン上で確認できます。さらに、osv-scanner と同等の脆弱性スキャン、優先順位付きのアップグレード計画、判断の記録も利用できます。設定不要で、アカウントも不要です。

You:     "Upgrade axum to 0.8"
Agent →  upgrade_impact { package: "axum", to_version: "0.8.4" }

         axum 0.7.9 -> 0.8.4: 5 releases (0.8.2 yanked), changelog from the 0.8.4 crate.
         12 breaking entries, 8 touch your code (Path, Query, Router, extract, serve):
           breaking  Remove OptionalFromRequestParts impl for `Query`        (you use Query)
           breaking  Require `Sync` for all handlers added to `Router`       (you use Router)
           ...
         Your code: 10 files import axum.

(実際の出力を抜粋。2026-10-02 にこのリポジトリで実行。)

コマンド 1 つでインストールできます。API キーもアカウントも不要です。コードがマシンの外に出ることはありません。

インストール

Node.js 22 以降が必要です。

サーバーは Node 組み込みの node:sqlite（Node 22.13 以降）を使用するため、インストールスクリプトは不要で、デフォルトでスクリプトの実行をブロックする npm 12 でも動作します。Node 22.0-22.12 では、オプションの better-sqlite3 を使用します。このネイティブモジュールは npm 10 および 11 がインストール時にビルドします。npx @4da/mcp-server --doctor で使用中のものを確認できます。

claude mcp add 4da -- npx @4da/mcp-server

Claude Code プラグインとして（MCP サーバーとフック）：

claude plugin marketplace add 4DA-Systems/4da-mcp-server
claude plugin install 4da@4da

フックの動作：エージェントが package.json、Cargo.toml、pyproject.toml、requirements.txt、go.mod のいずれかで依存関係のバージョンを編集すると、更新されたパッケージが通知され、インストールとビルドの前に実行すべき dependency_check と upgrade_impact の正確な呼び出しが提示されます。フックは通常の Node で動作し、外部に接続せず、ほかの編集では何も表示しません。

{
  "mcpServers": {
    "4da": {
      "command": "npx",
      "args": ["@4da/mcp-server"]
    }
  }
}

{
  "servers": {
    "4da": {
      "type": "stdio",
      "command": "npx",
      "args": ["@4da/mcp-server"]
    }
  }
}

{
  "mcpServers": {
    "4da": {
      "command": "npx",
      "args": ["@4da/mcp-server"]
    }
  }
}

npx @4da/mcp-server --setup --dry-run   # show each file and entry, write nothing
npx @4da/mcp-server --setup

次のように AI に尋ねてください：「X を Y にアップグレードすると何が変わりますか？」、「脆弱性をスキャンしてください」、または 「最初に何をアップグレードすべきですか？」

仕組み

サーバーは、起動されたプロジェクト内にあるすべてのロックファイルを読み込みます。ルート以下に個別にロックされたプロジェクトがある場合も対象です（ルートの pnpm-lock.yaml と並んで src-tauri/Cargo.lock があるリポジトリ全体をスキャンします）。.gitignore で除外されるものはスキップします。対象は、package-lock.json／npm-shrinkwrap.json、pnpm-lock.yaml（v5～v9）、yarn.lock（v1 および berry）、bun.lock、Cargo.lock（Cargo ワークスペースを含む）、poetry.lock、uv.lock、pdm.lock、Pipfile.lock、requirements のピン指定（*requirements*.txt、requirements/*.txt。-r と -c を含む）、go.mod／go.sum（Go のビルドリスト）、Gemfile.lock（RubyGems。git および path の gem はリリースではなくローカルコードです）、composer.lock（Packagist）です。フォルダー内の Python ソースは、最初の 1 つだけでなくすべて読み込みます。名前ごとに 1 つのバージョンだけではなく、インストールされているコピーをすべてスキャンし、ロックファイル独自の dev フラグを使用します。ロックファイルが変更されるたびに再読み込みし、npm では node_modules に実際に存在する内容も確認します。走査範囲は深さ 4 レベル、最大 256 プロジェクトです。対象から除外されたものと、ロックファイルのないすべてのマニフェスト（宣言された範囲はインストール済みのものではないため、スキャンされません）は、黙って除外せず、回答の coverage ブロックに記載します。読み取り対象外のエコシステムのマニフェスト（Maven の pom.xml、Gradle、.NET の *.csproj／packages.lock.json、Pub、Hex、SwiftPM、CocoaPods。coverage.not_covered）、存在するものの読み取れないロックファイル（マージコンフリクトマーカー、不正な JSON。coverage.unreadable_lockfiles）、テストフィクスチャのディレクトリ（tests/、test/、fixtures/、testdata/、__fixtures__/、conformance/ など）配下にあるロックファイルも同様です。これらは include_test_fixtures: true を渡さない限り、プロジェクト自体のものとしてスキャンされません（coverage.not_scanned）。

不完全な回答が、問題なしと判定されることはありません。 OSV.dev が一部の依存関係について回答できない場合（サービス停止、HTTP エラー、タイムアウト、クエリ予算の超過）、vulnerability_scan は summary: "NOT CHECKED: ... N of M dependencies have no vulnerability answer" で始まり、それらを coverage.unchecked_dependencies に計上し、total_vulnerable_packages と by_severity を null に設定します（チェック済みの依存関係で見つかった内容は found_in_checked_dependencies に記載されます）。dependency_health はスコアと脆弱な依存関係の数を保留し、upgrade_planner は vulnerabilityDataAvailable: false を設定します。大規模なツリーは、OSV の予算の範囲内で 1,000 件ずつバッチ処理するため、依存関係が 10,000 件を超えるツリーもすべて回答します。

公的な 19 のリポジトリ（npm、pnpm v5～v9、yarn v1 および berry、bun、Cargo、Poetry、uv、Pipfile、requirements、Go。2026-10-10）で osv-scanner と比較した結果、すべての差異は OSV 独自の API によって解決されました。読み取り対象のロックファイルでは、19,115 件の検出結果に対する適合率は 1.00、再現率は 19,116 件中 19,115 件でした（Maven／Gradle は読み取りません）。新たに読み取り対象となった requirements ファイルも pip-audit と照合しました。

• 既知の脆弱性についてはOSV.devを利用し、インストール済みのバージョンと正確に照合します
• バージョン、非推奨化、公開取り下げの確認には、npm registry、crates.io、PyPI、Go module proxy（registry.npmjs.org、crates.ioとindex.crates.io、pypi.org、proxy.golang.org）を利用します
• dependency_healthの週間ダウンロード数には、npmのダウンロード数（api.npmjs.org）を利用します
• upgrade_impactが読み取る変更履歴には、パッケージ独自のレジストリアーカイブ（registry.npmjs.org、static.crates.io、files.pythonhosted.org、proxy.golang.org）を利用します。GitHubを利用するのは、以下のFOURDA_GITHUB_CHANGELOG=trueをオプトインした場合のみです
• dependency_checkでは、npmの完全なpackument、crates.ioのversions API、PyPI JSON API、Go proxyのバージョン一覧を利用します（公開日時、公開取り下げ、撤回。npmとcrates.ioでは、さらに公開者、インストールスクリプト、バージョンごとの依存関係も確認します）。これらのリクエストで送信されるのはパッケージ名のみです。インストール済みのバージョンがレジストリに送信されることはありません。ただし、Go proxyの一覧には日付がないため、判定対象のバージョンの.infoを問い合わせます（go getが行うのと同じリクエストです）。パッケージのOSV.devアドバイザリ一覧を使って、dependency_checkは制約内で安全なリリースを提示します。packumentはディスクにキャッシュされ、If-None-Matchで再検証されます。crates.io APIへのリクエストは1秒に1回に制限されます。
• Hacker News Algolia API（hn.algolia.com）は、ecosystem_pulseを呼び出した場合のみ利用します
• GitHub（api.github.com、raw.githubusercontent.com）は、FOURDA_GITHUB_CHANGELOG=trueの場合のみ利用します
• 埋め込みプロバイダーは、セマンティック検索用に設定した場合のみ利用します（ローカルのOllama URLまたはapi.openai.com。以下を参照）

サーバーが接続するホストは以上です。

結果はキャッシュされます（レジストリデータは24時間、脆弱性情報は1時間、ニュースは30分）。また、ソースごとにリクエスト数が制限されます。

**ネットワーク経由で送信される情報：**パッケージ名とバージョン（ロックファイルで確認できるものと同じ情報）と、ecosystem_pulseの場合に限り、検索語として使用する依存関係の名前がいくつか送信されます。ソースコード、ファイルパス、個人情報は送信されません。upgrade_impactの呼び出し箇所のスキャンはローカルで実行されます。FOURDA_OFFLINE=trueを設定すると、すべてのネットワーク通信が無効になります。

**GitHubのリリースノート（オプトイン、デフォルトでは無効）。**多くのパッケージは、レジストリアーカイブに変更履歴を含めていません（vite、zod、cobra、ほとんどのGoモジュールなど）。サーバーの環境でFOURDA_GITHUB_CHANGELOG=trueを設定すると、対象範囲の変更履歴がアーカイブにない場合、upgrade_impactはリポジトリのGitHubリリースを読み取ります（PyPIの場合は、まずプロジェクトのproject_urlsからGitHub上にリンクされた変更履歴ファイルを確認します）。その場合、GitHubに送信されるのはリポジトリ名とバージョンのみで、それ以外の情報は送信されません。認証なしのREST API（1時間あたり60件）を使用します。GITHUB_TOKENが設定されている場合は、それを使用します（1時間あたり5,000件）。レート制限に達した場合はリセット時刻を通知し、ループ内で再試行することはありません。また、結果はキャッシュされます。無効の場合、変更履歴がないときはその旨と設定名が回答され、推測による情報は提示されません。

**ディスクに書き込まれる情報と保存場所：**サーバーが所有するファイルのみが、ユーザーデータディレクトリ内のサーバー用フォルダーに保存されます（%LOCALAPPDATA%\4da-mcp、~/Library/Application Support/4da-mcp、または~/.local/share/4da-mcp。FOURDA_MCP_HOMEで保存先を変更できます）。cache.db（レジストリ、OSV、変更履歴の応答。削除しても問題ありません）と、デスクトップアプリを使用しない場合はstandalone.db（プロジェクトのスキャン結果、記録した判断、エージェントのメモリ、フィードバック）が保存されます。リポジトリ内には何も書き込まれません。 4DA デスクトップアプリがインストールされている場合、サーバーは読み取り専用の接続を通じてアプリのデータベース（4da.db）を読み取り、データベース内にテーブル、列、キャッシュを作成・変更することはありません。書き込みを行うのは、ツールが値を入力するために用意されているアプリ所有の4つのテーブルへの行の追加だけです。アプリは追加された内容を認識します。対象は、決定事項（decision_memory -> developer_decisions）、エージェントメモリ（agent_memory）、フィードバック（record_feedback -> interactions と feedback。これらはアプリのキャリブレーションで読み取られます）です。これらの書き込みには、アプリによるロックが解除されるまで少し待機する別の書き込み接続を使用します。アプリのバージョンに、そのレコードに必要なテーブルや列がない場合、レコードは代わりに standalone.db に保存され、レスポンスの _meta でその旨が通知されます。（6.1より前のバージョンでは、サーバーはアプリのデータベース内にも live_cache テーブルを作成していましたが、現在はそのキャッシュを cache.db に保存します。）

設定とデータベースの取得元： FOURDA_DB_PATH が設定されている場合はそのパスを使用します（相対パスはサーバーの作業ディレクトリを基準に解決され、既存のファイルを指定する必要があります。ファイルが存在しない絶対パスの場合、そのディレクトリが存在すれば新しいスタンドアロンデータベースとして作成され、最初のツールの応答で _meta.database_note にその旨が通知されます。それ以外の場合はエラーとなり、使用は拒否されます）。設定されていない場合は、デスクトップアプリのデータディレクトリにあるデータベースを使用し、それもない場合はサーバー自身の standalone.db を使用します。埋め込み設定は、FOURDA_SETTINGS_PATH、FOURDA_DB_PATH と同じ場所にある settings.json、デスクトップアプリのデータディレクトリの順に取得します。サーバーの起動ディレクトリから設定やデータベースを取得することはありません。6.2.5より前は、作業ディレクトリ内（またはその隣）にある data/settings.json や data/4da.db が採用されていたため、クローンしたリポジトリによってセマンティック検索の参照先が任意のホストに変更されたり、「決定事項」が仕込まれたりする可能性がありました。

例外は1つです。セマンティック検索でOpenAIの埋め込みプロバイダー（FOURDA_EMBED_PROVIDER=openai）を明示的に設定した場合、保存する決定事項やメモリのテキストは、埋め込み生成のためにOpenAIへ送信されます。デフォルト設定（埋め込みプロバイダーを指定しない場合、またはローカルのOllamaを使用する場合）では、すべてのデータがマシン上に保持されます。また、FOURDA_OFFLINE=true を設定すると、どの設定よりも優先してオフラインで動作します。

サポート対象のエコシステム： npm、crates.io（Rust）、PyPI（Python）、Goに対応しています。vulnerability_scan は、RubyGems（Gemfile.lock）とPackagist（composer.lock）も読み取ります。Maven、Gradle、.NETは読み取られず、対象外として表示されます。upgrade_impact はnpm、crates.io、PyPI、Goを読み取ります。PyPIでは、バージョンと日付をPyPI JSON APIから、変更履歴をリリースのsdistから取得します。インポート箇所は、配布パッケージがインストールするモジュール名に基づいて照合します。仮想環境のメタデータ（.venv、venv、env にある top_level.txt または RECORD）があればそこから読み取り、なければ一般的な差異の一覧（PyYAML -> yaml、Pillow -> PIL）を使用し、それにも該当しない場合は配布パッケージ名を使用します。その場合、回答では推定であることが明示されます。Goでは、バージョンと日付をproxy.golang.orgから、変更履歴をモジュールのzipから取得します。また、メジャーバージョンが2以上の場合は、モジュールパスの変更として報告し（github.com/jackc/pgx/v4 -> /v5）、古いパスをインポートしているファイルも示します。dependency_check も4つすべてを読み取ります。PyPIとGoでは、レジストリが公開者の識別情報やインストールフックを公開していないため、これらのシグナルは「該当なし」と表示されます。 明記している既知の制限事項： ロックファイルのない requirements.txt に記載されるのは直接指定したピン留めバージョンだけなので、推移的な依存関係はスキャンされません（uv lock、poetry lock、または pip-compile を使用してください）。多くのパッケージはレジストリアーカイブに変更履歴を含めていません（fastembed、vite、zod など）。その場合、upgrade_impact は推測せず、その旨を伝えてリリースノートの URL を提示します。破壊的変更を含むエントリーは、変更履歴の見出しと文言に基づいてフラグ付けされ、各エントリーにはそのエントリーが属する見出し（under）が含まれます。npm、crates.io、PyPI、Go の実際のアップグレード 40 件で構成されるパネルで測定しました（1,618 件のエントリー。3 人の評価者によるブラインド評価と、原文のままの証拠に基づくゴールドデータです。パネルと測定方法はテストスイートに含まれています）。ルール作成に使用していない 20 件のアップグレードでは、破壊的変更としてフラグ付けされたエントリーの 95％が実際に破壊的変更でした（95％信頼区間 89～98％）。また、破壊的変更を含むエントリーの約 72％にフラグが付けられました。文章で書かれた Go のリリースノートが最も弱く、再現率は約 54％です。フラグは事前に並べ替えるための目安として扱い、メジャーアップグレードの全エントリーを読んでください。各回答の _meta.classification にもこの点が記載されています。

質問できること

"What changes if I upgrade axum to 0.8?"      -> upgrade_impact
"Check my dependency health"                  -> dependency_health
"Scan for vulnerabilities"                    -> vulnerability_scan
"Which deps should I upgrade first?"          -> upgrade_planner
"Is it safe to bump axios to 1.14.1?"         -> dependency_check
"Pin ws to a 7.x version"                     -> dependency_check (to: "7.x")
"I'm about to bump fastembed 5 -> 7"          -> what_should_i_know
"What's happening in the ecosystem?"          -> ecosystem_pulse
"What's my tech stack?"                       -> get_context
"Record a decision: we chose Postgres"        -> decision_memory
"Does switching to MySQL align?"              -> check_decision_alignment
"Remember: never use ORM for batch inserts"   -> agent_memory

16 種類のツール

依存関係のセキュリティ

インテリジェンス

決定とメモリー

ID

* すべてのデータを利用するには、4DA デスクトップアプリが必要です。

プロンプト：deps

ユーザーが呼び出すワークフローです（MCP プロンプトを表示するホストでは、スラッシュコマンドとして表示されます）。エージェントに対し、upgrade_planner を実行し、提案されたすべての更新を dependency_check で確認し、proceed の項目のみを少数ずつ適用して、各バッチの後にプロジェクト独自のテストを実行するよう指示します。また、根拠を示して review／avoid／wait／unknown の項目をすべて停止して報告し、最後に vulnerability_scan を再実行するよう指示します。省略可能な引数 scope（例：security only）。

スタンドアロンモードとフルモード

MCP サーバーはデスクトップアプリがなくても動作します。ユーザーデータフォルダー（%LOCALAPPDATA%\4da-mcp、~/Library/Application Support/4da-mcp、または ~/.local/share/4da-mcp。リポジトリ内には保存されません）に小規模なローカルデータベースを保持し、起動のたびにプロジェクトをスキャンします。

フル機能を利用するには4DA をダウンロードしてください。

トランスポート

stdio（デフォルト）— すべての MCP ホストで動作します：

npx @4da/mcp-server

Streamable HTTP — リモート環境や複数クライアントでの構成向けです：

npx @4da/mcp-server --http --port 4840

HTTP トランスポートはデフォルトで 127.0.0.1 にバインドされ、すべてのリクエストに対して Host ヘッダーの DNS リバインディング対策を適用します。このマシン以外に公開するには、共有シークレットが必要です：

MCP_AUTH_SECRET=<same value as the relay's JWT_SECRET> \
MCP_ALLOWED_HOSTS=mcp.internal \
  npx @4da/mcp-server --http --host 0.0.0.0

MCP_AUTH_SECRET がない場合、ループバック以外へのバインドは起動時に拒否されます。設定されている場合、 すべてのリクエストに、そのシークレットに対する HMAC-SHA256 署名が検証できる Bearer トークンが必要です。また、各ツールではトークンのロールが適用されます（viewer は読み取り専用、member と admin は書き込み可能です）。前段に TLS を配置してください。

HTTP モードはシングルテナントです。 トークンの team_id は検証されますが、データの分離には使われません。認証済みのすべてのクライアントが、1 つのデータベース、1 つのエージェントメモリ、1 組の判断を共有します。また、project_path により、認証済みのクライアントはサーバーが読み取れるホスト上の任意のディレクトリをスキャンできます。チームごと（または信頼境界ごと）にサーバーを 1 つ実行し、そのアクセスを許可できるクライアント経由でのみ利用してください。

CLI リファレンス

npx @4da/mcp-server              # Start server (stdio)
npx @4da/mcp-server --http       # Start server (Streamable HTTP)
npx @4da/mcp-server --setup      # Auto-configure your editors
npx @4da/mcp-server --doctor     # Verify installation health
npx @4da/mcp-server --version    # Print version

環境変数

よくある質問

コードがどこかに送信されますか？ いいえ。サーバーはパッケージ名とバージョンを公開 API（OSV.dev、npm registry、crates.io、PyPI、Go proxy）に送信し、upgrade_impact のためにパッケージ独自のレジストリから対象バージョンのアーカイブをダウンロードします（また、FOURDA_GITHUB_CHANGELOG=true に設定した場合に限り、GitHub のリリースノートを読み取ります）。さらに、ecosystem_pulse を呼び出した場合に限り、依存関係の名前をいくつか検索語句として HN Algolia に送信します。ソースコード、ファイルパス、個人データは送信されません。呼び出し箇所のスキャンはローカルで実行されます。すべてのネットワーク通信を無効にするには、FOURDA_OFFLINE=true に設定してください。（唯一の例外は、オプトイン方式の OpenAI 埋め込みです。上記のネットワークに関する注記をご覧ください。）

4DA デスクトップアプリは必要ですか？ いいえ。11 個のツールは単独で動作します。アップグレード影響分析、インストール前の依存関係チェック、脆弱性スキャン、依存関係の健全性チェック、アップグレード計画、エコシステムのニュース、タスク前のブリーフィング、プロジェクトコンテキスト、意思決定メモリー、アラインメントチェック、エージェントメモリーに対応しています。デスクトップアプリでは、同じエンジンを日常的に実行できます。マシン上のすべてのプロジェクトにまたがる作業リスト、スタックで何が変わったかをまとめた朝のブリーフ、アップグレード計画を利用できます。インストールすると、エージェントはさらに 5 つのツール（シグナル、ナレッジギャップ、スタックに照らして評価した開発者向けニュース、Developer DNA、フィードバック）も利用できるようになります。

どの AI ツールで使えますか？ MCP に対応するツールであれば、どれでも使えます。Claude Code、Claude Desktop、Cursor、Windsurf、VS Code（Copilot）、および任意のカスタム MCP クライアントに対応しています。

ソースからビルドする

git clone https://github.com/4DA-Systems/4da-mcp-server.git
cd 4da-mcp-server
pnpm install
pnpm build
pnpm test    # offline

ライセンス

Apache License 2.0（Apache-2.0）。LICENSE をご覧ください。

4DA が開発