dotnetdevmcp

DotNetDevMCP

AI コーディングエージェントに実用的な .NET ツールを提供する MCP サーバーです。Roslyn によるコードインテリジェンス、dotnet build／test、影響を受けるテストの選択、そしてこれらのツールを依存関係グラフとして並行実行するオーケストレーターを備えています。

.NET コードを扱うエージェントは、通常 grep と dotnet のシェル実行で作業します。そのため、シンボルではなくファイルを読み、構文ツリーではなくテキストを編集し、コマンドを一度に1つずつ実行します。DotNetDevMCP はこれを、既定で37個（以下のオプショングループを有効にすると53個）のツールに置き換えます。これらのツールは、ソリューションをコンパイラーの視点で扱い、ビルド、テスト、分析を並行して実行できます。

初めての方は、wikiに、最初のセッションのチュートリアル、各 MCP クライアントのセットアップ方法、トラブルシューティングが掲載されています。

インストール

.NET 10 SDK が必要です。

Claude Code

claude mcp add dotnetdevmcp -- dnx DotNetDevMCP --yes

VS Code / Visual Studio（.mcp.json または .vscode/mcp.json）

{
  "servers": {
    "dotnetdevmcp": {
      "type": "stdio",
      "command": "dnx",
      "args": ["DotNetDevMCP", "--yes"]
    }
  }
}

Claude Desktop / Cursor / 任意の stdio クライアント（mcpServers 形式）

{
  "mcpServers": {
    "dotnetdevmcp": {
      "command": "dnx",
      "args": ["DotNetDevMCP", "--yes", "--", "--load-solution", "C:/src/MyApp/MyApp.sln"]
    }
  }
}

初回実行時に dnx が NuGet.org からパッケージをダウンロードします。恒久的にインストールする場合は、dotnet tool install -g DotNetDevMCP を実行し、コマンドとして dotnetdevmcp を使用してください。

起動時に Roslyn でソリューションを読み込むには --load-solution <path> を渡します。必要になったときにエージェントから SharpTool_LoadSolution を呼び出させることもできます。--http --port 3001 を指定すると、stdio の代わりに Streamable HTTP で提供します（localhost のみ、認証なし：セキュリティを参照）。外部の Origin ヘッダーまたは localhost 以外の Host ヘッダーを含むリクエストは拒否されます。--allowed-origin <origin>（複数指定可）を使うと、この許可リストに追加のオリジンを登録できます。たとえば、Origin を転送するローカル開発サーバーのプロキシには --allowed-origin http://localhost:5173 を指定します。サーバーは CORS ヘッダーを送信しないため、これによってブラウザーページからサーバーへ直接アクセスできるようにはなりません。--clean-env を指定すると、dotnet と git を最小限の環境変数で起動し、環境変数に設定されたトークンやクラウド認証情報が渡されないようにします。すべてのオプションは dotnetdevmcp --help で確認できます。

Git とモニタリングのツール（下の表を参照）は既定で無効です。エージェントがすでに利用できるシェルで代用でき、登録するツールが増えるたびに、すべてのセッションでコンテキストトークンを消費するためです。--enable git,monitoring（カンマ区切りおよび／または繰り返し指定が可能。例：--enable git --enable monitoring）を渡すと、どちらか一方または両方を有効にできます。

既定では、Roslyn の編集ツール（SharpTool_RenameSymbol、OverwriteMember、AddMember、MoveMember、FindAndReplace、CreateRoslynDocument、OverwriteRoslynDocument、ManageUsings、ManageAttributes）は git に一切触れません。変更をディスクに適用し、通常のコンパイルチェック結果のみを返します。--git-commit-edits を指定すると、従来の動作を有効にできます。この場合、すでにそのブランチにいない限り、編集ごとに sharptools/<timestamp> ブランチが作成され、変更がコミットされます。これは SharpTool_Undo が変更を元に戻すためにも必要です。このフラグを指定しない場合、SharpTool_Undo は原因の分かりにくい失敗ではなく、説明付きのエラーを返します。（--disable-git は引き続き使用できますが、git 統合は既定でオプトインになったため、現在は何もしません。）

エージェントが利用できる機能

