[Enh]: Support MCP protocol revision 2026-07-28 (stateless transport, server/discover, cacheable lists)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
Hướng nghiên cứu
Bắt đầu với đặc tả MCP ngày 2026-07-28 và phân tích khoảng cách trong #3429; đồng thời xem xét issue packaging liên quan, #3658. Issue này yêu cầu một roadmap hoặc quyết định rõ ràng thay vì triển khai, vì vậy sẽ hoàn tất khi quan điểm hỗ trợ của DAB được ghi nhận cùng với mọi milestone hoặc label áp dụng được.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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-Idheader are removed. - The
initialize/notifications/initializedhandshake is removed. Every request
carries its protocol version and client capabilities in_meta. - A new
server/discoverRPC is mandatory for advertising versions, capabilities and identity. - The GET stream endpoint and
resources/subscribeare replaced bysubscriptions/listen. - SSE resumability (
Last-Event-ID) is removed. MCP-Protocol-Version,Mcp-MethodandMcp-Nameheaders 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/setLevelare 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-Idfriction that the MCP Inspector guidance currently works around. ttlMs/cacheScopeontools/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_entitiesresponses 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-Nameheader. Lets reverse proxies route, rate-limit and audit per tool without
parsing the request body. Today an operator behind nginx sees onlyPOST /mcpand cannot
tell which entity was read — a real gap for auditing.- Tasks extension (
io.modelcontextprotocol/tasks) is a natural fit for
aggregate_recordsover 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
- Is support for
2026-07-28on the roadmap? - If yes, could it be tracked with a milestone/label the way other MCP work is (
2.x,2.3)? - If no — please say so explicitly. A clear "DAB stays on
2025-06-18for now" is genuinely
actionable for operators, who can then plan a translating layer instead of waiting.
(Related: #3658, packagingMicrosoft.DataApiBuilder.Mcpas a NuGet SDK, would make such
a layer considerably cheaper to build.)
References
- Changelog for the revision: https://modelcontextprotocol.io/specification/2026-07-28/changelog
- Streamable HTTP transport: https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
- #3429 — gap analysis for
2025-11-25(closed) - #3658 —
Microsoft.DataApiBuilder.McpNuGet package
- Ngôn ngữ chính
- C#
- Star
- 1.5k
- Fork
- 372
- Merge trung bình
- 7 ngày 19 giờ
- Pull request đã merge (30 ngày)
- 10
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Azure/data-api-builder
-
pgsql
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Azure/data-api-builder#3598 ·
-
2.x cli mcp-server
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Azure/data-api-builder#3576 ·
-
2.x health-endpoint
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Azure/data-api-builder#3570 ·
-
2.x telemetry
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Azure/data-api-builder#3564 ·
-
2.x telemetry
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Azure/data-api-builder#3562 ·
Tất cả issue của Azure/data-api-builder
Issue tương tự
-
untriaged
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
dotnet/dotnet-api-docs#13095 ·
-
area-deployment area-integrations triage:bot-seen
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 86/100
-
type/automation type/tech-debt
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
newrelic/newrelic-dotnet-agent#3850 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
LuckyPennySoftware/AutoMapper#4660 ·