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:

The goal is to let clients filter and present primitives by group, reducing context overload in LLM interactions.

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.

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.

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.

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 consolidation

MCP tool annotations - destructiveHint, readOnlyHint, idempotentHint - are defined at the tool level. This is fine when tools are atomic. But in the absence of a protocol-level grouping primitive, the ecosystem is independently converging on tool consolidation as the primary strategy for managing large action surfaces: multiple related operations collapsed behind one MCP tool, dispatched via a discriminator enum.

When that happens, the annotation system breaks in a way that is not a framework bug - it is a protocol constraint.

Consider a consolidated platform tool with these actions:

users.list       → readOnly: true,  destructive: false
users.create     → readOnly: false, destructive: false
users.ban        → readOnly: false, destructive: true
billing.invoices → readOnly: true,  destructive: false
billing.refund   → readOnly: false, destructive: true

The only safe annotation resolution for this tool under the current spec is:

• destructiveHint: true - because any action is destructive
• readOnlyHint: false - because not all actions are read-only
• idempotentHint: false - because not all actions are idempotent

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. readOnlyHint and destructiveHint are used by security middlewares to gate execution: read-only tools bypass confirmation flows, destructive tools trigger audit logging or require elevated entitlements. When the protocol forces these fields to be imprecise, two failure modes follow:

1. False positives: every users.list call triggers destructive-tool safeguards - audit entries, confirmation prompts, rate limits designed for write operations. This creates alert fatigue that operators learn to ignore, which is itself a security risk.
2. False negatives: if a team resolves annotations optimistically (marking the tool readOnly: true because most actions are read-only), a destructive action silently bypasses the safeguards designed to catch it.

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 worse

This 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: tools/list token pressure grows linearly with action count. At 50+ actions, the model starts losing track. At 200+, context exhaustion is a real operational problem.

Option B - Consolidated tools with discriminators: Controlled tools/list token budget. Cost: annotation semantics degrade, the LLM must navigate a compound discriminator schema (group + action + variant-specific parameters), and framework authors must build significant compensating machinery - 4-tier per-field annotation systems, conservative aggregation logic, structured error messages to help the model self-correct after wrong discriminator selection.

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 - platform - not to the specific operation that failed. The model's self-correction loop must then reason about which action within that tool was intended, from a validation error that carries no action-level context. In a flat tool model, the error returns attributed to users.ban and correction is immediate. Under consolidation, that precision is lost at the protocol boundary.

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 search

The 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 tools/list. It helps the model select the right tool from the visible set. It is a client-side, runtime concern.

Namespace grouping operates at server configuration time and determines what enters tools/list in the first place. In a large organization where billing.* is governed by the finance team and must not be visible to sessions without the appropriate entitlement, the requirement is structural - which domains are exposed to which clients, at configuration time, based on server-side policy. Tool search has no surface to act on until that boundary is already drawn.

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 question

The 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 name field itself to carry structured metadata (e.g. finance/invoices.get) as a formally specified convention, or CallToolResult could support execution-branch metadata that restores per-action behavioral context at the response level. Neither requires the full Groups capability from SEP-2084.

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.