Define handling for protocol-incompatible result properties set by applications

オープン
#1,754 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
csharp

調査の方向性

共有のポストハンドラー境界から開始し、McpServerImpl.IsJuly2026OrLaterProtocolRequest が RequestContext.JsonRpcRequest.Context.ProtocolVersion と McpServer.NegotiatedProtocolVersion をどのように解決するかを読みます。選択する前に提案されたポリシーを比較し、その後、通常の結果、キャッシュ可能な結果、即時の代替結果の出力を追跡します。完了条件は、選択した動作が定義され、正確な wire 形式のテストが、一覧にあるプロトコルコンテキスト、ハンドラー、フィルター、再利用された結果インスタンスをカバーしていることです。

索引モデルが issue の本文から書いたものです。

説明

enhancement P2 ready for work

Summary

PR #1753 fixes #1721 by stopping the SDK from automatically adding the 2026-07-28-only resultType, ttlMs, and cacheScope properties to legacy results. Applications can still set those properties explicitly from handlers or filters, which can produce a wire shape that is invalid for the negotiated protocol version.

We should define and consistently enforce the server behavior for protocol-version-specific result properties supplied by application code.

Protocol detection

The effective protocol version is already available at the shared post-handler boundary:

  • Use RequestContext.JsonRpcRequest.Context.ProtocolVersion for per-request metadata protocols.
  • Fall back to McpServer.NegotiatedProtocolVersion for stateful sessions.
  • McpServerImpl.IsJuly2026OrLaterProtocolRequest already implements this resolution.

Possible policies

  1. Fail the request before serialization with an InternalError and a useful server-side diagnostic. This gives application developers the strongest signal, but turns an otherwise valid client request into an error. Ordinary application exceptions currently produce a generic "An error occurred." response, so we would also need to decide whether the client receives a specific message.
  2. Strip the unsupported properties and log a warning. This preserves a valid legacy wire shape while making the application misuse visible to server operators.
  3. Strip the unsupported properties silently. This maximizes compatibility but can hide application bugs.

Scope

The selected policy should:

  • Be applied once at a typed response-emission boundary after handlers and filters.
  • Cover Result.ResultType and both ICacheableResult properties.
  • Cover normal, cacheable, and immediate alternate results.
  • Avoid mutating shared response instances in a way that can affect later requests using another protocol version.
  • Preserve explicit values and add required defaults for 2026-07-28 and later responses.
  • Be extensible to future protocol-version-specific result properties.

Tests

Add exact serialized wire-shape coverage for:

  • Legacy handlers and filters that explicitly set each unsupported property.
  • 2026-07-28 handlers and filters with explicit values.
  • Normal, cacheable, and immediate alternate results.
  • Session-negotiated and per-request HTTP protocol contexts.
  • Reused or shared result instances across requests with different protocol versions.
主要言語
C#
スター
4.5k
フォーク
814
平均マージ
9日 19時間
マージ済み PR(30日)
4

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/csharp-sdk のほかの issue

modelcontextprotocol/csharp-sdk の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。