Skip to content

SEP-2243 HTTP Standardization - #2243

Merged
kurtisvg merged 33 commits into
modelcontextprotocol:mainfrom
mikekistler:mdk/http-standardization-sep
Apr 15, 2026
Merged

SEP-2243 HTTP Standardization#2243
kurtisvg merged 33 commits into
modelcontextprotocol:mainfrom
mikekistler:mdk/http-standardization-sep

Conversation

@mikekistler

Copy link
Copy Markdown

Motivation and Context

This PR introduces a SEP for incorporating HTTP features into the HTTP Transport that support processing by "middle boxes" on the internet, for tasks like routing, tracing, and priorization.

How Has This Been Tested?

I have a reference implementation built on the C# SDK that illustrates the basic features in this SEP.

https://github.com/mikekistler/csharp-sdk/tree/mdk/http-standardization

Breaking Changes

All changes are gated by protocol version and thus not breaking.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

This PR was previously reviewed in the Transports Working Group and updated to address their feedback.
It has been approved to proceed to review by the core maintainers.

@mikekistler mikekistler changed the title SEP-xxxx HTTP Standardization SEP-2243 HTTP Standardization Feb 13, 2026
Comment thread seps/2243-http-standardization.md

@SamMorrowDrums SamMorrowDrums left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is cool, I’d consider splitting out the extension from this proposal and making it separate because I think there’s little to no controversy in the method based routing part of the proposal. Virtually all my questions/comments pertain to the extended part.

I say that as somebody with existing production use-cases for extension as I mention in a comment, where I'm currently double parsing json.

Comment thread seps/xxxx-http-standardization.md Outdated
Comment thread seps/2243-http-standardization.md
Comment thread seps/2243-http-standardization.md
Comment thread seps/2243-http-standardization.md
Comment thread seps/2243-http-standardization.md
Comment thread seps/2243-http-standardization.md
Comment thread seps/2243-http-standardization.md
Comment thread seps/xxxx-http-standardization.md Outdated
Comment thread seps/xxxx-http-standardization.md Outdated
Comment thread seps/2243-http-standardization.md
Comment thread seps/2243-http-standardization.md
Comment thread seps/xxxx-http-standardization.md Outdated
Comment thread seps/xxxx-http-standardization.md Outdated
Comment thread seps/2243-http-standardization.md
@CaitieM20

Copy link
Copy Markdown
Contributor

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

@SamMorrowDrums SamMorrowDrums left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikekistler thanks for thoughtful changes, looking good to me!

kurtisvg
kurtisvg previously approved these changes Mar 2, 2026
Comment thread seps/2243-http-standardization.md
Comment thread seps/xxxx-http-standardization.md Outdated
@kurtisvg kurtisvg self-assigned this Mar 4, 2026
@sep-automation-bot sep-automation-bot Bot added draft SEP proposal with a sponsor. and removed proposal SEP proposal without a sponsor. labels Mar 4, 2026
@sep-automation-bot

Copy link
Copy Markdown

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.

@SamMorrowDrums

Copy link
Copy Markdown
Contributor

@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?

@kurtisvg

Copy link
Copy Markdown
Contributor

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

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

@kurtisvg

Copy link
Copy Markdown
Contributor

/lgtm

This was referenced Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

final SEP finalized. roadmap/transport Roadmap: Transport Evolution & Scalability (incl. Server Cards) SEP

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.