グループ	ツール	内容
コードインテリジェンス（Roslyn）	21	ソリューションの読み込み、定義の検索と表示、参照と実装の検索、メンバーの追加・上書き・移動・名前変更、using と属性の管理、構文を考慮した検索と置換、複雑度の分析、元に戻す。SharpTools からフォークしています。
テスト	3	dotnet_test_run（プロジェクトまたはソリューションごとに dotnet test を1回実行し、TRX を解析してメッセージとスタックトレースを含むテストごとの結果を出力）、dotnet_test_discover、dotnet_test_affected：Roslyn が変更されたファイルから参照をたどり、そのファイルに到達するテストメソッドを特定して、該当するテストのみを実行します。
ビルド	4	dotnet build、restore、clean、MSBuild プロパティを指定したビルド。構造化されたエラーと警告を出力します。
分析	5	プロジェクトの依存関係グラフ、循環依存の検出、品質メトリクス、古いパッケージのスキャン。
オーケストレーション	4	orchestrate_parallel はサーバー独自の任意のツールを並列実行し、execute_workflow はそれらを DAG として実行します。リソース制限とメトリクスに対応しています。
Git（オプトイン）	10	ステータス、ブランチ、チェックアウト、ステージング、コミット、差分、ログ、プッシュ、プル。--enable git で有効にします。
モニタリング（オプトイン）	6	プロセスのパフォーマンスメトリクス、GC 統計、リソース使用率、ヘルスチェック、プロファイリングセッション。--enable monitoring で有効にします。

このサーバーを接続したエージェントには、次のように指示できます。

• 「MyApp.sln を読み込み、IOrderRepository のすべての実装を検索して、ソリューション全体で GetById の名前を FindById に変更してください。」
• 「たった今の変更によって影響を受けるテストだけを実行し、スタックトレースとともに失敗を表示してください。」
• 「API プロジェクトとワーカープロジェクトを同時にビルドしてから、両方のテストプロジェクトを実行してください。」
• 「循環依存があるプロジェクトはどれですか？」

オーケストレーション

上記のツールは個別でも便利ですが、オーケストレーターを使うと高速になります。サーバー上の任意のツールを名前で指定し、1回の呼び出しで並列実行したり、依存関係グラフとして実行したりできます。

{
  "name": "execute_workflow",
  "arguments": {
    "workflowName": "ci",
    "steps": [
      { "name": "build-tests",  "toolName": "dotnet_build",    "arguments": { "projectPath": "tests/Api.Tests/Api.Tests.csproj" } },
      { "name": "build-worker", "toolName": "dotnet_build",    "arguments": { "projectPath": "src/Worker/Worker.csproj" } },
      { "name": "test-api",     "toolName": "dotnet_test_run", "arguments": { "path": "tests/Api.Tests/Api.Tests.csproj", "noBuild": true }, "dependsOn": ["build-tests"] },
      { "name": "deps",         "toolName": "dotnet_detect_circular_dependencies", "arguments": { "projectPath": "src/Api/Api.csproj" } }
    ]
  }
}

build-tests、build-worker、deps はすぐに開始し、test-api は build-tests の完了を待ちます。ステップはリソースマネージャーによってスロットリングされます（デフォルトはプロセッサ数で、configure_resource_limits で調整できます）。失敗はステップごとに報告され、依存関係が失敗すると、その依存先も停止します。

内部では ConcurrentExecutor／WorkflowEngine／ResourceManager が使われています。これらは MCP なしでも利用できる、DotNetDevMCP.Orchestration 内の通常の C# クラスです。

数値

i7-10750H、.NET 10.0.9 で BenchmarkDotNet を使用して測定しました。オーケストレーションのベンチマークでは、I/O バウンドの処理を Task.Delay で代用しているため、dotnet 自体ではなく、エンジンのオーバーヘッドとスケジューリングを測定しています。

シナリオ（20操作 × 50 ms）	平均	逐次実行との比較
逐次実行	1,237 ms	1.00
ConcurrentExecutor（5にスロットリング）	246 ms	0.20
ConcurrentExecutor（スロットリングなし、12コア）	123 ms	0.10
依存関係のある WorkflowEngine	185 ms	0.15
Task.WhenAll（下限値）	62 ms	0.05

