MCP Core Maintainer Meeting, April 22, 2026

Attendees:

• Den Delimarsky (@localden)
• Paul Carleton (@pcarleton)
• Peter Alexander (@pja-ant)
• Caitie McCaffrey (@CaitieM20)
• Kurtis Van Gent (@kurtisvg)
• Che Liu (@pwwpche)
• Nick Cooper (@nickcoai)
• Clare Liguori (@clareliguori)

Purpose: Triage SEPs for the June 2026 spec release. Eight days remain before the list locks.

Key Decisions

1. Trust & Sensitivity Annotations: CUT from this release

@localden pulled these entirely for this launch. The discussion exposed too much disagreement about what annotations are actually for, and as a P2 it wasn't worth the cycles.

• Annotations feel "sprawling and weird" since they're all just hints with no enforcement.
• It doesn't imply false security guarantees. A malicious server can ignore them regardless.
• Server owners read "hint" as "doesn't matter if it's right," and Google has seen zero customers actually using the existing hints.
• Fragmentation problem - if every client interprets hints differently, the user experience becomes incoherent.
• At this time, we do not have an articulated long-term goal of annotations, so it's impossible to evaluate the SEP objectively.

@localden deferred to a future spec version and will loop in @SamMorrowDrums's interest group to flesh out the design properly.

2. Tasks: moving from core spec to official extension

This was the meatiest discussion. Outcome: Tasks should be moved out of the core protocol and re-homed as an official extension, timed with the June release. They were already in this odd "in spec, but not really" state so we should make this consistent with the rest of the extensions if this is an experimental capability.

Why:

• Going back to @dsp-ant's observation from earlier discussions: nobody is using Tasks today, and there's been almost no client input. Mandating it in core is premature.
• "Extension equals experimental." Tasks predated the formalized extension framework, but that's where it always belonged.
• Too many open questions to force every client to build support now.

This was also part of the discussion with @CaitieM20's work on @LucaButBoring's proposal on changes to the Task primitive:

• Splitting into a dedicated tasks/get method for polling status and results (supports incomplete results, MRTR requests for more info, and final results from one endpoint).
• Adding a separate tasks/update or tasks/continue method so clients can send additional info without coupling streams. Makes the whole thing properly async/event-driven.
• Killing most task capabilities. Instead, tool definitions get metadata saying "this returns a task," and clients can simply filter those tools out if they don't want them.
• Microsoft Foundry is looking at actively implementing this; VS Code, M365 likely to follow.

The catch-22 debate:

• @nickcoai argued for making Tasks mandatory in the next release to break the adoption deadlock. Even a shim that treats tasks as slow tool calls would unstick servers.
• @clareliguori noted Amazon already does exactly that shim in Strands.
• @kurtisvg: it's extremely hard for servers to support a tool both with and without tasks (his go-to example: Cloud SQL instance creation, 2 to 20 minutes). Optional means servers won't implement.
• @pcarleton and @localden landed on: don't mandate behavior the spec hasn't validated yet. Extension first, prove it works, then promote.

3. Extension framework problems: acknowledged, unsolved

@kurtisvg laid out some concerns with extensions:

• Extensions aren't versioned with the protocol, so they read as unstable.
• No clarity on how multiple extensions interact, or what happens when an extension modifies tool behavior across sessions.
• Enterprise customers need deprecation guarantees baked into terms of service. MCP extensions currently offer none.
• Google's internal 1MCP platform team won't greenlight extension features without lifecycle answers.

@CaitieM20 proposed using the Tasks extension as the proof point to work through versioning and protocol-dependency declaration.

Moving to 2026-06-30

We moved the pending SEPs to in-review - the Core Maintainer team will review the content in-depth this week to provide input and do a final cut on Friday.