MCP Six-Month Release Cycle: What SDK, Server and Client Teams Should Plan For

The MCP release cycle is now a calendar. In its post of November 11, 2026, the Model Context Protocol project said specification releases move to a regular six-month schedule, generally the last Tuesday of March and September. The next target is March 30, 2027, as version 2027-03-30. The process comes from SEP-3398, which the project's own page lists as Accepted on October 14, 2026.

If you run an existing client or server, nothing needs to change because of the announcement. The maintainers say it changes how a release is prepared, not MCP messages or version negotiation. What you get is a set of dates to plan against, and the useful ones are the soft freeze, the Tier 1 SDK betas and the hard freeze, not the release day itself.

This post turns SEP-3398 into a planning calendar and a now-versus-later checklist. Everything is as of November 12, 2026, and every date marked "indicative" is our arithmetic from the SEP's month offsets, not a date the project has published.

The short version

Who this is for

You maintain an MCP SDK, a server, or a client or host application, or you lead a team that builds on MCP and needs to know how often it will cost you work. The checklist below splits by role. For what changed in the 2026-07-28 revision itself, read our 2026-07-28 specification explainer.

How we checked this

On November 12, 2026 we opened the official announcement, the SEP-3398 page, the SDK tiering and feature lifecycle pages, the deprecated-features registry, the versioning guide, the project roadmap, the Core Maintainer meeting notes from September 15, 2026, the two earlier release posts, and the project's release tracker. We cross-checked the announcement text against SEP-3398 and two search tools.

We did not test any SDK, because no beta exists yet. We did not find a published transition calendar with exact deadlines, so every date in this post other than the 2027-03-30 target is derived from month offsets. Where two official pages disagree, we say so. Oakgen is our product, and this topic is infrastructure, not an Oakgen feature.

What the announcement actually changes

Three things, and only three.

A fixed rhythm. Releases are date-driven. The September 15 Core Maintainer notes say "Work that is not ready rolls to the next release; the date does not move." The announcement repeats it. A proposal that is not ready moves to a later release rather than delaying the whole spec.

An eight-month cycle that overlaps. Each release is planned for eight calendar months and published every six, so planning for the next release overlaps the last two months of work on the current one. The announcement says the March 2027 release is "just a little different" because some of the planning concluded in August 2026.

A Release Manager role. The post names Den Delimarsky and David Soria Parra, with Luca Chang joining for the next cycle. SEP-3398 describes a primary and a secondary manager, with the secondary becoming primary for the following cycle. We did not find which of the three holds which role.

What does not change is the wire. The announcement says specification versions continue to use dates, and the versioning guide says the identifier marks the last date a backwards-incompatible change was made.

Why March 2027, not December 2026

The August 12 plan was a December 15, 2026 release. The September 15 notes say that date put the soft freeze in mid-October with review starting at once, and that several roadmap items, file uploads among them, "need more runway." The group moved to March 2027, and chose March and September because they avoid year-end and mid-summer and line up with the community event calendar.

One loose end is worth knowing about. On November 12, 2026 the project's release tracker still listed a version 2026-12-15 as "NOT READY" with zero SEPs scoped. The announcement and SEP-3398 supersede it. If a vendor or an internal dashboard shows December 15, it is stale.

The planning calendar

This is the part we built so you do not have to do the month arithmetic yourself. The first column is the SEP-3398 offset. The date columns apply that offset to the two release days and are indicative, because the SEP says the release managers' published calendar sets exact deadlines.

By the same arithmetic the third release falls on 2028-03-28, and the SEP says planning for it begins in late July 2027.

Two checks on the table. The last Tuesday of March 2027 is March 30 and the last Tuesday of September 2027 is September 28, both by calendar arithmetic. The September date does not appear in the announcement text. It appears only in the description of the timeline image on that page.

What last cycle tells you about lead time

The 2026-07-28 revision is the only recent release we can use as a baseline.

The SDK beta post of June 29, 2026 said all four Tier 1 SDKs then had betas for the release candidate, and the July 28 release post said all four Tier 1 SDKs spoke 2026-07-28 that day. So the baseline is a beta four weeks ahead and a same-day stable. The new schedule is meant to give you about two more weeks. That is a modest improvement, not a transformation, and the September meeting notes admit the underlying worry. SDKs get little real use until after the hard freeze, "when change is hardest."

What it means by role

SDK maintainers