依存関係のあるステップと独立したステップが混在するワークフロー	平均	逐次実行との比較
逐次実行	308 ms	1.00
WorkflowEngine	185 ms	0.60

影響を受けるテスト

編集後、エージェントは通常、テストスイート全体を再実行します。dotnet_test_affected は代わりに Roslyn に問い合わせます。変更されたファイルで宣言されているシンボルを取得し、[Fact]、[Theory]、[Test]、[TestCase]、[TestMethod] のいずれかを持つメソッドに到達するまで参照をたどります（最大ホップ数は maxDepth で指定し、デフォルトは 8）。その後、該当するテストのみを実行します。変更されたファイルは、デフォルトでは Git の作業ツリーから取得します。ブランチを指定する場合は gitBase: "main" を使います。dryRun: true を指定すると、テストを実行せずに一覧表示します。framework: "net10.0" を指定すると、複数のターゲットフレームワークを対象とするテストプロジェクトで、1つのターゲットフレームワークのみを実行します。 ウォークには時間予算があります（maxSelectionSeconds、デフォルトは 10 秒）。すべてのコードが依存するコードへの変更は、手頃な時間で追跡するには影響範囲が広すぎるため、その場合は変更されたプロジェクトを参照するテストプロジェクトを実行します（該当するものがすべてならソリューション全体を実行します）。その旨はレスポンスに示されます（selectionComplete: false、ranScope）。選択対象が全テストの 20％を超える場合（maxSelectedFraction）も同じ対応になります。フィルターをかけても実行時間が短縮されないためです。ウォークで追跡できない変更ファイル（.csproj、.razor、appsettings.json、削除されたファイル）は、同じプロジェクト単位のフォールバックに切り替わり、untracedFiles に一覧表示されます。Directory.Build.props、global.json、.editorconfig のいずれかに変更があると、ソリューション全体を実行します。選択範囲が不完全なまま通知されずに実行されることはありません。実行は timeoutSeconds（デフォルトは 600 秒）経過後に強制終了されるため、ハングしたテストがエージェントを停止させることはありません。レスポンスには、完了しなかったテストモジュールが示されます。maxDepth: 3 にすると、対象となる変更は絞り込めますが、見逃すテストも増えます。VSTest と Microsoft.Testing.Platform（global.json 内の "test": { "runner": "Microsoft.Testing.Platform" }）に対応しています。プロジェクト単位のフォールバックでは、復元済みの NuGet パッケージ参照もたどります（obj/project.assets.json がソリューション内の別プロジェクトのパッケージ ID を参照しているテストプロジェクトは、その間に ProjectReference がなくても選択されます）。Directory.Packages.props の変更を、バージョンが変更されたパッケージ ID を実際に使用するテストプロジェクトだけに絞り込むのは、そのファイルだけが変更された場合（どのプロジェクトにも属さないドキュメントの変更は除きます）、実際に変更されたのが Version 属性だけの場合（Condition、GlobalPackageReference、または同時に加えられたその他の編集は対象外です）、かつソリューション内のすべてのプロジェクトが復元済みの場合に限られます。それ以外の同ファイルへの変更、別のファイルと同時に加えられた変更、またはソリューション内のどこかに未復元のプロジェクトがある場合は、該当する条件を説明する注記を付けてソリューション全体を実行します。

このリポジトリでは、ConcurrentExecutor.cs を編集すると、44 件中 22 件のテストが選択されます（ConcurrentExecutorTests と、OrchestrationService 経由でそこに到達する OrchestrationServiceTests）。MCP ツールで計測した結果です。ビルドを含みます。i7-10750H：

	テスト数	実時間
シェルからの dotnet test	44	9 秒
dotnet_test_run	44	8.3 秒
dotnet_test_affected（ConcurrentExecutor.cs の変更）	22	6.6 秒

