Proposal: Make MCP identifiable on first request (media type and/or header)

Background

MCP over HTTP/WS currently requires a proxy or middleware to parse request bodies in order to recognize the protocol.
Specifically, the initialize request has no MCP-specific header or media type. This creates challenges for:

• Network inspection / observability tools that need to classify or block MCP traffic.
• Enterprise gateways that route traffic based on protocol/application type.
• Performance-critical proxies handling billions of packets that cannot afford deep JSON body scans.

From the second request onward, fields like MCP-Session-Id and MCP-Protocol-Version make classification trivial — but the very first initialize request is opaque.

Problem

• The first request to an MCP server is indistinguishable from arbitrary JSON-RPC traffic (Content-Type: application/json).
• Proxies must wait until initializeResult or parse full JSON to confirm MCP, which is computationally expensive at scale.
• Lack of first-packet signal reduces visibility and complicates security policies.

Proposal

Introduce one or more distinguishable signals that appear in the first MCP request, without requiring body parsing:

1. Media type

   • Define a JSON subtype for MCP:
     • Content-Type: application/mcp+json
     • (or application/vnd.mcp+json initially → graduate to IANA application/mcp+json).
   • Example client request:

     Content-Type: application/mcp+json
     Accept: application/mcp+json, application/json
     

2. New header (structured fields, RFC 8941)
   MCP: ver="`2025-06-18`", client="`acme/1.2.3`"

• Lightweight, compressible, greppable.
• Distinct from MCP-Protocol-Version (which is only present after init).

3. (Optional) Well-known endpoint

• Define /.well-known/mcp for initialization.
• Makes MCP endpoints discoverable and trivially classifiable.

4. Standardize MCP-Protocol-Version as a header on all requests (including initialize)

• Today, MCP-Protocol-Version only appears after initialization.
• If required from the very first request, this gives an immediate and unambiguous protocol identifier.
• Example:

  MCP-Protocol-Version: 2025-06-18
  

• Pros: simple, consistent, no new IANA registration needed.
• Cons: slight duplication (also exists in params.protocolVersion inside JSON).

5. Transport-specific signals

• WebSocket: Sec-WebSocket-Protocol: mcp.2025-06-18
• SSE: Content-Type: text/event-stream; mcp=1

Example (HTTP)

POST /.well-known/mcp HTTP/1.1
Host: api.example.com
Content-Type: application/mcp+json
Accept: application/mcp+json, application/json
MCP: ver="2025-06-18", client="acme/1.2.3"

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
"protocolVersion":"2025-06-18",
"clientInfo":{"name":"acme","version":"1.2.3"},
"capabilities":{...}
}}

Alternatives considered

• Do nothing → Proxies continue deep-parsing JSON (costly, ambiguous).
• Heuristic detection → Match "method":"initialize" + "protocolVersion" in body (not robust, false positives).
• TLS/ALPN or HTTP/2 SETTINGS → Strong but heavyweight, requires deeper ecosystem changes.

Backwards compatibility

• Servers should continue to accept application/json and missing MCP headers for legacy clients.
• New clients SHOULD send the distinguishing signal; servers MAY warn if absent.
• Migration path: start permissive, move towards recommending signals in spec.

Benefits

• ✅ Zero-cost protocol classification on first request.
• ✅ Easier observability, security, and policy enforcement.
• ✅ Standards-aligned (IANA JSON subtypes, RFC 8941 Structured Fields, RFC 8615 well-known URIs).
• ✅ Works consistently across HTTP, WebSocket, and SSE transports.

Next steps

• Decide on preferred approach (media type, header, or both).
• Register media type with IANA.
• Update MCP spec examples to show application/mcp+json + MCP: header.
• Add WebSocket subprotocol guidance.