MCP Protocol News - November 13, 2026

Week of: November 13, 2026

Overview

The MCP project this week announced a six-month specification release cadence with a March 30, 2027 target, while also revising SEP sponsorship and automation processes. On the implementation side, MCP Servers v2.4.0 shipped security fixes across three servers, and MCP documentation clarified partial MCP Apps support in Inspector alongside an experimental file transfer extension.

Stories

1. MCP Servers v2.4.0 fixes six vulnerabilities across three servers

Source: MCP Servers Link: https://github.com/modelcontextprotocol/servers/releases/tag/v2.4.0

The MCP Servers project released v2.4.0, fixing six vulnerabilities in three servers. The release directs users to upgrade @modelcontextprotocol/server-filesystem to 2.3.0 and mcp-server-git and mcp-server-fetch to 2026.11.11. It lists affected ranges, including all filesystem versions before 2.3.0 and date versions 2025.1.14 through 2026.8.31, plus git and fetch through 2026.11.4.

Server packages are the runtime surface where MCP clients expose tools and resources, so vulnerabilities in filesystem, git, and fetch servers are operationally urgent. The filesystem fixes also change read behavior so reads stay with the file that was checked on Linux and macOS, and read tools and file resources open a file relative to the directory that was checked.

Impact Analysis: Operators should treat v2.4.0 as a required upgrade and re-check pinned server versions in MCP deployments.

2. MCP announces six-month specification release cycle with March 30, 2027 target

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/9a67316897f90f97bcd2ee939ca8e7e1532a27d3

The MCP project published a blog post announcing a six-month specification release cadence from SEP-3398, with a March 30, 2027 release target. It introduces Luca Chang as a release manager alongside Den Delimarsky and David Soria Parra for the next specification cycle. The post explains proposal and SDK milestones and includes a timeline showing the next two specification targets, SDK betas, freezes, and overlapping planning.

A fixed cadence gives SDK authors, server maintainers, and client implementers a schedule for compatibility work instead of reacting to ad hoc releases. Separate proposal and SDK milestones also clarify when experimental work is expected to stabilize. For teams building on MCP, the timeline is now the planning reference for the next two cycles.

Impact Analysis: Teams should map dependency and migration work to the published SDK beta, freeze, and specification target milestones.

3. MCP SEP guidance shifts to working-group sponsorship

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/99a8e4605c4278b6f905c98e585f98b393b15623

A documentation commit updates the SEP process so protocol-change proposals are sponsored through working groups. The previous guidance told proposers to discuss the idea, build a prototype, and then find an individual sponsor—defined as a Core Maintainer, Maintainer, or WG Lead—by consulting MAINTAINERS.md, tagging up to two maintainers, and asking in #general after two weeks without a response. The commit changes that contributor-facing process.

Sponsorship has been a practical gate for SEP authors, and routing it through working groups ties proposals to the groups that own relevant protocol areas. That can reduce dependence on individually recruiting maintainers and make review paths more legible. Builders proposing protocol changes should identify the relevant working group earlier.

Impact Analysis: Proposers should check the revised SEP guidance and seek working-group sponsorship before opening a SEP pull request.

4. MCP publishes early feedback post on experimental file uploads/downloads extension

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/5324218639be4a6c696902d70f98f225326bbe4b

The MCP blog added a post on the work-in-progress file uploads and downloads extension, aimed at gathering early feedback and prototypes from the community. The post explicitly describes the extension as experimental and not approved. The merge notes also called for the extension draft to be merged and for the image placeholder, byline, and publish date to be resolved.

File upload and download are common integration needs that the core protocol has not standardized, so an extension draft is a signal of where client and server implementers may converge. Because it is experimental and unapproved, implementations should expect changes and avoid treating it as a stable compatibility target. Early prototypes are the intended feedback channel.

Impact Analysis: Builders can prototype against the draft but should isolate it behind feature flags and track approval status.

5. MCP Inspector marked as partially supporting MCP Apps

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/a40b29a92906d43f2ffaff8c9ba8217b5e5a68d4

The MCP documentation now marks MCP Inspector as partially supporting MCP Apps in the extensions client matrix. The Inspector web client renders MCP Apps and advertises the io.modelcontextprotocol/ui extension by default, per the linked Inspector code at v2.14.0. Because the Inspector has no LLM, the model-facing parts of the extension are not exercised.

The client matrix is how implementers judge whether a tool can validate MCP Apps behavior. Partial support means the Inspector is useful for rendering and extension-advertisement checks, but not a full test bed for model-driven app flows. That distinction matters as MCP Apps moves through extension adoption.

Impact Analysis: Use Inspector for UI and extension-advertisement checks, and test model-facing MCP Apps behavior in an LLM-backed client.

6. MCP SEP automation drops proposal state and sponsor-hunt comments

Source: MCP Specification Link: https://github.com/modelcontextprotocol/modelcontextprotocol/commit/283d8d6a10ca9c4de63bc3a8d798762dfed52e86

A SEP automation fix removes proposal as the first SEP state and drops sponsor-hunt comments. Previously, the bot moved a proposal SEP to draft once an assignee was in the steering-committee team tree; if a proposal went quiet, the author got a 90-day reminder asking whether they needed help finding a sponsor, and after 180 days the bot labeled it dormant and closed it.

Automation shapes contributor behavior, and a proposal state tied to sponsor hunting added friction before a SEP reached draft. Removing those bot behaviors aligns the workflow with the revised sponsorship guidance and reduces noise for authors. Maintainers and contributors should expect SEP status transitions to follow the updated process rather than old bot reminders.

Impact Analysis: SEP authors should rely on the current lifecycle docs, not older bot-driven sponsor reminders, when planning submissions.

Source Links

• MCP Servers - MCP Servers v2.4.0 fixes six vulnerabilities across three servers
• MCP Specification - MCP announces six-month specification release cycle with March 30, 2027 target
• MCP Specification - MCP SEP guidance shifts to working-group sponsorship
• MCP Specification - MCP publishes early feedback post on experimental file uploads/downloads extension
• MCP Specification - MCP Inspector marked as partially supporting MCP Apps
• MCP Specification - MCP SEP automation drops proposal state and sponsor-hunt comments