Core Maintainer Meeting - April 1, 2026

[localden]

MCP Core Maintainers met on April 1st during the MCP Dev Summit, to discuss the evolution of MCP.

Discussions split cleanly into two arcs. The morning sessions resolved a long-standing architectural question about where statefulness lives in the protocol, landing on a decision to strip sessions from the core spec. The afternoon sessions shifted to strategic positioning, pressure-testing MCP against CLI-based and skills-based alternatives and converging on bi-directionality, security posture, and enterprise deployment capabilities as the protocol's differentiators. A recurring undercurrent across all four conversations was that MCP's adoption is increasingly about improved guidance and client completeness.

1. Sessions: removed from core, reintroduced as an extension

The morning opened with the sessions question, which had been blocking other transport work. The group reached consensus that transport-level sessions, where statefulness is tied to the protocol itself and requires initialization, are not needed and should be eliminated entirely. The confusion they introduce outweighs any benefit at that layer.

Attention then moved to whether an application-level session construct should exist instead: a server-minted ID returned to the client, which the client uses to logically group related tool calls. The group raised the concern that while the minimal peer design is elegant, the absence of any structured session concept makes it harder to reason about higher-level system architecture, and that a simple "error requiring a session" pattern might be the lighter-weight answer.

The group debated the trade-off between making existing application code easy to port versus asking server authors to rethink their architecture. There was agreement that shuffling state is conceptually fine and that servers wanting stateful behavior could implement it with cookies or similar mechanisms without protocol support.

Decision vector: Remove sessions from the core protocol and simultaneously publish sessions as an extension to gather early feedback. The group explicitly favored a smaller core and lower implementation burden for server authors. @dsp will help make the final call after thinking through the end-to-end implications.

2. Spec restructuring: extensions, versioning, and configuration

With sessions resolved, the group used the momentum to revisit spec scope more broadly.

Roots and sampling move to an extension. The group discussed a potential avenue for moving things out of the core spec - roots and sampling being some of the candidates that could be relocated to an extension. This is part of a wider intent to keep the core spec minimal and push optional capabilities outward, as well as establish a

Versioning and deprecation. There was agreement that MCP needs a formal versioning status and a defined deprecation cycle. The proposed model: version MCP as a whole, then hold SDKs accountable against that, for example requiring Tier 1 SDKs to support a minimum number of years of a given spec version.

3. MCP vs CLI: where each actually wins

The afternoon turned to competitive framing, starting with the recurring "why not just use a CLI" challenge.

Production and enterprise reality. CLIs are a poor fit for production-grade systems because agents in production should not be executing arbitrary commands. In practice, the vast majority of enterprise customers reach tools like Figma, Notion, Slack, and Gmail through MCP via coding assistants or LLM clients. Highly technical organizations may still lean on CLIs locally, but that is the exception.

Technical merits. CLIs are effective for local code execution in single-machine developer environments. MCP is the better fit for remote environments because it inherits standard HTTP observability and established API patterns for security and authentication. The group called out that moving CLI workloads off a single machine is hard: assumptions get baked in, and SSO becomes a mess.

Scalability is structural. Building an MCP server allows the resource to be shared and propagated broadly. CLI sandbox approaches that rely on local credentials cap out quickly, with rough estimates of fewer than 100 users before the per-person resource cost becomes prohibitive.

4. Bi-directionality as the core differentiator

The second afternoon session sharpened the value proposition further.

Bi-directionality is the moat. Dynamic elicitation, where the server can ask the client or user for information mid-flow, is structurally difficult to achieve in a CLI model. This, combined with MCP's opinionated approach to designing APIs specifically for model consumption, is where the protocol earns its keep. Progressive discovery was called out as critical near-term work that needs to be better evangelized.

Guidance over features. A notable framing emerged: the program does not primarily need additions to MCP itself. It needs clearer guidance on how to use what already exists. This goes back to the discussion about having better client support.

The client gap. There is a real lack of clients implementing the full MCP specification, and this is creating adoption barriers. The group flagged the need for clearer guidance aimed specifically at client builders.

5. Skills and MCP: complementary, not competing

Some industry teams' leadership's stated preference for skills over MCP came up directly. Their reasoning: skills accomplish higher-level, multi-step tasks that are closer to user value, while MCP provides foundational building blocks.

The group's counter-framing was that this is a layering relationship, not a rivalry. MCP servers should function as libraries that skills reference and compose. Skills sit on top; MCP sits underneath. Positioned this way, a preference for skills is not a threat to MCP, it is a dependency on it.

Decisions and open items

Decision vectors (need finalization)

• Transport-level sessions eliminated; no initialization requirement at the transport layer
• Sessions removed from core spec, published concurrently as an extension for feedback
• Roots and sampling move from core to an extension (specialization of resources) or to a path to deprecation.
• MCP positioning vs CLI: shared control plane/management + bi-directionality are the defensible differentiators
• Skills positioned as a layer above MCP, not a replacement - we'll work on better guidance

Open

• Formal versioning status and SDK deprecation cycle (direction agreed, mechanics TBD)
• Client builder guidance to close the full-spec implementation gap

[pja-ant]

Thanks for sharing this!

Prompts and sampling move to an extension

I don't think we agreed on prompts. My recollection was that sampling and roots where the likely candidates for deprecation and that logLevel may just go entirely. I'm not sure we aligned on extensions being the deprecation mechanism either.

[localden]

@pja-ant adjusting!

[localden]

@pja-ant also just calling out that I mentioned that these are decision vectors so we can still adjust the direction of the concrete steps

[olaservo]

Skills positioned as a layer above MCP, not a replacement - we'll work on better guidance

Concrete examples of the two-way relationship between them could be helpful, to make it less about a hierarchy and more about using them as flexible building blocks. The interest group repo and meeting notes include a lot of valuable community-sourced content on this topic. Guidance-wise, would it make sense to showcase a few of the patterns where skills and mcp can intersect, maybe as a blog post or a learn section of the docs?