このテストスイートは小さいため、短縮効果もわずかです。実際のライブラリでは違いがより明確です。benchmarks/polly では、Polly の 40 件のコミットを再生し、そのコードに障害を注入します。1 ファイルの変更で、影響を受ける 5 件のテストが 5.1 秒で実行されたのに対し、net10.0 のテストスイート全体では 48.1 秒でした（同一セッション）。また、選択されたテストには、障害の注入によって失敗した 112 件中 111 件が含まれていました（見逃したものは、リフレクションを使ってオブジェクトを構築します）。数百件のテストに影響する変更では、効果はありません。直近の 40 件のコミットのうち、16 件ではフィルターをかけたテストが実行され、24 件ではスイート全体が実行されました。処理が集中するコードに対するセッション内の最初の選択は、より遅くなります（Roslyn が対象ファイルをバインドした後、キャッシュします）。dryRun: true を指定すると、何がどの理由で選択されたか（via）を確認できます。

セキュリティ

DotNetDevMCPは、コードを信頼して任せられるエージェントのために、あなたの権限で実行されます。dotnet buildとdotnet testはソリューションに含まれるものを何でも実行するため、悪意のあるテストや.csprojは、ターミナルで実行した場合とまったく同じように、あなたの権限で実行されます。サーバーはサンドボックスを追加しません。保証するのは、ツールの引数からdotnetやgitに余分なオプションを渡せないこと、Roslynによる編集がソリューションディレクトリ内にとどまること、そして--clean-envによって環境変数内のシークレットが子プロセスに渡らないことです。信頼できないコードを扱う場合は、認証情報を持たないコンテナーまたはVM内でエージェントとサーバーを一緒に実行してください。以下のイメージに含まれるのはサーバーのみで、ビルドとテストはすでにあなたのマシン上で実行されないようになっています。--httpをlocalhost以外に公開しないでください。詳細はこちらをご覧ください： SECURITY.md。

コンテナーで実行する

ネットワークを無効にし、メモリとプロセス数を制限し、ケイパビリティを無効にして、リポジトリだけをマウントしたコンテナーでサーバーを実行できます。そのため、エージェントが起動するビルドやテストが、マシンのほかの部分にアクセスすることはできません。イメージをビルドし（Dockerfileを含む最初のリリースはv0.3.4です）、ネットワーク接続がある状態で一度だけ復元してから、サンドボックス化されたサーバーを登録します：

docker build -t dotnetdevmcp https://github.com/csa7mdm/DotNetDevMCP.git#v0.3.4

docker run --rm -v "${PWD}:/src" -v dotnetdevmcp-nuget:/home/mcp/.nuget/packages --memory 8g --memory-swap 8g --pids-limit 512 --cap-drop ALL --security-opt no-new-privileges --entrypoint dotnet dotnetdevmcp restore /src/YourSolution.sln

claude mcp add dotnetdevmcp -- docker run -i --rm --network none -v "${PWD}:/src" -v dotnetdevmcp-nuget:/home/mcp/.nuget/packages:ro --memory 8g --memory-swap 8g --pids-limit 512 --cap-drop ALL --security-opt no-new-privileges dotnetdevmcp --load-solution /src/YourSolution.sln

これはDocker Desktop向けの形式です（Windows、macOS）。PowerShell、WSL、macOSから実行するか、Git Bashでは各コマンドの先頭にMSYS_NO_PATHCONV=1を付けてください。ネイティブのLinuxでは--userを使う形式が必要です。また、core.autocrlfが設定されたWindowsのリポジトリでは、gitモード用に追加の設定が必要です。どちらもSECURITY.mdに記載されています。各フラグが遮断するものや、それを実証するテストも確認できます。

すべてを保護できるわけではありません。マウントされたリポジトリは設計上、書き込み可能です。コンテナーに隔離されるのはサーバーのみで、エージェントやdocker CLIは隔離されません（Linuxではroot相当のデーモンアクセスが必要です）。復元では、ネットワークアクセスを使ってソリューション独自のビルドロジックが実行されます。共有パッケージキャッシュを介して、あるリポジトリに仕込まれたビルドファイルが別のリポジトリに持ち込まれる可能性があります（信頼できないリポジトリごとにボリュームを分けてください）。また、Docker Desktopの境界は、すべてのコンテナーが共有するVMカーネルです。

ヘルプ、フィードバック、コントリビューション

