You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Is support for 2026-07-28 on 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-18 for now" is genuinely
actionable for operators, who can then plan a translating layer instead of waiting.
(Related: Add NuGet Package Support for Microsoft.DataApiBuilder.Mcp #3658, packaging Microsoft.DataApiBuilder.Mcp as a NuGet SDK, would make such
a layer considerably cheaper to build.)
Summary
DAB's MCP server advertises and implements
2025-06-18as a fixed default(
McpProtocolDefaults.DEFAULT_PROTOCOL_VERSION). Two spec revisions have shipped since:2025-11-25and2026-07-28. #3429 analysed the gap to2025-11-25and was closed withouta follow-up item, and there is currently no issue tracking
2026-07-28at 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-28is not additive; it restructures the transport and lifecycle:Mcp-Session-Idheader are removed.initialize/notifications/initializedhandshake is removed. Every requestcarries its protocol version and client capabilities in
_meta.server/discoverRPC is mandatory for advertising versions, capabilities and identity.resources/subscribeare replaced bysubscriptions/listen.Last-Event-ID) is removed.MCP-Protocol-Version,Mcp-MethodandMcp-Nameheaders become required, withserver-side header/body validation (
-32020 HeaderMismatch).resultType; server-initiated requests are replaced by theMulti 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-18depends 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:
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 alreadyhas 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.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 withoutparsing the request body. Today an operator behind nginx sees only
POST /mcpand cannottell which entity was read — a real gap for auditing.
io.modelcontextprotocol/tasks) is a natural fit foraggregate_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-18successfully over HTTP. The concern is that continued operationdepends on client-side backwards compatibility that operators do not control, while DAB has
no stated position.
Ask
2026-07-28on the roadmap?2.x,2.3)?2025-06-18for now" is genuinelyactionable for operators, who can then plan a translating layer instead of waiting.
(Related: Add NuGet Package Support for Microsoft.DataApiBuilder.Mcp #3658, packaging
Microsoft.DataApiBuilder.Mcpas a NuGet SDK, would make sucha layer considerably cheaper to build.)
References
2025-11-25(closed)Microsoft.DataApiBuilder.McpNuGet package