docs: add upcoming transport WG tracks roadmap (#50)
This commit is contained in:
Kurtis Van Gent
GitHub
parent
6d9b43bd5f
commit
f1bad2f384
1 changed files with 364 additions and 0 deletions
364
roadmaps/2026-12-15.md
Normal file
364
roadmaps/2026-12-15.md
Normal file
|
|
@ -0,0 +1,364 @@
|
|||
# Transports WG: 2026-12-15 Roadmap
|
||||
|
||||
This document is a high-level outline of the tracks the Transports Working Group
|
||||
is taking up for the **2026-12-15** specification release. Each track gets a
|
||||
short brief: the goal (what problem it solves), the core idea of the solution,
|
||||
key requirements, and the open questions we still need to answer. As tracks
|
||||
mature, each brief should graduate into a full problem statement or proposal
|
||||
under `proposals/`.
|
||||
|
||||
Tracks are grouped into three tiers — **Priority**, **Best Effort**, and **Not
|
||||
Planned** — and numbered in priority order across the document.
|
||||
|
||||
## Alignment with the MCP roadmap
|
||||
|
||||
The core maintainers' [MCP
|
||||
roadmap](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/) names five
|
||||
priority areas for the next specification release and beyond. SEPs that fall
|
||||
within those areas get expedited review and the best chance of acceptance;
|
||||
proposals outside them compete for scarce maintainer review time. These items
|
||||
are marked below as "MCP priority".
|
||||
|
||||
# Priority
|
||||
|
||||
Targeted for the 2026-12-15 release.
|
||||
|
||||
## 1. Tool/Primitive Versioning
|
||||
|
||||
**MCP priority** - HTTP-native transport hardening.
|
||||
|
||||
**Outcome:** Allow clients to indicate which version of a primitive definition
|
||||
they are using, and allow servers to adjust behavior, reroute the request, or
|
||||
refuse execution based on that version.
|
||||
|
||||
**Approach:** Add an ETag-like version identifier to primitive definitions.
|
||||
Clients return the identifier when invoking a primitive. Servers use it to
|
||||
preserve the behavior described by that version, route the request to a
|
||||
compatible implementation, or reject the request if the version cannot be
|
||||
honored.
|
||||
|
||||
The identifier can also support conditional list requests. `ttlMs` determines
|
||||
when a client should revalidate a cached list; the identifier determines whether
|
||||
the list or an individual definition has changed.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* An opaque version identifier for primitive definitions.
|
||||
* A standard way for clients to include the identifier when invoking a
|
||||
primitive.
|
||||
* Defined server behavior when the requested version differs from the current
|
||||
version: preserve compatible behavior, reroute the request, or reject it.
|
||||
* A standard version-mismatch error that is distinct from execution errors and
|
||||
tells the client whether to refresh and retry. The code should come from the
|
||||
registry defined by the Error Standardization track.
|
||||
* Conditional revalidation for cacheable list results, integrated with `ttlMs`
|
||||
and `cacheScope`.
|
||||
* Equivalent behavior across transports, including transports without HTTP
|
||||
headers.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* Must clients include the version when invoking a primitive, or is it optional
|
||||
for backward compatibility?
|
||||
* What changes are compatible, and who decides whether to preserve behavior,
|
||||
reroute, or reject the request?
|
||||
* How long should a server retain support for older versions, if at all?
|
||||
* Which parts of a definition determine its version: the entire definition or
|
||||
only fields that affect behavior? How should localized text be handled?
|
||||
* Should HTTP use `ETag` and `If-None-Match` directly, map them to in-band
|
||||
fields, or support both?
|
||||
* Do list-level and primitive-level versions use the same mechanism?
|
||||
* How does revalidation work with shared caches using `cacheScope: "public"`?
|
||||
|
||||
---
|
||||
|
||||
## 2. HTTP over STDIO
|
||||
|
||||
**MCP priority** - HTTP-native transport unification and hardening.
|
||||
|
||||
**Outcome:** Reduce protocol divergence, maintenance work, and wire overhead by
|
||||
using the same HTTP transport model for local subprocesses and network
|
||||
connections. Features should not require separate stdio behavior or duplicate
|
||||
values in both JSON-RPC `_meta` and HTTP headers.
|
||||
|
||||
**Approach:** Run Streamable HTTP over a subprocess's stdin and stdout. Clients
|
||||
continue to manage the server process, but exchange HTTP messages instead of
|
||||
newline-delimited JSON-RPC. With both standard transports using HTTP semantics,
|
||||
implementations can share transport logic and encode transport metadata once in
|
||||
headers.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* Preserve the same protocol behavior across subprocess and network
|
||||
connections.
|
||||
* Support concurrent requests and server-initiated messages over one process.
|
||||
* Define one canonical representation for transport metadata rather than
|
||||
requiring duplicate `_meta` fields and HTTP headers.
|
||||
* Distinguish HTTP-over-stdio servers from legacy stdio servers during startup.
|
||||
* Define process startup, shutdown, failure, and stderr behavior.
|
||||
* Keep the implementation practical for small servers and SDKs across
|
||||
languages.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* Should the pipe carry HTTP/1.1 with additional conventions or HTTP/2?
|
||||
* How should server-initiated requests use an HTTP connection over stdin and
|
||||
stdout?
|
||||
* Should this be a **new** transport, or can clients negotiate between legacy
|
||||
and HTTP-based versions over stdio?
|
||||
* Which `_meta` fields can move exclusively to HTTP headers, and how should
|
||||
older implementations be supported?
|
||||
* Which HTTP authentication semantics, if any, apply to local subprocesses?
|
||||
* What is the minimum conforming implementation?
|
||||
|
||||
---
|
||||
|
||||
## 3. Pluggable Transports
|
||||
|
||||
**Outcome:** Keep Streamable HTTP as MCP's primary transport, the focus of
|
||||
upcoming protocol designs, and the only transport every client must support.
|
||||
Developers with requirements it cannot meet should have an escape hatch for
|
||||
custom transports, allowing MCP to be adopted without expanding the baseline
|
||||
for every implementation.
|
||||
|
||||
**Approach:** Separate the MCP data model from its wire representation enough
|
||||
for SDKs to expose a custom transport interface. Streamable HTTP remains the
|
||||
reference binding and default design target; custom transports are optional
|
||||
extensions for specialized environments.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* Define the logical message interface shared by all transports.
|
||||
* Define transport responsibilities such as serialization, framing, delivery,
|
||||
ordering, bidirectional communication, and metadata.
|
||||
* Keep the MCP data model and application APIs independent of the selected
|
||||
transport.
|
||||
* Identify optional transport features and behavior when they are unavailable.
|
||||
* Define how startup, shutdown, failure, and reconnection map onto the transport
|
||||
interface.
|
||||
* Custom transports must not impose new requirements on clients that support
|
||||
only Streamable HTTP.
|
||||
* Provide conformance criteria for third-party transport implementations.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* Where is the exact boundary between the data model and transport behavior?
|
||||
* Which delivery and ordering guarantees must every transport provide?
|
||||
* How should logical metadata map to transports without HTTP-style headers?
|
||||
* How should implementations name, select, and negotiate transport bindings?
|
||||
* Should Tier 1 SDKs be required to expose a pluggable transport interface to
|
||||
encourage a consistent extension mechanism across widely used clients?
|
||||
* How prescriptive should the interface guidance be while still allowing
|
||||
idiomatic, language-specific APIs?
|
||||
* Should conformance use a checklist, a shared test suite, or both?
|
||||
|
||||
---
|
||||
|
||||
# Best Effort
|
||||
|
||||
Lower priority. We will advance these if capacity allows, but they are not
|
||||
commitments for the 2026-12-15 release.
|
||||
|
||||
## 4. Error Standardization
|
||||
|
||||
**Outcome:** Give clients and infrastructure consistent, machine-readable errors
|
||||
across transports. Implementations should not need to invent codes or match
|
||||
message text.
|
||||
|
||||
**Approach:** Define a normative registry that assigns each protocol error a
|
||||
name, JSON-RPC code, HTTP status where applicable, and retry guidance. Prefer
|
||||
standard JSON-RPC codes when they fit; allocate MCP-specific codes from the
|
||||
range reserved by the [2026-07-28
|
||||
specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/index#error-codes).
|
||||
Error messages remain flexible, human-readable text.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* Assign each defined error condition a name, JSON-RPC code, HTTP mapping, and
|
||||
retry classification.
|
||||
* Provide generic fallback codes for conditions without a specific entry.
|
||||
* Define how JSON-RPC errors and HTTP statuses are used together.
|
||||
* Reuse standard JSON-RPC codes when they accurately describe the condition.
|
||||
* Define a clear boundary between protocol errors and application errors,
|
||||
including when invalid input produces a JSON-RPC error versus a tool result
|
||||
reporting failure.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* When should an error use a non-200 HTTP status instead of a JSON-RPC error in a
|
||||
`200` response?
|
||||
* Are HTTP status mappings required or recommended?
|
||||
* Which failures are protocol errors, and which should be represented as
|
||||
application-level results?
|
||||
* How should extensions and implementations allocate error codes?
|
||||
* Should the registry define the structure of `error.data`?
|
||||
* How should retryability and delay information be represented?
|
||||
* How do content-language rules apply to human-readable error messages?
|
||||
|
||||
---
|
||||
|
||||
## 5. Incremental Tool Results
|
||||
|
||||
**Outcome:** Allow tools to return results incrementally or just in time instead
|
||||
of buffering the complete result. This supports cases such as streaming video
|
||||
while it is generated and delivering large database query results as rows become
|
||||
available.
|
||||
|
||||
**Approach:** Associate an ordered sequence of result chunks with a tool call,
|
||||
followed by a terminal outcome. Each chunk can contain standard MCP content or
|
||||
structured data and is delivered as soon as it becomes available. Because
|
||||
JSON-RPC normally permits one response per request, this track must also define
|
||||
how chunks are represented and correlated before that final response.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* Associate every chunk with its tool call, preserve ordering, and distinguish
|
||||
chunks from the terminal success or error.
|
||||
* Support structured data and binary content without requiring clients to
|
||||
reconstruct one in-memory result.
|
||||
* Define a JSON-RPC-compatible mechanism for delivering multiple chunks before
|
||||
the terminal response.
|
||||
* Support cancellation and flow control with defined cleanup behavior.
|
||||
* Resolve the overlap with Tasks, including when an operation should use
|
||||
incremental results, a Task, or both, and whether Task output can use the same
|
||||
mechanism.
|
||||
* Negotiate support without breaking clients that accept only terminal results.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* Where is the boundary between incremental tool results and Tasks?
|
||||
* Can a Task produce incremental output using the same mechanism?
|
||||
* Should JSON-RPC chunks use notifications, extend progress notifications, or
|
||||
introduce a new message type?
|
||||
* How are chunks correlated with the original request while preserving
|
||||
JSON-RPC's single terminal response?
|
||||
* How do chunks combine into a final result?
|
||||
* What happens to delivered chunks if the operation later fails?
|
||||
* Do incremental results need resumability?
|
||||
* Should flow control be defined by MCP or delegated to the transport?
|
||||
* How should large binary content, such as generated video, be represented
|
||||
efficiently?
|
||||
|
||||
---
|
||||
|
||||
## 6. Content Language Negotiation
|
||||
|
||||
**Open PR** -
|
||||
[transports-wg#42](https://github.com/modelcontextprotocol/transports-wg/pull/42)
|
||||
|
||||
**Outcome:** Allow clients to request a language for human-readable content and
|
||||
servers to identify the language returned. Language selection should happen per
|
||||
request so it can change without creating session state.
|
||||
|
||||
**Approach:** Use stateless language negotiation based on RFC 9110
|
||||
`Accept-Language` and `Content-Language` semantics. The open PR proposes
|
||||
corresponding `_meta` fields and HTTP header mappings. The final design should
|
||||
work across transports while avoiding duplicate wire representations where
|
||||
possible.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* Use standard `Accept-Language` matching rather than defining a custom
|
||||
algorithm.
|
||||
* Define which fields are user-facing, model-facing, or machine-interpreted and
|
||||
which categories may be translated.
|
||||
* Never translate identifiers, names, URIs, enum values, or other
|
||||
machine-interpreted data.
|
||||
* Allow clients and servers without language-negotiation support to continue
|
||||
operating normally.
|
||||
* Define consistent language metadata across transport bindings.
|
||||
* Ensure language-aware responses interact correctly with caching and primitive
|
||||
versioning.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* Which model-facing fields, such as descriptions, may be translated?
|
||||
* Should language be represented in `_meta`, HTTP headers, or mapped between
|
||||
them?
|
||||
* How should language affect cache keys, validators, and primitive versions?
|
||||
* Does language negotiation require errors beyond the standard header-mismatch
|
||||
error?
|
||||
* How should content-language rules apply to error messages?
|
||||
* Do we need guidance for evaluating tool-selection behavior across languages?
|
||||
|
||||
---
|
||||
|
||||
## 7. Tool Capability Requirements
|
||||
|
||||
**Open PR** -
|
||||
[transports-wg#31](https://github.com/modelcontextprotocol/transports-wg/pull/31)
|
||||
|
||||
**Outcome:** Allow clients to identify tools that require capabilities they do
|
||||
not support before presenting those tools to the model. Tool lists should remain
|
||||
client-independent and cacheable.
|
||||
|
||||
**Approach:** Servers annotate tools with their required client capabilities
|
||||
using `requiredCapabilities` in `_meta`. Clients compare those requirements with
|
||||
their capabilities and decide whether to filter, disable, or expose each tool.
|
||||
Servers validate the requirements again when the tool is called.
|
||||
|
||||
Tools that can operate without a capability do not declare it as required.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
* Support requirements for core and extension capabilities.
|
||||
* Use annotations only for capabilities required for the tool to operate.
|
||||
* Return the same tool list to every client without requiring clients to
|
||||
disclose their capabilities.
|
||||
* Keep capability-dependent presentation a client responsibility.
|
||||
* Require servers to validate capabilities when a tool is called.
|
||||
* Return a standard protocol error when a required capability is unavailable.
|
||||
* Preserve compatibility with clients that ignore the annotation.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* Should clients filter unavailable tools, show them as disabled, or allow calls
|
||||
to fail?
|
||||
* Is client-side filtering sufficient, or is server-side filtering needed for
|
||||
more advanced adaptation?
|
||||
* How should servers advertise fallback or substitute tools?
|
||||
* How should nested and extension capabilities be matched consistently across
|
||||
SDKs?
|
||||
* Should the same requirement mechanism apply to prompts or resources?
|
||||
* If server-side filtering is supported, how should capability-dependent lists
|
||||
interact with caching and primitive versioning?
|
||||
|
||||
---
|
||||
|
||||
# Not Planned
|
||||
|
||||
## 8. Sessions / Conversation IDs
|
||||
|
||||
> **Note — not planned for the 2026-12-15 release.** Protocol-level sessions and
|
||||
> the initialization handshake were removed in 2026-07-28. The WG will only
|
||||
> reconsider something session-shaped if compelling, concrete use cases cannot
|
||||
> be addressed by narrower mechanisms. Until that bar is met, this track remains
|
||||
> problem-definition work rather than protocol design.
|
||||
|
||||
**References** - [Sessions Reintroduction Problem
|
||||
Statement](../docs/sessions-reintroduction-problem-statement.md) and [Sessions
|
||||
vs. Sessionless Decision](../docs/sessions-vs-sessionless-decision.md)
|
||||
|
||||
**Outcome:** Determine whether documented needs for correlation, routing, and
|
||||
cross-request state require any new protocol primitives.
|
||||
|
||||
**Approach:** Separate correlation and routing from state scope and lifecycle.
|
||||
Evaluate each against existing mechanisms such as client-carried state, Tasks,
|
||||
caching, and server-minted handles before considering a new design.
|
||||
|
||||
**Requirements for reconsideration:**
|
||||
|
||||
* Identify the specific use cases a proposal addresses.
|
||||
* Explain why existing sessionless mechanisms do not address them.
|
||||
* Keep sessionless operation first-class.
|
||||
* Define creation, expiration, and termination for any stateful mechanism.
|
||||
* Keep routing identifiers visible to HTTP infrastructure.
|
||||
* Avoid overlapping mechanisms for state in Sessions, MRTR, and Tasks.
|
||||
|
||||
**Open decisions:**
|
||||
|
||||
* Does MCP need a routing identifier, a state-scoping context, both, or neither?
|
||||
* If an identifier is needed, should the client or server create it?
|
||||
* Are server-minted handles passed through ordinary tool arguments sufficient?
|
||||
* Should session-like state, MRTR state, and Task state share one mechanism?
|
||||
* Does MCP need explicit mapping to A2A `contextId`?
|
||||
Loading…
Reference in a new issue