MCP Core Maintainer Meeting - September 30, 2026 #3407

Attendees

• Peter Alexander (@pja-ant), facilitator
• Den Delimarsky (@localden)
• David Soria Parra (@dsp-ant)
• Paul Carleton (@pcarleton)
• Caitie McCaffrey (@CaitieM20)
• Clare Liguori (@clareliguori)
• Kurtis Van Gent (@kurtisvg)
• Nick Cooper (@nickcoai)

Purpose: Close out Amsterdam follow-ups, review SEP-3398 (release cycle) and SEP-2792 (per-request language preference), preview SEP-3392 (extension lifecycle) and the triggers and events proposal, and decide how release managers get picked.

Key Decisions

1. Amsterdam follow-ups

• Notes from the September 15 core maintainer meeting and the September 16 maintainer day are published and linked in Discord.
• The release-process changes agreed in Amsterdam are written up as SEP-3398 (item 3). @localden and @kurtisvg will put out a blog post and announcement once the SEP is accepted.

Outcome: Notes are out. Release-cycle communications wait for SEP-3398.

2. Review queue: scheduling and pre-SEP requests

• Getting a SEP onto a meeting agenda in the voting tool takes three transitions (draft, in review, queued) before it can be scheduled. @kurtisvg ran into this with SEP-3398 and @pcarleton with SEP-3371 for next week. @dsp-ant will simplify the path from draft to scheduled.
• @clareliguori asked how a working group gets early direction from core maintainers before a SEP exists. Agreed: the WG lead writes the question down (a doc, a PR, or a decision record in the WG repo) and puts it in the same queue. An item can be scheduled more than once before any vote. @kurtisvg will add this to the pre-review section of SEP-3398.
• Requests for the voting tool itself go in as issues on the voting repo.

Outcome: Pre-SEP direction requests use the existing queue with a written artifact. Tooling requests are issues on the voting repo.

3. SEP-3398 Release Cycle Updates: dates set, vote next week

• @kurtisvg presented the SEP: planning opens eight months before a release, core review runs from six months out to the soft freeze at two and a half months, tier-1 SDK betas follow at one and a half, hard freeze at one month. Working group leads put SEPs into the review queue. A primary and a secondary release manager run the SEP schedule for each release.
• Release dates are end of March and end of September. The April conference does not fit the March planning window and the group does not want conference-driven development, so in-person planning happens once a year at the September event and the March release gets lighter asynchronous planning. @clareliguori asked about moving the 2028 conference; @dsp-ant expects organizers to keep April and September or October.
• Proposals as pull requests in WG repos: only the transports WG does this today. @localden wants it required for consistency and discoverability; @CaitieM20 and @kurtisvg agreed. @pcarleton will look at limiting who can open PRs and issues in WG repos to collaborators (@localden has an Action that closes issues from non-members).
• Voting versus soft freeze: the last vote on a SEP for a release happens at least a week before the soft freeze. Soft freeze means the SEP is merged with conformance tests in, which is when SDK work starts in earnest. No votes on freeze day.
• The SEP text says core maintainer meetings run every two weeks. Whether the weekly meeting stays was not settled.

Outcome: @kurtisvg updates the SEP (end-of-month dates, voting deadline relative to soft freeze, written artifact for pre-review requests). Comments this week, vote next week.

4. Release managers: one-week self-nomination, then a vote

• Luca Chang (@LucaButBoring) has volunteered and Ola Hungerford (@olaservo) was suggested. @dsp-ant proposed overlapping pairs so one manager always carries into the next release, the way the PHP project does it.
• @kurtisvg pointed out that the SEP calls for self-nomination and a vote, so the slot has to be opened to all maintainers first.
• New release managers will need onboarding sessions and a shared channel.

Outcome: @dsp-ant posts a self-nomination call in the maintainer chat with a one-week window; vote next week. @localden creates a release-manager Discord channel.

5. SEP-2792 Per-Request User Language Preference: to a vote