• 質問、アイデア、「これはバグですか？」：Discussionsをご利用ください。
• 問題が発生した場合：バグを報告する。ツール名と渡された引数が、特に役立つ情報です。
• コントリビューションをご希望ですか？good first issueから始めるか、CONTRIBUTINGをお読みください。ご自身のソリューションでDotNetDevMCPを実行し、その結果を報告していただくことも同じくらい役立ちます。
• ドキュメント：wiki（チュートリアル、ツールリファレンス、トラブルシューティング）は編集できます。
• セキュリティ：非公開で報告してください。
• 職場で利用していますか？：Discussionsでお知らせください。今後何を開発するかを決める参考になります。チームのソリューションへの導入支援（影響を受けるテストの調整、プライベートフィード向けの--clean-env、CI）や、チーム向け機能（共有設定、監査ログ、サンドボックスでの実行）への早期フィードバックを希望される場合も、そちらでお知らせください。
• ここに参加する全員が行動規範に従います。DotNetDevMCPで時間を節約できた場合は、開発をスポンサーとして支援できます。

ソースからビルドする

git clone https://github.com/csa7mdm/DotNetDevMCP.git
cd DotNetDevMCP
dotnet build -c Release
dotnet test -c Release
dotnet run --project src/DotNetDevMCP.Server -- --help

MCPクライアントからローカルビルドを使用するには、commandにsrc/DotNetDevMCP.Server/bin/Release/net10.0/dotnetdevmcpを指定してください（Windowsでは.exe）。

構成

src/
  DotNetDevMCP.Server/           entry point; stdio or HTTP; packs as the `dotnetdevmcp` tool
  DotNetDevMCP.CodeIntelligence/ Roslyn tools (SharpTools fork)
  DotNetDevMCP.Testing/          dotnet test runner, TRX parsing, Roslyn affected-test selection
  DotNetDevMCP.Build/            dotnet build/restore/clean
  DotNetDevMCP.Analysis/         dependency graph, quality metrics
  DotNetDevMCP.SourceControl/    git
  DotNetDevMCP.Orchestration/    ConcurrentExecutor, WorkflowEngine, ResourceManager, orchestration tools
  DotNetDevMCP.Monitoring/       process metrics
  DotNetDevMCP.Core/             interfaces and models shared by the above
tests/                           xUnit tests
benchmarks/                      BenchmarkDotNet suite; polly/ measures the tools on Polly
docs/architecture/               design notes and ADRs

公式のMCP C# SDK 2.xをベースにしています。パッケージのバージョンはDirectory.Packages.propsで一元管理されています。

ステータス

0.3.4。Roslyn ツールは成熟しています（SharpTools に由来します）。テスト、ビルド、Git、オーケストレーションの各機能は比較的新しく、このリポジトリといくつかの別のリポジトリで動作確認されています。特殊なプロジェクト構成では、まだ不具合がある可能性があります。問題の報告やプルリクエストを歓迎します。CONTRIBUTINGをご覧ください。

既知の制限：dotnet_test_affected がたどるのは C# の参照のみです（リフレクション、規約ベースの DI、文字列キーによる検索には対応していません）。そのため、これらの経路でのみ到達する変更はテスト選択の対象になりません。選択されるテストを確認するには、dryRunを使用してください。インターフェースまたは基底クラス経由の呼び出しはたどります。プロジェクトのフォールバックでは、ProjectReferenceと NuGet パッケージ参照をたどります。テストプロジェクトが復元済みの場合は、パッケージ参照もたどるようになりました。別のリポジトリの利用側は対象外です。ビルドとテストはサンドボックス化されていません（「セキュリティ」を参照）。失敗せずにハングするテストを検出できるのは、実行が完了した場合のみです。テスト属性の検出は、属性名による xUnit、NUnit、MSTest に対応しています。コマンドラインの長さ制限を超えると、フィルターはメソッドからクラスへ、さらにプロジェクト全体へと範囲を広げます（テスト数は増えますが、減ることはありません）。

クレジットとライセンス

MIT。コードインテリジェンスモジュールは、кɵɵѕнī による SharpTools のフォークであり、こちらも MIT ライセンスです。参照ではなくフォークを選んだ理由については、LICENSE、NOTICE、ADR-001をご覧ください。