MCP Core Maintainer Meeting (Client Maintainers edition) - Jun 17, 2026

Attendees

• Den Delimarsky (@localden)
• David Soria Parra (@dsp-ant)
• Paul Carleton (@pcarleton)
• Caitie McCaffrey (@CaitieM20)
• Peter Alexander (@pja-ant)
• Kurtis Van Gent (@kurtisvg) [Google Cloud]
• Clare Liguori (@clareliguori) [Amazon]
• Nick Cooper (@nickcoai)
• Matt Carey (@mattzcarey) [Cloudflare]
• Tyler James Leonhardt (@TylerLeonhardt) [Microsoft / VS Code]
• Connor Peet (@connor4312) [Microsoft / VS Code]
• Sam Sokolin [Cursor]
• Pavel Gorgulov [JetBrains]

Thank you to all client maintainers for attending and providing feedback!

Topics

OAuth single-use refresh tokens (Sam, Cursor)

• Multiple clients sharing one OAuth grant (Cursor IDE, CLI, cloud agents) trip over single-use refresh tokens. Coordinating refresh across processes causes premature sign-outs
• Matt: Cloudflare servers use single-use tokens and are likely contributing. Mitigated with a ~90s grace period for refresh-token reuse
• Paul: private-client flows (private-key JWT) help, but no good spec-level answer today
• Outcome: no decision. Noted as an Auth IG topic

Stateless transport

• Broad enthusiasm for stateless-by-default
• Matt: SDK changes must be explicit and visible. Developers should know they're opting in rather than have behavior change silently. Cloudflare currently routes to durable objects and expects to remove most of that infra once stateless lands

SDK usage among clients

• VS Code: no MCP SDK. Custom implementation glued to VS Code's network stack since the early days
• Zed: custom implementation
• Nick's team: hybrid. SDK for protocol handling, custom connection initialization
• Cloudflare: custom network interception for routing

Spec tracking and conformance

• VS Code tracks spec changes manually. Tyler and Connor split implementation
• Conformance tests called out as very useful. Cloudflare added them recently and found three bugs
• Paul shared a link to the experimental hosted conformance runner

Transport selector anti-pattern (DSP)

• Clients should not expose a user-facing toggle between legacy session-based Streamable HTTP and the stateless MRTR-based mode. A URL should just work without the user picking a mode.

Deprecating older protocol versions

• SSE transport: Anthropic plans hard deprecation
• March 2025 OAuth fallback (clients hit /register and /authorize on the main endpoint): generates confusing bug reports
• Paul: proposed making the fallback opt-in for new servers in the TS SDK
• Tyler: wants to drop the old auth-server-in-MCP-server flow entirely, but some servers still use it

MCP config standardization (Clare, Amazon)

• Lack of a standard config format is a real pain point for enterprise customers running multiple clients
• Sticking point from the New York discussion: cross-client value injection (env vars, credentials)

Tool discovery / progressive loading (Pavel, JetBrains)

• IntelliJ-based IDEs see 80-100 tools at once because every plugin can extend the list. Need lazy loading, deferred tools, or tool search, especially for local-model users
• DSP: frequently requested. Team is considering a generalized discovery mechanism but design is tricky (tools only, or all primitives?)
• Clare: per-server discovery isn't enough. The sum across servers is still large
• Nick: ship a concrete reference (e.g., a tool-search MCP gateway) so the community has something tangible
• Kurtis: needs standardization. Without it, server authors can't optimize because every client handles selection differently
• Caitie: the protocol should enable discovery rather than solve it (HTTP didn't solve web search). Indexes will emerge from clients and third parties
• Outcome: dedicated core-maintainer follow-up. Not resolved here

Extensions: tasks and skills

• Skills over MCP: DSP described the vision (org charts as skills, Figma server shipping usage skills). Sam: overlaps with plugin model but packaging skills into servers gives real portability
• Tasks: VS Code supports old-style tasks but not the new spec. Caitie wants new tasks since Foundry will support it. Current workaround is 4-5 minute tool-call timeouts, painful for connection management
• Clare: SDK support for extensions and versioning are adoption blockers

Extension stability (Pavel)

• Hard for client teams to know when to invest in an extension. Unclear what's experimental vs stable and heading to core
• Den: valid feedback. Tasks, for example, aren't expected to change fundamentally even though they're an extension

Caching (Peter)

• Asked how clients plan to integrate the new TTL-based caching for tools/list and other calls. Briefly raised, not discussed in depth

Actions

• @TylerLeonhardt: pull telemetry on usage of the old auth-server-in-MCP-server OAuth flow and share which servers still use it
• @dsp-ant @nickcoai: schedule a dedicated follow-up on tool discovery / progressive loading (protocol changes, reference implementation, standardization)
• @localden @dsp-ant: clarify and publish the stability/maturity status of each MCP extension so client teams know what to invest in
• @CaitieM20: complete conformance tests for tasks. Review with @pcarleton / conformance group
• @pcarleton / TS SDK: consider making the March 2025 OAuth fallback opt-in rather than automatic
• Core + client maintainers (raised by @clareliguori): drive MCP config standardization forward. Specifically resolve value injection / credentials across clients
• @localden: communicate hard-deprecation timeline for SSE transport
• Core maintainers (raised by @clareliguori): compile and share a list of servers supporting newer spec features (tasks, skills, new transport) so clients have real servers to test against