Core Maintainer Meeting - February 4th #2204
Replies: 3 comments 2 replies
-
With due respect, I think that centralizing decision making in a statically-defined, exclusive, very small set of core maintainers simply does not scale to a broadly-used protocol (and/or API(s)/sdks for that matter). Although better process docs, clearer and more documentation of decisions, contributor education, are all good things...based upon my experience they will still eventually create a bottleneck of decision making...especially in something like AI/ML where tooling and integration are just beginning. I think the only way to scale something in the open source world is to depend upon and trust the dev community, encourage/enable greater open participation...both in terms of technical contributions, experiments, working group participation, etc, as well as the decision-making process/project mgmt/inter-project coordination (e.g. conformance testing). Of course there have to be ways of creating and establishing community trust continuously. I don't mean to discount that this can be a very difficult challenge, specifically because of backward compatibility requirements to assure that protocol consumers/products are not continuously broken. My only observation is that diversity of participation and expertise can give both innovation and protocol stability, if an participatory architecture is adopted and democratic, community-based decision making (trust) is enabled. In many respects, protocol stability is similar to maintaining API backward compatibility, which has been successfully done over the long term in several existing open source organizations including the ones I've participated in over many years. |
Beta Was this translation helpful? Give feedback.
-
|
Respect the decision to wait on groups as it is a one way door if the group feels things are still moving too fast to adopt. Would appreciate a couple clarification points if possible:
I thought this was one of several goals and this wasn't more important than the other goals that this was no longer all about context management. For my use cases, the need of groups comes from server side organization and access controls to things like resources / prompts for a very large organization.
These alternatives handle dynamic context discovery client side, but I've yet to see anything that would solve for server side organization and access without something being in the protocol itself. Without an organization concept, it inhibits our ability to move forward with MCP for some of the things that we want to do with enterprise resource / prompt libraries. It would be great for my understanding to get more insight from the core maintainers perspective on the importance of working towards an organization concept beyond just free-floating primitives as a protocol priority? Even if the answer is it's a priority, but the stance is it's too soon to coalesce on an implementation for this that's helpful for me. If groups can be accomplished with an extension first I'm perfectly happy with that and better understand the reasoning with extensions coming, but I'm struggling conceptually understanding how that would work. (but I also have a limited understanding of extensions at this point or how to even get started on that; I've only skimmed the SEP a couple months ago and see that just got merged didn't realize it didn't ultimately get included in the November release) Edit: Okay I think I grasp extensions now and agree with the philosophy here. |
Beta Was this translation helpful? Give feedback.
-
I would be interested to hear very specific use cases here. I might not full grasp the challenge here and would love to learn about it (also happy to do that via email if you prefer). The use cases I am aware of would mostly be solved by exposing oauth scopes directly at a primitive level (tools/resources/prompts) and handle access levels this way. After access is provided based on scopes, the underlying selection problem remains the same. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Observation: If 'widespread adoption' is defined too narrowly, it can effectively turn 'standardization' over to large players only. At the schema spec level, what is meant by extensions? Is this something more/other than using _meta? If so, I would appreciate pointers to documentation and/or existing code examples of using this mechanism. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
MCP Core Maintainer Meeting — February 4, 2026
Attendance:
Quorum was reached with 7 out of 9 Core Maintainers
Meeting Summary
The MCP Core Maintainers met to review three Specification Enhancement Proposals (SEPs). Below is a summary of the decisions, rationale, and what contributors should know going forward.
SEPs Reviewed
SEP-2084: Primitive Grouping — Not Accepted at This Time
PR: #2084
What it proposes: A new server capability called "Groups" that organizes MCP primitives (tools, prompts, resources, tasks) into named, hierarchical collections. The goal is to let clients filter and present primitives by group, reducing context overload in LLM interactions.
Decision: After discussion, the core maintainers proceeded to an asynchronous vote on this proposal. The overall sentiment leaned against accepting it at this time. While the design is sound and solves a real organizational challenge, the group concluded that the AI tooling landscape is evolving too quickly to commit to a specific grouping mechanism right now. Tool search and skills have recently emerged as alternative approaches, and it isn't yet clear whether explicit grouping will remain the best path forward.
Key reasoning:
What contributors should know: The door is not closed on this idea. Contributors interested in grouping are encouraged to prototype it as an MCP extension or standalone project. If it gains traction in the ecosystem, it becomes a strong candidate for future standardization.
Vote:
Proposal was rejected.
SEP-414: OpenTelemetry Trace Context Propagation — Supported, Proceeding to Vote
PR: #414
What it proposes: Formalizes the convention of propagating W3C OpenTelemetry trace context (
traceparent,tracestate,baggage) through the_metaparameter in MCP requests. This documents a pattern that is already in use across several SDKs, including the C# implementation.Decision: The core maintainers expressed broad support and moved the proposal to an asynchronous vote. The group also agreed to make a namespacing exception: while MCP normally requires DNS-style prefixes for meta keys, the OTel fields will be allowed without prefixes to maintain compatibility with the OpenTelemetry standard.
Key reasoning:
Open investigation: The maintainers asked for further research into how existing SDKs and major client implementers handle OTel context today (headers vs. meta fields) and what the deprecation path would look like if the approach needs to change later.
Vote:
Proposal was accepted.
SEP-1938: Agency Hint Tool Annotation — Not Accepted
PR: #1938
What it proposes: An optional
agencyHintboolean annotation on tools to signal that a tool performs autonomous, multi-step AI reasoning rather than a simple atomic operation. The intent was to help clients apply appropriate UX patterns (confirmation flows, progress monitoring) for agentic tools.Decision: The core maintainers did not support this proposal.
Key reasoning:
What contributors should know: The agents working group is encouraged to continue exploring how to surface tool complexity to clients, but future proposals in this area should be grounded in demonstrated ecosystem need and clearer definitions.
Vote: Still ongoing
Broader Takeaways for Contributors
MCP's standardization philosophy
A key theme of the meeting was reinforcing MCP's approach to protocol evolution: standardize patterns that have already emerged and proven themselves in the ecosystem, rather than inventing new ones. MCP Apps was cited as a success story — it was built outside the core spec, gained community adoption, and was then brought into the protocol.
Extensions are the right starting point
If you have an idea for a new capability, the recommended path is to build it as an MCP extension first. Extensions let you ship, iterate, and gather real-world feedback without the permanence of a core protocol addition. If your extension gains widespread adoption, it becomes a natural candidate for standardization.
What the maintainers are prioritizing
The core maintainers committed to publishing an updated roadmap within the coming weeks to give the community clearer guidance on priorities. Topics like streaming, transport improvements, and protocol stability are high on the list. Contributors are encouraged to watch for that roadmap and align their efforts accordingly.
Improved proposal process
The maintainers are working on improvements to the SEP review process, including better pre-screening of proposals before they reach the core group, clearer documentation of decisions, and a published vision-and-values document for the protocol. The goal is to help contributors understand what makes a strong proposal and avoid investing effort in directions that aren't aligned with protocol priorities.
Links
Beta Was this translation helpful? Give feedback.
All reactions