[notes] Maintainer Spec Release Retrospective - December 17, 2025 #1996

localden · 2025-12-20T07:07:02Z

localden
Dec 20, 2025
Maintainer

Attendees

Overview

Things Going Well	Things That Can Be Improved
Knowing ahead of time what SEPs the CMs considered helped	Timing for tasks: lots of stuff went in at the last minute; it didn’t get the launch it deserved
Positive cross-SDK communication happened around features (e.g., SSE polling feedback from Go SDK)	Hit a date rather than a technical milestone
Benefit to SDKs implementing new features early around the same time	Freeze timeline: 2 weeks isn’t formalized, feels arbitrary, and isn’t always enough for large features
VS Code is one the most engaged clients - we need to scale that to others	Timelines feel scary/too short for some companies; hard to get a clear picture of what the next spec will be (esp. start-ups)
Interest from clients on the MCP Apps side has been large - potential engagement hook to drive client work	Engagement model with client implementers is weak; Discord engagement is low; unclear if there’s a regular forum for client implementers
Having its own repo for things like MCP Apps is super helpful	Need more direct engagement with key clients; consider a blog post to highlight clients and drum up maintainer engagement
Writing conformance tests forces thinking about the client and server	Client cost-of-change is high against feature roadmaps; spec churn is costly to develop/support
	Balance feels off between solidifying existing work vs. introducing new features
	SDK gaps: state management needs work; scalability gripes may be SDK implementation issues
	Experimental status is unclear: “experimental” label doesn’t mean much today; need formalization and SDK guidance (including separating experimental features from public API)
	Cross-SDK communication is limited/siloed; general SDK chat feels too public during critical times; need a private spec-release channel
	SDK collaboration ideas: hackathons during freeze; more frequent SDK maintainer working meetings; learn from interop-style events
	Process hygiene: triage changes faster; avoid changes lingering too long; consider organizing a call for moderators
	Docs gaps: capabilities documentation; emerging scenarios; how docs plug into the spec area; more SDK examples
	Docs architecture ideas: how do we structure pulling docs from other repos to simplify maintenance
	Spec process clarity: prototype/reference implementation expectations need clarification; polling example raised questions; adopting a SEP before a reference implementation exists may need to be flipped
	How do we rationalize the work against potential future stabilization of the MCP core, where breaking changes would be harder to make

Follow-ups/Action Items

Note

With the end of the year approaching and folks going on break, we will sequence the feedback items and drive ownership in January around individual improvement areas.

Raw Notes

Timing for tasks. Lots of stuff went in at the last minute, which meant it didn’t get the launch it deserved.
- We hit a date rather than a technical milestone.
Knowing ahead of time what SEPs the CMs considered helped. Short two weeks - felt like we’re hitting a deadline.
- But also got the idea that some of it is experimental.
- Putting the word “experimental” doesn’t mean much right now, especially with SDKs, where it’s hard to flag something as experimental. We need to formalize that for the next release.
- Worth noting that it partly came out of the perennial chicken and egg - someone needs to go and implement it.
- Spec language makes it experimental, but we didn’t use experimental capability marking for Tasks.
- We need guidance for SDKs on how experimental features need to be separated rather than be implemented right into the public API.
- Marking things as experimental is good because it allows us to not introduce breaking changes in the SDK.
Propose or sponsor changes - things that required effort did not really have a good path to reach client implementers. We currently don’t have a great engagement model with client implementers. What we have in the Discord - there is not much engagement there.
- VS Code is the most engaged client, we have some folks from ChatGPT, but not sure if we have a regular meeting with client implementers.
- We should engage a bit more directly with some of the key clients.
- How to interpret the signal that we don’t hear as much from client implementers as we do from server developers?
- This is a bit of a chicken and egg problem - when server and client implementations diverge (people start screaming), that’s when folks will push for changes. But we still do not see as much activity from client developers.
- A lot of client developers just build stuff they need, and then go and open a SEP for missing semantics.
- You do want clients to try things before it goes to production.
- There is a lot of interest from clients on the MCP Apps side, so maybe that is a hook here to help with the engagement.
- Can we get a blog post to talk about clients and drum up interest in engaging closer with the maintainers?
  - Maybe use that as a vehicle to highlight client implementations.