Tier 1 SDKs must publish stable support before the specification is published, and publish betas for the frozen scope 1.5 months out. Beta notes should name the target release, available functionality, known gaps and where to report feedback, and maintainers provide conformance results and blockers to the release managers.

Three rules are easy to miss.

• A late SDK does not move the spec. The announcement says the gap will be documented, and SEP-3398 adds that a delay does not automatically change that SDK's tier.
• Extensions and experimental features stay outside the mandatory beta scope for Tier 1. The SDK tiers page says Tasks and MCP Apps are not required for any tier.
• Conformance still bites. The tier page says a Tier 1 SDK can drop to Tier 2 if any conformance test fails continuously for four weeks.

The notes from September 15 also record an intent to announce each accepted SEP on a mailing list and a Discord channel, and to open a tracking issue in each SDK repository on acceptance. That was an action item, not something we confirmed is live. SEP-3398 says SDK work should begin at acceptance, not at soft freeze.

Tier 1 today means TypeScript, Python, C#, Go, Rust and Ruby, per the Ruby SDK's Tier 1 announcement of October 30, 2026. Tier 2 is where a cadence of two releases a year matters in a way the announcement does not spell out. The tier page lets a Tier 2 SDK add new protocol features within six months, which is now exactly one release cycle. That is our reading, not the project's. A Tier 2 SDK that uses the full window will ship a revision just as the next one lands.

Server maintainers

Your server is on the receiving end of a cadence, not a deadline. The practical points are these.

• You have no obligation to move on release day. Clients and servers may support several protocol versions at once, and each request declares the version it uses.
• A server that gets a version it does not implement answers with an UnsupportedProtocolVersionError that lists the versions it supports, so the client can choose another.
• Your real deadlines are the project's deprecations. Roots, Sampling, Logging and Dynamic Client Registration were deprecated in 2026-07-28, and the registry lists their earliest removal as the first revision released on or after July 28, 2027.

That last point answers a question many teams will ask in January. By the project's own clock, a release on March 30, 2027 cannot remove those features. The first release that could is the September one, and the lifecycle page says eligibility is not a decision. The policy does allow a shortened window, never under 90 days, for an active security risk.

One disagreement between official pages is worth flagging. The July 28 release post describes a year-long offramp for the older HTTP+SSE transport, while the deprecated registry lists its earliest removal as three months after SEP-2596 reaches Final. If you still serve SSE, read the registry entry before you set a retirement date.

Client and host maintainers

You carry the version matrix. The September meeting notes record a concern that each release grows the client-server version matrix, and one camp argued that six months is already fast for a protocol where implementers run production systems.

For clients, the beta window is the main benefit. The announcement asks the community to try betas "with the clients and servers they already run" while corrections can still go into the release. That is the cheapest time to find a break. Bring your gateway or load balancer into that test, because routing assumptions are where stateless changes tend to show up, and the July beta post gave the same advice.

Proposal and extension authors

The calendar is strict about what counts as ready. At soft freeze a proposal must be Final and merged, which the SEP defines as specification text, schema changes, a changelog entry, a completed reference implementation and the conformance tests required by SEP-2484. Acceptance alone does not meet the cutoff.

The review path has its own lead time. Formal reviews pick an agenda two weeks before a Core Maintainer meeting, comments run during the preceding week, and then comes a recorded seven-day vote that must conclude before the freeze. The September notes tell Working Groups to queue items four to six weeks ahead. Counted back from an indicative mid-January soft freeze, that puts the practical queue date for March in early December 2026. That date is our arithmetic.

Extensions keep their own publication lifecycle, though their review timing follows the same window.

Platform, gateway and procurement teams

Expect new revisions twice a year at most, with no forced migration on release day. Budget one planning review per release at soft freeze, when the release managers publish the frozen scope and the deferred proposals.

Now versus later checklist

This is the original asset in this post. Dates marked "indicative" come from the calendar above.

Do now (November and December 2026)

• Write the six dates from the calendar into a shared team calendar, labelled indicative, with one named owner.
• Decide which of the two 2027 releases you actually plan to adopt, and write down that you are not adopting by default.
• If you have not moved to 2026-07-28, plan it as its own project. The cycle announcement does not replace it, and the SDK migration guides cover it.
• List every use of Roots, Sampling, Logging and Dynamic Client Registration in your code, and note the migration path the registry names for each.
• Add upper bounds on major SDK versions in any library you publish, as the July beta post advised library authors to do for the Python mcp package.
• If you write proposals, get queued by early December for the March release, and make sure conformance tests are in the plan.
• Check the release managers' published calendar once a week until exact dates appear.
• Remove any internal reference to a December 15, 2026 release.

