This was voted on by core maintainers on 2/19 as Accept with Changes.

State Transition: proposal → draft

This SEP has been transitioned from proposal to draft.

@kurtisvg has been assigned as the sponsor for this SEP.

This is an automated message from the SEP lifecycle bot.

@kurtisvg I tagged you to review #2355
and @mikekistler I think you'd find it interesting too, because in a sense this is something where it might go the other way:

• we can add such a recommendation to http spec already
• we can eventually look at communicating the same data in a different place (such as initialization) for other transports

This PR sets a precedent for JSON RPC duplication in headers, and in my mind it's not crazy to propose the other direction so we can lean into the http transport for stuff it is already good at we are not using.

Unlike auth, where there are complex reasons to keep it in the transport, i18n feels a simple case.

Curious if you agree or have thoughts?

Here are the final vote after discussion in 3/4 Core Maintainer's meeting:

• SEP-2243: HTTP Standardization
  • Outcome: Accept
  • Votes: 🟢 7 | 🟡 0 | 🔴 0

/lgtm

Hi, we're currently implementing this SEP in the Go SDK (modelcontextprotocol/go-sdk#915). I have two requests for clarification:

1. This functionality is specific to the streamable transport. For this reason, I believe the SDKs should try to contain the logic in the streamable transport layer as much as possible. However, the spec defines filtering tools with incorrect x-mcp-header annotations in the general sections about tools. This prevents us from handling the filtering on the transport level, as according to the current text in the spec STDIO should also follow this process, even though the annotations have no effect in it. Should the wording be adjusted to make this functionality apply only to the streamable transport and not affect STDIO at all?

2. It's not clearly stated in the spec that the x-mcp-header annotations should apply only to top-level properties in tool's arguments. I would propose to make it explicit, as the only place that suggests this is the intention is the planned conformance test that lists nested property annotation as an error scenario.

Regarding x-mcp-header only applying to top-level properties, I don't think this restriction is intended so I think the fix is in the conformance tests, to not treat this as an error.

And three more questions coming from implementation:

3. Is it really required to support case insensitive matching of the =?base64? prefix? Again, it seems that the SEP body and specification changes do not suggest this (and header values are supposed to be case sensitive), but the conformance test description contains such case with a note that it should be accepted by the server.
4. Both our and the C# implementation seem to make use of a tool schema cache that is filled when ListTools is called. I believe we should align on a cross-SDK approach what should happen if the tool being called is not in such cache (either ListTools was not called beforehand or stale information was used). Would returning an error in such case make sense? Quietly calling ListTools from within CallTool sounds like a bad idea and without the schema the client may not fulfill the MUST to send the headers.
5. Numbers in tool arguments are supposed to be "Converted to decimal string representation" and servers are supposed "match the corresponding values in the request body" and "reject requests with a 400 Bad Request HTTP status if any validation fails". Number <-> string conversion is not as well defined as e.g. bool <-> string and some small differences are likely to appear. Should "42" and "42.0" be considered matching?

3. Is it really required to support case insensitive matching of the =?base64? prefix?

This also seems like a bug in the conformance test. I would say that should be case-sensitive matched only.

4. what should happen ... if ListTools was not called beforehand

This is an interesting case! One possibility is that the SDK catch the error response and if the error is for missing headers only then issue the tools/list to get the inputSchema and then redrive the tools/call with the updated schema.

5. Number <-> string conversion is not as well defined

Another interesting detail. I do you expect that the values will be compared as strings or as numbers? If as numbers, I wonder if "numerically equal within some precision", like 1E-6, would be sufficient.