- I'd also add that for clients there is a significant cost-of-change against feature roadmaps; so constantly iterating specs with new features (where server implementations lag) is painful unless you have lots of $$$.
- You have to develop AND support AND handle spec churn. And be confident that investment is going to return better than other uses of the time. Maybe we could focus more on some of those practical benefits.
We need to do a better job documenting capabilities.
Freeze timeline - 2 weeks is not formalized, but is kind of arbitrary. The complexity of stuff really varies. Spec release that has a bunch of changes - some small and some larger, but this seems like not always the right amount of time for large features.
- Is there something more nuanced here?
- Positive note on the freeze - cross SDK communication that happened around features (e.g., SSE polling feedback from Go SDK). Some of it came after the release, so if we had a few more weeks, we could improve the spec even further.
- Yes, I've heard complaints from several companies that the timelines are too short, and they find it scary to have to adapt that quickly - and find it difficult to get a clear picture of what the next spec is likely to be. Especially start-ups.
- There's a definite benefit of having the SDKs start implementing new features early around the same time
- Some SDKs are silo-ed, which is challenging.
If there are lots of defects in the SDKs, that means consolidating/improving things takes a backseat to sprinting for new things.
Balance of time - are we balancing the community focus on solidifying the existing stuff vs. new features? We haven’t gotten that quite right.
- There are some big gaps around state management in SDKs.
- Wonder if gripes with scalability are issues with SDK implementation.
Cross-SDK communication - don’t see a lot of it in the general SDK group.
- How do we engage all the SDK developers here to make sure that we’re on the same page with spec changes?
- The general SDK dev chat almost feels too public - don’t want to have people who are not working on the spec release to pile on and add opinions (esp. during a critical time). We need a private channel for people working on the spec release.
  - If you post in the general channel, you have a higher risk of people chiming in with distracting ideas.
- In the C# SDK, Stephen is looking at TS/Python as starting point, but want to make sure that we’re not silo-ing too much stuff on Discord and leverage GitHub, since this is where a lot of the discussions are that are SDK-related.
- Hackathons for SDKs potentially could be helpful here.
  - Maybe during the spec freeze, we can set up something along the lines of a hackathon to work through the requirements and changes.
  - Paul talked to someone at OIDF about their "interop" in person events, could model some of this off of that.
- SDK maintainer working meeting - maybe that needs to be more frequent.
We currently do not have a call for moderators - maybe that’s something that can be organized to make them more effective.
There are documentation changes that are going into the spec - some things are not necessarily materially impactful to the specification itself, but they need to go in and make those changes into an existing spec.
- We should also be triaging changes much quicker. Some changes are lingering there for a bit too long.
Evolution of MCP - do we expect the core to “slow down” eventually?
There isn’t a lot of documentation over the emerging scenarios and how will all of this plug into the spec area?
- Documentation for SDKs - how do we plug that in as well to focus on examples?
- Having its own repo for things like MCP Apps is super helpful.
- Submodules for docs? E.g. pull from other repos.
Spec churn - there is a requirement for a fully-working prototype for spec changes. Have we kept to that?
- The polling example is where this was a language change to the spec, but how do we rationalize changes like that with prototypes?
- The language on that is a little weird - the idea that you can adopt a SEP before a reference implementation exists, and then do it after, this feels like it needs to be flipped.
  - The problem here is that the spec can change underneath.
- Writing a conformance test will force you to think about the client and server here.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[notes] Maintainer Spec Release Retrospective - December 17, 2025 #1996

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

[notes] Maintainer Spec Release Retrospective - December 17, 2025 #1996

Uh oh!

localden Dec 20, 2025 Maintainer

Attendees

Overview

Follow-ups/Action Items

Replies: 0 comments

localden
Dec 20, 2025
Maintainer