0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MCPの仕様とC# SDKがv2でどう変わったのか整理してみる

0
Posted at

はじめに

Model Context Protocol(MCP)の仕様が2026年7月28日付でメジャーアップデートされ、C# SDKも合わせて v2.0.0 としてメジャーバージョンアップしました。ちょうど1週間ほど前には v2.2.0 もリリースされていて、v2系はすでに安定して動いている状態です。

「stateless」「discovery-first」など聞き慣れないキーワードが増えていたので、何がどう変わったのかを一度整理しておきます。

MCP仕様 2026-07-28(安定版)およびC# SDK v2.2.0 時点の情報を元にしています。

MCPのバージョニングの仕組み

MCPの仕様バージョンは YYYY-MM-DD の日付形式で管理されていて、後方互換性を壊す変更をした最後の日付を表します。セマンティックバージョニングのような「メジャー.マイナー.パッチ」ではないので、「v2」という呼び方はSDK側(C# SDKやTypeScript SDKなど)のバージョン番号を指しています。

仕様バージョン リリース時期 備考
2024-11-05 2025年1月 最初の安定版
2025-03-26 2025年3月
2025-06-18 2025年6月
2025-11-25 2025年11月
2026-07-28 2026年7月 今回取り上げる大型改訂

クライアントとサーバは複数の仕様バージョンを同時にサポートでき、リクエストごとにどのバージョンを使うか宣言し合う「バージョンネゴシエーション」の仕組みで後方互換性を保っています。

仕様 2026-07-28 で何が変わったか

initialize ハンドシェイクの廃止

これまでのMCPは、接続確立時に initialize リクエストを送ってサーバのケーパビリティを取得する「ハンドシェイク」が必須でした。2026-07-28 ではこれが廃止され、代わりに server/discover という1回のリクエストでケーパビリティ・対応プロトコルバージョン・サーバ情報をまとめて取得する「discovery-first」方式になりました。

server/discover の呼び出しは任意です。クライアントはいきなり本来のリクエストを送り、サーバが対応していないバージョンならエラーを返してもらう、という使い方もできます。

ステートレスが既定に

サーバ側でセッション状態を持たない「ステートレス」な動作が標準になりました。これに伴い、Mcp-Session-Id ヘッダーやセッション削除用の DELETE エンドポイントは、ステートレスサーバでは不要になっています。

大量のクライアントを捌くAPIサーバとして動かす場合、セッションの記憶領域を持たなくて済むのはスケールの面でもメリットがあります。

Roots / Sampling / Logging の非推奨化

MCPの初期からある「Roots」「Sampling」「Logging」の3つの機能は、より汎用的な「Extensions framework」に統合される方針で非推奨になりました。既存の接続では引き続き使えますが、新規実装では拡張機能ベースの代替への移行が推奨されています。

Tasks拡張・MCP Apps拡張

長時間かかるツール呼び出しを非同期化して状態をポーリングできる「Tasks拡張」と、MCPホスト上でインタラクティブなUIを描画できる「MCP Apps拡張」が、それぞれ独立した拡張機能として整理されました。

C# SDK v2.0での主な破壊的変更

C# SDKは 2026-07-28 仕様への追従に合わせて v2.0.0 としてメジャーアップし、いくつかの破壊的変更が入りました。

ステートレスHTTPが既定値に

// v1.x(既定はステートフル)
builder.Services
    .AddMcpServer()
    .WithHttpTransport();

// v2.0(HttpServerTransportOptions.Statelessの既定値がtrueに変更)
builder.Services
    .AddMcpServer()
    .WithHttpTransport(options =>
    {
        // 既存のステートフルな挙動が必要な場合は明示的にfalseにする
        options.Stateless = false;
    });

セッションを使う既存実装がある場合は、Stateless = false を明示しないと動作が変わってしまう点に注意が必要です。

Roots / Sampling / Loggingが [Obsolete]

安定版として提供されていたRoots・Sampling・LoggingのAPIサーフェスに、仕様の非推奨化に合わせて [Obsolete](警告コード MCP9005)が付与されました。既存の down-level 接続(2025-11-25 以前)ではそのまま使えますが、コンパイル時に警告が出るようになります。移行を後回しにしたい場合は、警告を一時的に抑制することもできます。

Tasks機能が別パッケージへ移動

// v1.x(ModelContextProtocol.Core に同梱)
using ModelContextProtocol.Protocol;
// McpServerOptions.TaskStore などを直接設定していた

// v2.0(専用パッケージに分離)
// dotnet add package ModelContextProtocol.Extensions.Tasks
using ModelContextProtocol.Extensions.Tasks;

builder.Services
    .AddMcpServer()
    .WithTasks() // 拡張メソッドとしてTasksストアを登録
    .WithHttpTransport();

Tasks関連の型・拡張メソッドは ModelContextProtocol.Extensions.Tasks 名前空間に移動しており、McpServerOptions.TaskStore のような直接設定ではなく、ビルダー拡張メソッド経由での登録に変わっています。

OAuthコールバックの受け取り方が変更

// v1.x(MCP9007警告:リダイレクトURL全体を自前でパースする必要があった)
var options = new ClientOAuthOptions
{
    AuthorizationRedirectDelegate = async (redirectUri, ct) =>
        ParseAuthorizationCode(redirectUri),
};

// v2.0(code / state / issuerがフレームワーク側でパース済みで渡ってくる)
var options = new ClientOAuthOptions
{
    AuthorizationCallbackHandler = async (callbackContext, ct) =>
        new AuthorizationResult
        {
            Code = callbackContext.Code,
            State = callbackContext.State,
            Iss = callbackContext.Issuer,
        },
};

RFC 9207・RFC 8414準拠のissuer検証も追加され、認可サーバのメタデータが不整合な場合は認証が失敗するようになっています(回避せず、メタデータ側を修正するのが推奨)。

構造化ツール結果・inputSchema の扱い変更

// v1.x: 非オブジェクトの戻り値も { "result": ... } でラップされていた
// structuredContent: { "result": 72 }

// v2.0: 生の値がそのまま返るようになった
// structuredContent: 72

UseStructuredContent = true でオブジェクト以外の型を返すツールは、result プロパティでラップされなくなり、宣言したスキーマに従って生の値がそのまま返されるようになりました。また Tool をデシリアライズする際に inputSchema が無いと例外になるため、自前でツールのJSONを組み立てている場合は空でも {} を含める必要があります。

まとめ

MCP 2026-07-28 仕様は「initialize ハンドシェイクの廃止」「ステートレスの既定化」という、接続ライフサイクルそのものを見直す大きな改訂でした。C# SDKもそれに合わせて v2.0.0 でいくつかの破壊的変更を入れつつ、2025-11-25 以前のクライアント・サーバとは自動で下位互換の initialize ハンドシェイクにフォールバックするようになっているので、いきなり全部が壊れるわけではありません。

とはいえステートレスの既定化やTasksパッケージの分離は既存実装に影響が出やすいポイントなので、v1系からv2系へ上げる際はC# SDK Versioningのドキュメントと変更履歴を確認してから移行するのがオススメです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?