Core Maintainer Meeting - February 4th #2204
Replies: 4 comments 4 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.
-
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.
-
|
We built MCP Fusion, a grouping and routing layer over the MCP SDK, following the guidance in these notes. Building it exposed specific, verifiable problems in the current protocol that grouping would resolve. I want to put these on record precisely, because they are spec-level issues - not preference. The core problem: tool annotations become semantically incoherent under consolidationMCP tool annotations - When that happens, the annotation system breaks in a way that is not a framework bug - it is a protocol constraint. Consider a consolidated The only safe annotation resolution for this tool under the current spec is:
This is the correct conservative resolution. It is also semantically wrong for 3 out of 5 actions. The annotation degradation is not just a UX inconvenience - it is a security concern.
This is not a solvable problem at the framework level. It requires a protocol primitive that allows behavioral semantics to be scoped below the tool level. Why consolidation is happening: the alternative is worseThis is a forced tradeoff between two protocol-level constraints that currently cannot both be satisfied: Option A - Flat individual tools: Clean annotation semantics, clear per-action schemas, optimal LLM tool-use quality. Cost: Option B - Consolidated tools with discriminators: Controlled Neither option is correct. Both exist because the protocol has no way to express "these tools are structurally related, share behavioral scope, and should be reasoned about as a domain" without collapsing them into one endpoint. There is a second-order cost to Option B that compounds over time. When the model selects the wrong discriminator or sends parameters for the wrong action variant, the error returns attributed to a generic tool name - Protocol-level grouping would decouple the organizational concern from the exposure concern. Tools could remain individual and well-typed - preserving annotation semantics and LLM self-correction precision - while being declared as members of a namespace that clients can use for filtering, governance, and presentation. On the framing of grouping vs. tool searchThe meeting notes cited tool search and skills as alternative approaches. These solve different problems and the distinction matters for enterprise deployments. Tool search operates at inference time on whatever is already in Namespace grouping operates at server configuration time and determines what enters These are orthogonal. Solving discovery does not solve governance. Both are needed for enterprise-grade deployments, and conflating them in the rejection rationale leaves the governance problem unaddressed. The specific questionThe annotation incoherence described above is reproducible from the current spec and observable in any implementation that attempts consolidation. I am not asking to reopen SEP-2084. The specific question is: how does the core group see the annotation semantics problem being resolved without a sub-tool scoping primitive? If the answer is that full hierarchical grouping is still premature, we understand - but the problem does not go away. A lighter-weight path might be worth considering: the protocol could allow the tool If there is an intended solution within the current spec - or a direction already planned - we will build toward that. If there is not, we believe the annotation semantics problem is concrete enough to warrant a scoped re-engagement, independent of the broader grouping discussion. Happy to provide a minimal reproducible example against the SDK if that would be useful. |
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