MCP

MCP Has a Release Calendar Now: What SEP-3398, Server Cards, and October's Security Wave Mean for B2B Deployments

By IdeaBosqueLast updated: October 31, 2026

Key takeaways

MCP's specification now ships on a fixed calendar — SEP-3398, accepted October 14, 2026, sets releases every six months on the last Tuesday of March and September and moves the December 2026 target to late March 2027.
Server Cards are final — SEP-2127 merged as Final on October 6, 2026, giving MCP servers a standard metadata document for pre-connection discovery of transports, protocol versions, and connection guidance.
31 security advisories hit the official repositories in 28 days — eSEOspace's State of MCP October count, including two criticals in MCP Inspector fixed in the October 21 1.0.3 security release.
Smithery's proxy and managed identity shut down October 31, 2026 — Smithery's own notice retired run.tools and server.smithery.ai server URLs, the month's clearest proof that rented distribution routes are operational risk.
Plan on the 2026-07-28 spec through winter — the stateless core is unaffected; the next release lands late March 2027, so the migration beats are calendar-plannable, not changelog-reactive.

The Smithery MCP proxy and managed-identity service shut down on October 31, 2026 — today. Any agent deployment still resolving servers through run.tools or server.smithery.ai URLs stopped working with it; Smithery's own notice lists what died: the hosted server URLs, the API, Connect and Toolbox, accounts, API keys, and the CLI. The migration fix is the vendor's own endpoint — mcp.linear.app/mcp instead of linear.run.tools — and teams who never had one had to write one today.

In the same 28 days, MCP's maintainers accepted the protocol's first fixed release calendar, merged the Server Cards discovery standard to Final, and — per eSEOspace's count — logged 31 security advisories across the official MCP repositories, with two rated critical in MCP Inspector.

That combination is one transition seen from three directions — timing, discovery, and operations. MCP has stopped behaving like fast-moving glue and started behaving like managed infrastructure. This article reads the October record as a single signal and maps the operating rhythm it implies: pin the spec version, calendar the release beats, keep SDKs on the security track, and stop renting distribution routes.

This builds on MCP 2026-07-28: What the Stateless Protocol Means for B2B Agent Deployments, which covered the stateless core, the explicit-handle pattern, and the July 28 specification's deployment math. Here the focus is what changed around that spec in October — the cadence, the discovery layer, the advisory flow, and the distribution outage. The stateless thesis itself is untouched by any of it.

The October record in one view

Caption: five events in 28 days turned MCP from a rolling spec into a platform with a calendar, a discovery standard, a security-release track, and its first third-party distribution outage.

A release calendar, accepted and then merged

SEP-3398 is a process SEP, and process SEPs rarely make headlines — this one should have. Accepted October 14 and merged October 27, it fixes MCP's release rhythm in writing: specification releases every six months, "generally on the last Tuesday of March and September," with an eight-month working cycle per release — two months of planning, a scheduled Core Maintainer review window, and a stabilization phase — where successive cycles overlap by two months. The transition clause does the rest: the proposed December 2026 release target moves to late March 2027.

For the maintainers this is review-capacity management. For a B2B deployment it is planning infrastructure:

The deprecation windows are now calendar-plannable. Roots, Sampling, Logging, and the deprecated HTTP+SSE transport already carried a 12-month annotation window from the July 28 spec. A fixed calendar turns "12 months from July 28" into a beat on the same roadmap as ERP release windows.
Unfinished work moves, the date does not. Release-bound proposals must be Final and merged by soft freeze; unfinished proposals move to a later cycle without moving the release date. That is the behavior teams expect from platform vendors — predictability over completeness.

The immediate practical statement is the one eSEOspace drew from the October data: no new spec version shipped — the latest is still 2026-07-28, and the calendar moves the next one to late March 2027. The stateless core your deployment targets today is current through winter.

Server Cards: discovery stops being a config file

SEP-2127 (MCP Server Cards) merged Final on October 6 — before the calendar SEP — and closes the second half of the deployment problem. The stateless spec defined how an agent talks to a server once it has connected. Server Cards define how an agent finds a server without manual configuration: a standardized metadata document describing transports, protocol versions, and connection guidance, exposed by the server and readable by clients before any connection opens.

The mechanics, from the SEP itself: each server exposes its card — cards can be hosted at any unreserved URI, with <streamable-http-url>/server-card as the recommended location — under the extension identifier io.modelcontextprotocol/server-card. A domain-level "AI Catalog" can link or embed the relevant cards, which is what makes registry crawling and service auto-detection possible without touching each endpoint by hand.

The B2B parallel is A2A's agent card — .well-known/agent-card.json — which our A2A coverage already treats as table stakes for machine-to-machine discovery. The Server Card is the same idea for protocol servers, and it deletes the artifact most agent deployments maintain today: the hand-written list of server endpoints and their tool schemas. When that list becomes discoverable metadata, the operational posture changes in three ways — new servers announce their own surface; stale endpoints become auditable (a card that no longer matches the live server is a finding); and vendor upgrades stop needing reconfiguration on the client side.

SDK and client support is the SEP's stated next step, so the pragmatic move is to design now: build endpoints with a card location in mind and keep the server list ready to become metadata rather than configuration.