Do at soft freeze (indicative mid-January 2027)

• Read the frozen scope and the list of deferred proposals the release managers publish.
• Compare the scope with your own backlog and mark each frozen item as affects us, may affect us or no effect.
• Decide whether the release is large enough to need a project. The version string will not tell you.

Do at beta (indicative mid-February 2027)

• Install the Tier 1 beta for your language in a branch and pin the exact version, as the July beta post advised.
• Run real traffic through it, not just the happy path, and test your gateway or load balancer.
• File findings with the SDK or the specification repository while corrections can still go in.
• Do not move critical workloads to a beta. The July post kept stable releases as the recommendation for those.

Do at hard freeze and release (indicative late February to March 30, 2027)

• Stop adding scope to your own migration branch. Only emergency spec changes can land now, each approved by a full Core Maintainer vote.
• Read the release notes and the migration guidance published on release day.
• Confirm your SDK reached stable support, and if it did not, read the documented gap before blaming your code.
• Set and publish the date you will drop your oldest supported protocol version.

What the roadmap does and does not say about 2027

It is tempting to guess what lands in March. We will not. The project roadmap, last updated August 22, 2026, names five priority areas for the coming six to twelve months, which are agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives, and improved SDK developer experience.

It also says the roadmap reflects "current thinking rather than firm commitments", and that proposals in those areas get expedited review. It does not say which items will be in 2027-03-30. The scope is only knowable at soft freeze, so plan from the frozen list, not from the roadmap.

Common mistakes

Reading "every six months" as "migrate every six months." The official note says there is nothing to change in an existing client or server because of this announcement.

Planning to the release date. The dates that decide your workload are the soft freeze and the beta. Release day is when the work should already be done.

Trusting the version string to size the work. Date-based identifiers do not say whether a release is large or small. The September notes list a signaling convention as an open item. Read the frozen scope instead.

Assuming deprecations disappear in March. The registry's earliest removal for Roots, Sampling, Logging and Dynamic Client Registration is the first revision released on or after July 28, 2027.

Treating "Accepted" as "in the release." A proposal must be Final and merged by soft freeze. An accepted one that misses it waits for a later release.

Putting a beta SDK in production. The beta window exists so you can test, not so you can ship.

How a creative team would apply this

A creative team that uses an MCP server to reach image, video or voice tools is a consumer of this cadence, not a maintainer. Your action is small. Know which protocol version your host and server pair uses, ask each vendor for a date and not a promise, and keep an approval step in front of paid generations. Our MCP security checklist for creative teams covers connector review, and the guide to image generation MCP servers explains the moving parts.

We are in the same position. Our repository depends on the v1 line of the TypeScript SDK (@modelcontextprotocol/sdk ^1.29.0), and our MCP route tests use protocol version 2025-11-25. We have not published a statement about the 2026-07-28 revision, so treat the Oakgen MCP page as the place to confirm what is live. Oakgen is our product.

Decision framework and what I would do

Use the role that describes your job, then follow its default.

What I would do, in order.

I would ignore the release date and put the soft freeze in the calendar. That is the day the scope is real, and it is the earliest day a plan is worth writing.

I would treat the beta as the one mandatory test window, with a pinned version and real traffic.

I would adopt each revision within one cycle of its release, not on release day, and I would publish my support window. The project does not force that choice, but a window you wrote down is cheaper than a negotiation under pressure.

I would not plan any work around a feature that is on the roadmap but not in the frozen scope. Roadmap items are reviewed first, not guaranteed.

What we could not verify

• The exact transition calendar. SEP-3398 says the release managers publish it, and we did not find it.
• Which release manager is primary. The post names three people, and the SEP describes two roles.
• The September 28, 2027 date. It is calendar arithmetic and is not in the announcement text, only in the description of its timeline image.
• Whether the acceptance announcements and SDK tracking issues described in the September 15 notes are live.
• Whether the process will stay unchanged. SEP-3398 says release managers publish a retrospective after the first release under it, and substantive changes follow the SEP workflow.

Bottom line

The cadence is good news for planners. It converts an unpredictable release into two dates a year with published offsets, while changing nothing on the wire. The cost is that you now have to keep a calendar. Put the soft freeze, the beta and the hard freeze into it, wait for the release managers' exact dates, and keep your own support window written down.

Frequently asked questions

When is the next MCP specification release?

