Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Enh]: Support MCP protocol revision 2026-07-28 (stateless transport, server/discover, cacheable lists)

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
領域
api, backend

調査の方向性

MCP 2026-07-28仕様と#3429のギャップ分析から始め、関連する#3658のpackaging issueも確認してください。このissueでは実装ではなく、ロードマップまたは明示的な決定を求めています。そのため、該当するmilestoneまたはlabelとともにDABのサポート方針が記録されれば完了です。

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

説明

Summary

DAB's MCP server advertises and implements 2025-06-18 as a fixed default
(McpProtocolDefaults.DEFAULT_PROTOCOL_VERSION). Two spec revisions have shipped since:
2025-11-25 and 2026-07-28. #3429 analysed the gap to 2025-11-25 and was closed without
a follow-up item, and there is currently no issue tracking 2026-07-28 at all.

This issue asks for a decision and, if applicable, a roadmap entry — not necessarily an
immediate implementation.

Why this revision is different

2026-07-28 is not additive; it restructures the transport and lifecycle:

  • Protocol-level sessions and the Mcp-Session-Id header are removed.
  • The initialize / notifications/initialized handshake is removed. Every request
    carries its protocol version and client capabilities in _meta.
  • A new server/discover RPC is mandatory for advertising versions, capabilities and identity.
  • The GET stream endpoint and resources/subscribe are replaced by subscriptions/listen.
  • SSE resumability (Last-Event-ID) is removed.
  • MCP-Protocol-Version, Mcp-Method and Mcp-Name headers become required, with
    server-side header/body validation (-32020 HeaderMismatch).
  • All results carry a resultType; server-initiated requests are replaced by the
    Multi Round-Trip Requests (MRTR) pattern.
  • ping, logging/setLevel are removed; Roots, Sampling and Logging are deprecated.

Because the handshake itself is gone, the compatibility burden shifts entirely to clients.
The spec defines a probe-and-fall-back path, but a server that only speaks 2025-06-18
depends on every client retaining that path indefinitely. #3429 documented this failure mode
in practice (a client disconnecting on version downgrade over stdio).

What DAB would gain beyond conformance

Several of the changes map onto capabilities DAB users already ask for:

  • Statelessness. With no protocol session, DAB instances become trivially scalable behind
    a load balancer, and a restart no longer invalidates in-flight clients. It also removes the
    Mcp-Session-Id friction that the MCP Inspector guidance currently works around.
  • ttlMs / cacheScope on tools/list, resources/list, resources/read. DAB already
    has an entity cache with TTL; surfacing it at the protocol level would let clients stop
    re-fetching. This matters at scale: our production configuration has 315 entities and
    describe_entities responses are substantial.
  • Deterministic tool ordering (a SHOULD in this revision) improves client-side caching and
    LLM prompt-cache hit rates. Should be trivial, since DAB generates the tool surface.
  • Mcp-Name header. Lets reverse proxies route, rate-limit and audit per tool without
    parsing the request body. Today an operator behind nginx sees only POST /mcp and cannot
    tell which entity was read — a real gap for auditing.
  • Tasks extension (io.modelcontextprotocol/tasks) is a natural fit for
    aggregate_records over large tables.

Deployment context

Read-only ERP database exposed through DAB 2.0.9, HTTP transport behind an nginx reverse
proxy, 315 entities, consumed by MCP clients. Nothing is broken today — clients still
negotiate 2025-06-18 successfully over HTTP. The concern is that continued operation
depends on client-side backwards compatibility that operators do not control, while DAB has
no stated position.

Ask

  1. Is support for 2026-07-28 on the roadmap?
  2. If yes, could it be tracked with a milestone/label the way other MCP work is (2.x, 2.3)?
  3. If no — please say so explicitly. A clear "DAB stays on 2025-06-18 for now" is genuinely
    actionable for operators, who can then plan a translating layer instead of waiting.
    (Related: #3658, packaging Microsoft.DataApiBuilder.Mcp as a NuGet SDK, would make such
    a layer considerably cheaper to build.)

References

主要言語
C#
スター
1.5k
フォーク
372
平均マージ
7日 19時間
マージ済み PR(30日)
10

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

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

はじめの一歩

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

Azure/data-api-builder のほかの issue

Azure/data-api-builder の issue をすべて見る

似ている issue

C# の issue をもっと見る

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

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