SEP 2357: Dedicated structured media type for MCP HTTP transport#2357
SEP 2357: Dedicated structured media type for MCP HTTP transport#2357rvmillett wants to merge 3 commits intomodelcontextprotocol:mainfrom
Conversation
…a type Proposes a dedicated structured media type for MCP HTTP transport to enable infrastructure-layer identification of MCP traffic without JSON body parsing. Motivated by: - Documented interoperability bugs across Java, Python, and TypeScript SDKs caused by ambiguous application/json content negotiation - Enterprise governance requirement to identify MCP traffic at the proxy/gateway layer for DLP, WAF, and audit policy enforcement - Transport WG roadmap (2025-12-19) explicitly targeting header-based routing for load balancers and API gateways Complements SEP-1961 (security headers) and SEP-1960 (.well-known discovery). Aligns with proposed Mcp-Method/Mcp-Tool-Name routing headers by answering the prior question: "is this MCP traffic at all?" Zero breaking changes. application/json remains accepted throughout the proposed transition period.
Renames seps/0000-mcp-content-type.md to seps/2357-mcp-content-type.md and updates the SEP number in the document header per the SEP submission process. No content changes.
|
@shaun-smith @kurtisvg — tagging you as Transport WG maintainers. |
|
@rvmillett has this SEP been discussed with the Transports WG prior to submission? There is quite a bit of work that @kurtisvg, @CaitieM20, and others are driving around some architectural changes already. |
|
This hasn't been discussed with the Transport WG yet. Can we find a meeting time you are able to attend and we'll discuss with the group? |
Full transparency — I was spending my day getting up to speed on the AI ecosystem, security considerations, and MCP specifically. In the process, this gap jumped out at me as I was reading the December roadmap post. I drafted the SEP with Claude's help to make sure I got the technical framing right. I don't have deep context on what the Transport WG is already working on, but I'm happy to join a meeting. My interest is in the viability of an MCP Proxy/Gateway. |
|
Some quick thoughts after reading through the SEP: This change might be warranted, as other protocols like gRPC do seem to use their own content type. However, I'm not sure the motivations in the SEP are particularly compelling to me currently:
I think these are effectively the same point (which is it's useful to know it's MCP traffic), but I'm not sure why you couldn't just look for the
The spec currently does say:
And it's not clear to me that the examples you iterate (specifically One additional concern I didn't see highlighted: If today you have a strict firewall that operates on an allowlist (that includes application/json), switching to an mcp specific content type would cause it to be dropped. I don't know how much of a real concern this is, but probably worth further investigation. |
|
Regarding points 1 & 2 being the same, your scrutiny is fair. The MCP-Protocol-Version header identifies the sender as an MCP participant. Content-Type identifies what the body is and how it should be handled — a distinct and complementary assertion. Per RFC 7231, Content-Type is the correct HTTP mechanism for payload type declaration. Using MCP-Protocol-Version to imply payload type repurposes a session metadata header as a content descriptor, which works in practice but conflicts with HTTP's intended semantics. The goal of application/mcp+json is not just traffic identification — it's establishing the correct semantic contract for how MCP message bodies should be declared and handled by any conforming HTTP implementation. Regarding point 3 — I concede. The Regarding the firewall allowlist concern — this is the normal lifecycle of content type standardization. The standardization is precisely what gives infrastructure operators a stable, IANA-registered type to add to their allowlists. The phased transition in §3.7 ensures no breaking change before adoption reaches that threshold. |
Added authors name.
Proposes a dedicated structured media type for MCP HTTP transport to enable infrastructure-layer identification of MCP traffic without JSON body parsing.
Motivated by:
Complements SEP-1961 (security headers) and SEP-1960 (.well-known discovery). Aligns with proposed Mcp-Method/Mcp-Tool-Name routing headers by answering the prior question: "is this MCP traffic at all?"
Zero breaking changes. application/json remains accepted throughout the proposed transition period.
Motivation and Context
How Has This Been Tested?
Breaking Changes
Types of changes
Checklist
Additional context