The MCP project is targeting March 30, 2027, and says to expect protocol version 2027-03-30 on that day. The official post of November 11, 2026 says specification releases will generally land on the last Tuesday of March and September. SEP-3398 adds that release managers confirm the exact date in each cycle's published calendar, and it calls the March 30 date subject to confirmation in the transition calendar. The release after that falls on the last Tuesday of September 2027, which is September 28 by calendar arithmetic. The September date is our calculation. The only place we saw it on the project's pages is the description of the timeline image in the announcement.

Do I need to change my MCP server or client because of the six-month cycle?

No. The official post says the change affects how a release is prepared, not MCP messages or version negotiation, so nothing needs to change in an existing client or server because of the announcement. Specification versions keep using dates. The cycle does not replace the migration work from the 2026-07-28 revision, which is a separate job with its own SDK migration guides.

What are the soft freeze and hard freeze in the MCP release cycle?

Per SEP-3398, the soft freeze falls 2.5 months before release. Every proposal in the release must be Final and merged by then, including specification text, schema changes, a changelog entry, a reference implementation and required conformance tests. Only fixes, polish and clarifications within that scope are accepted afterwards. The hard freeze falls one month before release. After it, only critical security fixes or release-blocking correctness or interoperability fixes can enter, each approved by a full Core Maintainer vote.

When do the official SDK betas arrive for the next MCP release?

SEP-3398 puts Tier 1 SDK betas 1.5 months before release, which for March 30, 2027 points to roughly mid-February 2027. That is our arithmetic from the offset. The SEP says the published release calendar, written by the release managers, sets exact deadlines, and we did not find that calendar published as of November 12, 2026. Beta notes are meant to name the target specification release, available functionality and known gaps.

What happens to a proposal that is not ready by the soft freeze?

It moves to a later release and the release date does not change. SEP-3398 says an accepted proposal that misses finalization stays Accepted and is tracked for a later release, and a proposal still awaiting a decision returns to the queue. A material redesign needs renewed review. The post frames this as a deferral, not a rejection.

Will Roots, Sampling, Logging or Dynamic Client Registration be removed in March 2027?

Not under the project's own deprecation clock. The deprecated-features registry lists all four with an earliest removal of the first revision released on or after July 28, 2027, and the lifecycle policy says earliest removal marks eligibility, while the actual decision belongs to the Core Maintainers and may come later. A March 30, 2027 release falls before that date. The policy does allow a shortened window of at least 90 days for an active security risk, so check the registry before each release.

Does a faster cadence mean I must support more MCP versions at once?

Not by rule. The versioning guide says clients and servers MAY support several protocol versions at once, and each request declares its version so a server can accept or reject it on its own. How many versions you keep is your policy decision. A practical default is the current revision plus the one before it, and dropping older ones on a date you publish.

Is Oakgen's MCP server on the newest MCP specification?

We have not published a statement about the 2026-07-28 revision for the Oakgen MCP server. Our own repository depends on the v1 line of the TypeScript SDK and its tests use protocol version 2025-11-25. Oakgen is our product, so check the live MCP page for current client support before you rely on any version detail.

Sources

1. Model Context Protocol blog, A More Predictable Release Cycle for MCP, Nov 11 2026 (read 2026-11-12)
2. Model Context Protocol, SEP-3398 Release Cycle Updates, status Accepted 2026-10-14 (read 2026-11-12)
3. Model Context Protocol, SDK tiering system (read 2026-11-12)
4. Model Context Protocol, feature lifecycle and deprecation policy (read 2026-11-12)
5. Model Context Protocol, registry of deprecated features, draft specification (read 2026-11-12)
6. Model Context Protocol, versioning (2026-07-28 docs) (read 2026-11-12)
7. Model Context Protocol, project roadmap, last updated 2026-08-22 (read 2026-11-12)
8. modelcontextprotocol repository, Core Maintainer Meeting notes, September 15 2026, published Sep 30 (read 2026-11-12)
9. Model Context Protocol blog, The 2026-07-28 Specification, Jul 28 2026 (read 2026-11-12)
10. Model Context Protocol blog, Beta SDKs for the 2026-07-28 release candidate, Jun 29 2026 (read 2026-11-12)
11. Model Context Protocol blog, The Official Ruby SDK for MCP Reaches Tier 1, Oct 30 2026 (read 2026-11-12)
12. MCP Spec TPM release tracker, releases list and the 2026-07-28 and 2026-12-15 entries (read 2026-11-12)