dotnet new mcpserver が .NET 11 Preview 4 SDK に同梱されました
.NET 11 Preview 4 は mcpserver プロジェクトテンプレートを直接 SDK に同梱します。Microsoft.McpServer.ProjectTemplates の個別インストールも、preview フィードの手間もありません。stdio か HTTP のトランスポートを選び、Native AOT を有効にし、dotnet new mcpserver -o MyServer がセットアップのすべてです。
.NET 11 Preview 4 のリリースノートには、C# から Model Context Protocol サーバーを出荷するすべての人にとって小さいながらも要となる一行があります。mcpserver プロジェクトテンプレートは、これまで Microsoft.McpServer.ProjectTemplates をインストールしないと使えませんでしたが、今は .NET SDK に同梱されたテンプレートとして出荷されます。dotnet new list は追加インストールなしでこれを発見でき、その servicing は別個の NuGet パッケージではなく ASP.NET Core スタックと一緒に流れます。
Preview 4 SDK で何が変わるか
.NET 11 Preview 3 までは、新しい MCP サーバーのレシピは二段階でした。
# Preview 3 and earlier
dotnet new install Microsoft.McpServer.ProjectTemplates
dotnet new mcpserver -o InventoryMcp
クリーンな CI イメージや同僚の最初のチェックアウトでは、dotnet new install のステップが静かに壊れがちでした。NuGet から引っ張り、独自のケイデンスを持ち、テンプレートはユーザープロファイルに住みつき、新しい devcontainer では生き残らなかったのです。
Preview 4 (11.0.100-preview.4) では、ステップ 1 が消えます。
dotnet new mcpserver -o InventoryMcp
cd InventoryMcp
dotnet run
テンプレートは SDK リリースと一緒にバージョン管理されるので、global.json を 11.0.100-preview.4 にピン留めすれば、テンプレートも同時にピン留めされます。
標準で何が手に入るか
dotnet new mcpserver --help がテンプレートのサポートするノブを見せてくれます。最も重要な二つは次のとおりです。
dotnet new mcpserver --help
# Options:
# -f, --framework <net11.0> The target framework.
# --transport <stdio|http> MCP transport type. Default: stdio.
# --aot Enable Native AOT publish.
# --self-contained Enable self-contained publish.
ここに本物の選択が二つあります。
--transport stdio(既定) は、stdin/stdout でプロトコルを話すコンソールホストを生成します。Claude Code、Claude Desktop、VS Code がmcp.jsonから MCP の子プロセスを fork するときに起動するのがこれです。エージェントが同じマシンにいるときの正解です。--transport httpは Streamable HTTP トランスポートをマップした ASP.NET Core ホストを生成します。サーバーが ingress の背後にいて複数のエージェントで共有されるときに手を伸ばしてください。
--aot スイッチは最初から Native AOT publish を配線します。.csproj の PublishAot=true、プロトコルバインディング向けの AOT 互換ソースジェネレーター、ツール登録の trim-safe な属性配線です。--self-contained と組み合わせれば、数十ミリ秒で起動する単一ファイルの実行ファイルが手に入ります。これは stdio サーバーにとって重要です。エージェントがセッションごとに fork するからです。
最小限の stdio スキャフォルドは次のようになります。
// Program.cs -- generated by dotnet new mcpserver --transport stdio
using Microsoft.Extensions.Hosting;
using ModelContextProtocol.Server;
using System.ComponentModel;
var builder = Host.CreateApplicationBuilder(args);
builder.Logging.AddConsole(o =>
{
// stderr only -- stdout is the protocol channel
o.LogToStandardErrorThreshold = LogLevel.Trace;
});
builder.Services
.AddMcpServer()
.WithStdioServerTransport()
.WithToolsFromAssembly();
await builder.Build().RunAsync();
[McpServerToolType]
public static class EchoTool
{
[McpServerTool, Description("Echo the input back.")]
public static string Echo(string message) => $"hello {message}";
}
stderr 専用のロギングが標準で焼き込まれており、これは初心者が最もハマる落とし穴です。stdout への迷子の Console.WriteLine ひとつで JSON-RPC ストリームが壊れ、エージェントは有用な詳細のないプロトコルエラーを返します。
既存プロジェクトとの付き合い方
すでに古い方法で MCP サーバーをスキャフォールドしている場合 (.NET 11 上の C# でカスタム MCP サーバーを構築する方法の詳しいウォークスルーを参照)、マイグレーションは不要です。同梱テンプレートは古いものと同じ ModelContextProtocol パッケージ参照を生成します。変わるのは新しいプロジェクトの始め方だけです。
今日やる価値のあること。global.json を 11.0.100-preview.4 にピン留めし、チームのセットアップドキュメントと devcontainer から dotnet new install Microsoft.McpServer.ProjectTemplates の行を削除し、オンボーディング当日の Slack の質問が一つ消えるのを眺めましょう。
Comments
Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.