• @dsp-ant, neutral to slightly negative: there is no data showing model-quality gains from localized responses, models already translate human-visible strings well, and the convincing cases (contractual wording, MCP Apps UI) are narrow. Servers can ignore the hint, so it is not a binding constraint. SDKs would reimplement header parsing and negotiation outside HTTP, and if HTTP-over-stdio lands, Accept-Language comes for free. A query parameter covers most cases today.
• @nickcoai: align with web standards without relitigating each header. Accept-Language is widely deployed, and accepting it now is compatible with an HTTP-over-stdio end state, so ordering does not matter. MCP Apps already passes locale and user location in _meta, used mostly for unit conversion. A client can put a _meta field there today, but nothing makes servers honor it.
• @kurtisvg: MCP should be explicit about which HTTP semantics it supports (the caching work ran into the same question with ETags). The SEP also says which fields may be localized (descriptions yes, names no), and that part is worth standardizing on its own. About 20% of published open-source skills are not in English.
• @CaitieM20: skills are model input, not human-facing text, so localizing them means per-language evals. @nickcoai: skill resources such as templates still have a localization case.
• @clareliguori: instead of one SEP per header, write a policy on which standard HTTP headers a server may honor.
• HTTP-over-stdio: discussion after maintainer day converged on pursuing it, but a Node prototype ran into servers that log to stdout, and it is not yet clear every language can implement it. It will not land next month. @kurtisvg owes a write-up of where that landed.
• @kurtisvg: vote now instead of holding. If there is no clear consensus, ask Sam Morrow (@SamMorrowDrums) for more usage data from MCP Apps and skills.

Outcome: The vote on SEP-2792 opened during the meeting. @dsp-ant will circulate the additional usage data.

6. SEP-3392 Extension Lifecycle: async review, vote next week

• @pja-ant: extensions start experimental, move to beta by core maintainer vote (adoption feedback; breaking changes still allowed but expected to be rare), then to stable or into core by a second vote, after which they follow the core release schedule and its compatibility guarantees.
• @kurtisvg asked how clients negotiate across breaking changes during beta. The SEP carries a version tag in the extension's capability.
• @pcarleton: existing extension repos mix stable and unstable parts, and tasks wants the same. @pja-ant will move the stage marker from the repo level to subfolders (stable spec, beta spec). @clareliguori wants stability expressed at the capability level so a client can opt in or out of unstable parts; @pja-ant noted the client already chooses which capabilities it sends, and tasks is splitting into several capabilities.
• @pcarleton: get comments from the MCP Apps working group, which is the most constrained by this.

Outcome: Comments on SEP-3392 this week, vote next week. @pja-ant updates the SEP.

7. Triggers and events: draft SEP, aiming for beta

• @pja-ant: the design sketch has had a good reception and there is already an early host implementation. He will turn it into a draft SEP and add it to the queue, bringing it in as a beta extension under the new lifecycle so it can gather feedback without a stability commitment.
• @nickcoai: early implementations will realign as the spec firms up. He also raised an open MCP Apps question: some hosts carry native application hooks that MCP Apps did not adopt, and part of that (for example, knowing an app wants full screen before the MCP connection opens) belongs in app registration, outside MCP.

Outcome: @pja-ant files the draft SEP. Everyone reviews the design sketch and comments.

8. Next week

• Votes: SEP-3398, SEP-3392, release managers. The SEP-2792 vote is already open.
• @pcarleton runs a session on working the SEP queue. SEP-3371 should be ready for review.

Actions

• @kurtisvg: Update SEP-3398 with end-of-March and end-of-September dates, last vote at least a week before soft freeze, and a written artifact for pre-review requests.
• @kurtisvg: Write up where the HTTP-over-stdio discussion landed.
• @dsp-ant: Post the release-manager self-nomination call in the maintainer chat (one-week window) and schedule the vote.
• @dsp-ant: Circulate the language-preference usage data.
• @dsp-ant: Simplify the draft-to-scheduled transition in the voting tool.
• @localden: Create the release-manager Discord channel.
• @localden, @kurtisvg: Blog post and announcement on the release cycle once SEP-3398 is accepted.
• @pcarleton: Work out how to limit PR and issue creation in WG repos to collaborators.
• @pja-ant: Update SEP-3392 (stage per subfolder, capability-level stability) and ask the MCP Apps working group for comments.
• @pja-ant: Turn the triggers and events design sketch into a draft SEP and queue it.
• Core maintainers: Comment on SEP-3398 and SEP-3392 this week; vote on SEP-2792; file voting-tool requests as issues on the voting repo.
• Open: Weekly versus biweekly meeting cadence under the new cycle.