Core Maintainer Meeting — March 4, 2026 #2353
kurtisvg
started this conversation in
Meeting Notes - Core Maintainers
Replies: 1 comment
-
|
Update on SEP Votes
(Legend: 🟢 Accept | 🟡 Accept w/ changes | 🔴 Decline) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
MCP Core Maintainer Meeting — March 4, 2026
Attendance:
Quorum was reached with 7 out of 9 Core Maintainers
Meeting Summary
The MCP Core Maintainers met to discuss the addition of refresh token guidance
via SEP-2207, outline priorities for the 2026 roadmap and upcoming June spec
release, and review a new proposal for multi-round trip requests (SEP-2322). The
group also briefly touched on the status of SEP-2243 for HTTP Standardization.
2026 Roadmap & June Spec Release Priorities
The group discussed how to approach the 2026 roadmap, prioritizing items for the
upcoming June spec release. The release has a target milestone of June 30th,
which requires a Release Candidate (RC) to be ready by the end of April.
Key discussion:
communication, not a strict schedule.
work (such as mix-up protection), and tool scopes.
alongside the transport changes.
Action item: Kurtis Van Gent and Den Delimarsky will collaborate to create a
separate document outlining all items targeted for the June release, which will
be reviewed asynchronously in the core maintainers Discord channel.
SEPs Reviewed
SEP-2207: Refresh Tokens Guidance — Ready to Vote
PR:
#2207
What it proposes: Adds missing guidance for refresh tokens to the
authorization page of the specification. It advises MCP clients to keep refresh
tokens confidential, include them in supported grant types, and use the
offline_accessscope to indicate the desire for a refresh token.Decision: The proposal is considered non-controversial and fills an existing
gap in the spec. Wils Dawson confirmed that draft PRs for TypeScript, Python,
and Rust SDKs already mostly conform to this guidance. The group agreed to put
the proposal up for a vote.
SEP-2243: HTTP Standardization — Needs Repeat Vote
PR:
#2243
What it proposes: Standardizes HTTP features within the MCP HTTP Transport.
Decision: The proposal was previously voted "accept with changes". The
maintainers need to hold a repeat vote to confirm acceptance of the recent
revisions.
Open question: The group needs to decide whether to implement a more
complex, generalized solution for mirroring any field in the request as an HTTP
header (which relies on JSON path) or stick to a simpler solution that addresses
immediate needs. This will be discussed at the next meeting.
SEP-2322: Multi-Round Trip Requests — Ready to Vote
PR:
#2322
Sponsors: Mark Roth, Gabriel Zimmerman, and Caitie McCaffrey.
What it proposes: Generalizes a solution for server-side requests within the
context of a client-side request (e.g., tool call elicitations). It eliminates
the need for complex state sharing by introducing two workflows:
request, asks the client for input, and the client retries a brand new,
independent request with the new data and a
request stateobject.API. The client initiates a tool call, receives a task ID, and polls for
state updates.
The proposal also advocates for making tasks mandatory (non-optional) across the
protocol to reduce compatibility matrix complexities.
Decision: The core maintainers generally supported the proposal and its
direction to shift some burden to the client. The group agreed to put it up for
a vote to signal intent (anticipating an "accepted with changes" result).
Action item: Before finalizing, the group will build a reference
implementation in at least one SDK to work out bugs and clarify requirements for
client developers. Mark Roth will also update the SEP to specify that URL mode
elicitations will only be handled via the persistent workflow.
Links
Guidance
Standardization
Requests
Beta Was this translation helpful? Give feedback.
All reactions