The October security wave: advisories are part of the operating rhythm

The sharpest rows in the October record are security ones, and they read like a platform vendor's patch Tuesday rather than a hobby project's changelog. Two criticals in MCP Inspector shipped on October 21, both fixed in the 1.0.3 security release:

GHSA-6x67-4w4w-9f3w — a remote MCP App can steal the proxy's auth token and execute arbitrary local commands (RCE). Affected versions: Inspector 0.20.0 through 1.0.2.
GHSA-4fc4-wcmh-4g86 — a malicious MCP OAuth callback can switch the transport to stdio and execute arbitrary local commands (RCE). Affected versions: 0.13.0 through 1.0.2.

Outside Inspector, the TypeScript SDK's October advisory is the one with B2B teeth: GHSA-jm63-cq47-j5jp — "shared transport or server instances delivered one HTTP client's messages to another" — rated high, vulnerable from 2.0.0 and fixed in 2.3.0. A shared-transport cross-client data leak is exactly the class of defect that a B2B deployment cannot tolerate, and it landed in the SDK's core package, not an experimental corner.

The release dates tell the platform story as clearly as the severities. Python SDK 2.3.0 shipped October 2 with stricter header checks at tool registration; TypeScript SDK 2.4.0 shipped October 23 adding Skills-over-MCP (SEP-2640) support; Kotlin 0.16.0 shipped October 27 closing memory-exhaustion holes and deprecating SSE (release; the characterization per eSEOspace's release-notes review). Every major official SDK shipped at least once in the month, and per eSEOspace's review the theme through them is hardening: hard limits on request size, session counts, and memory. Their count of advisories across the official repositories — 31 in 28 days — is their own tally, but the shape it describes is verifiable: the security-release track is now continuous, not episodic.

The operator reading is simple. If your MCP estate has an SDK update policy, October is the month the policy had to trigger twice. If it does not, the advisories above are what accumulate.

Smithery: the distribution layer's contract expired

The third event is the one your operations team feels today. Smithery's notice is unambiguous: on October 31, 2026, Smithery shut down its connection management services — which means every run.tools and server.smithery.ai server URL, the hosted proxy path, the API, accounts, API keys, and the CLI stopped working. The smithery.ai directory remains online as a public directory, now powered by Arcade.dev.

The migration is straightforward for servers with vendor-native endpoints — Smithery's own example is pointing at mcp.linear.app/mcp instead of linear.run.tools. It is a scramble for the deployments that built against a proxy as their distribution strategy: no vendor-native URL, no contract for what replaces it in your control plane, and no audit of who is connecting now that the proxy that recorded the traffic is gone.

The lesson generalizes beyond one vendor: if the endpoint your agent fleet resolves MCP servers through belongs to a third party, the endpoint's lifecycle is a dependency you neither chose nor track. October delivered that proof in the same month that the protocol standardized discovery metadata and fixed its own release calendar. The durable position is vendor-native endpoints, per Smithery's own migration guidance, or endpoints your team operates — the buy-vs-build line our MCP server protection analysis draws for the boundary, this record proves for distribution.

The operating checklist for B2B MCP deployments

Caption: six controls that convert October's signal into deployment policy — each maps to a dated event from the month.

#	Control	The October event it answers	What it looks like in the deployment
1	Pin the spec version	No new spec version in October; next release late March 2027	Target 2026-07-28 explicitly; run SDKs that declare that version as supported; review the pin at each calendar beat
2	Calendar the release beats	SEP-3398: last Tuesday of March and September	Put the soft freeze (T−2.5 months) and hard freeze (T−1 month) on the team's roadmap as review windows, not surprises
3	Stay on the SDK security track	31 advisories in October; two criticals in Inspector 1.0.3	Pin SDK floors at the security release (TS ≥ 2.3.0, Inspector ≥ 1.0.3); subscribe to the official repos' advisory feeds
4	Prefer vendor-native or owned endpoints	Smithery's `run.tools` / `server.smithery.ai` EOL on October 31	Inventory every non-vendor endpoint in the server list; terminate proxy-dependent routes or operate them yourself
5	Build for Server Cards metadata	SEP-2127 Final on October 6, SDK/client support ahead	Design endpoints with a card location; keep the server list ready to become discoverable metadata, not configuration
6	Treat registry presence as non-vetted	52,141 servers in the official registry, 66% with remote endpoints (per eSEOspace's count)	A listing is not a security signal; apply the module-approval gate from the governance checklist before a third-party server connects

Where this leaves the 2026-07-28 deployment pattern

The stateless core our earlier analysis set out is the part of MCP that October did not touch — and that is the point worth stating plainly. SEP-3398 re-schedules future releases; it does not disturb the spec you are pinned to through winter. Server Cards add discovery without changing the transport. The advisories harden SDKs on the same protocol version. Smithery's shutdown is a third-party commercial decision, not a protocol event.

If your deployment pattern assumed MCP moves too fast to pin and too young to calendar, October is the disconfirmation record. The teams that convert from changelog-watching to calendar-watching will treat the late-March 2027 release as a scheduled review; the rest will learn about it from a breakage.