Primtive Grouping IG Meeting Notes (14th August 2026) #3264
chughtapan
started this conversation in
Meeting Notes - Other
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Attendees
1. Meeting purpose
The meeting was a reset and alignment discussion for the MCP “primitive grouping” effort. The group has been exploring how MCP should support large, complex servers where exposing all tools/resources/prompts up front creates usability, context, and control problems.
The central question was not “what exact solution should we ship?” but rather:
A major theme was that the group needs to stop converging prematurely on a mechanism — grouping, filtering, skills, tool search, dispatcher patterns, etc. — and instead first produce a crisp, compelling problem statement backed by concrete use cases and, ideally, quantitative evidence.
2. Historical context
The group began from earlier work around primitive grouping, proposed around December/January. At that time, core maintainers were not ready to accept grouping as a protocol primitive. The feedback was that the space felt too early and that multiple competing approaches existed. After that, the effort moved back into a broader “centrist” or exploratory group. Two broad solution directions had been discussed:
A persistent challenge has been that changing the available tool list can invalidate LLM prompt caches. Some experiments around deferred loading were run by Hallyu and Sam to avoid or reduce that cost.
3. Current state: tool search is dominant, but not sufficient
The group agreed that tool search has become the dominant current workaround because, in practice, it is the main thing MCP users can do today. However, several participants argued that tool search does not fully solve the problem.
Main concerns with tool search:
David pushed the group to quantify this rather than rely only on anecdotes — e.g. what percentage of users are on models without tool search, or how often users disable MCP servers due to tool overload.
The group did acknowledge that newer OpenAI and Anthropic-style client-initiated tool enablement is promising. In those systems, clients can enable tools dynamically without necessarily busting prompt caches, sometimes by injecting tools through user-message-like mechanisms. But the question remains whether MCP should provide protocol-level structure to guide those enablement decisions.
4. Key use cases raised
Kurtis / Google use case: Kurtis described Google’s situation as involving 50+ MCP servers. Users often want one unified Google extension/plugin/server representing all Google products. But that does not scale if every product and sub-product exposes all possible functionality all the time. Kurtis gave Cloud SQL as an example: Cloud SQL might expose functionality for managing instances, creating instances, and working with different database engines. Some users may never use SQL Server.
Those users should be able to disable or avoid seeing SQL Server-related tools. Google wants some way for server authors to express meaningful subsets, modes, or discovery paths. The underlying problem is not just context size; it is also server-side agency. Google, as the server author, wants to shape how capabilities are exposed rather than relying entirely on every client to rediscover and filter the tool universe independently.
Sam / GitHub use case: Sam described a different but complementary problem from the GitHub MCP server. GitHub has many possible tools. In practice, agents often use only a very small subset — around four tools — and then fall back to the GitHub CLI for many operations because it is more token-efficient or easier for coding agents. Sam’s concern is that MCP’s value is being undercut when agents avoid using rich MCP toolsets because the exposed surface area is too large or too inefficient. For GitHub, the issue is partly: too many tools, context overload, insufficient client/server coordination, agents optimizing around token cost, and a lack of good protocol affordances for progressive discovery. Sam also emphasized that this has become “life consuming” over a long period: teams want to expose more functionality, but the baseline token footprint and discoverability issues make that difficult.
5. Core conceptual distinction: selection vs. discovery
David introduced what became one of the most important conceptual frames of the meeting: the group has been conflating selection mechanisms and discovery mechanisms.
Selection mechanism: A selection mechanism shows the available universe and lets a client, user, or model pick a subset.
Primitive grouping, in its earlier form, looked more like a selection mechanism: “Here are all the groups.” “Choose which groups/tools you want enabled.” The universe is visible or at least enumerated. David described flat grouping as essentially a tree of depth one.
Discovery mechanism: A discovery mechanism hides parts of the universe until something looks for them. David compared this to a file system: You do not see every file in every directory all at once. You traverse a structure. Discovery can be recursive.
The mechanism exists independently of the specific thing being discovered. David said he is more interested in a general, recursive discovery mechanism than a flat grouping mechanism. In his view, if grouping is useful, it likely wants to generalize into a tree or directory-like mechanism rather than remain a one-level list.
6. Server-side agency emerged as a major theme
David said his thinking has shifted since the earlier grouping discussions. Previously, many core maintainers were skeptical that this needed to be solved on the server side. The argument was: clients can fetch all tools and decide what to expose to the model.
But David now sees a stronger argument for giving server authors some protocol-level agency. The reasoning is not that clients could never do the right thing. In an ideal world, clients would have all information and make perfect decisions. But in practice:
clients may not optimize a given server well, server authors understand their own domains better,server authors care most about their servers being usable, clients often implement all-or-nothing loading, and there is no in-protocol contract for enabled/disabled subsets. David referenced an insight from Anna: remote discovery mechanisms can give server authors agency over what gets exposed without relying on clients to make all the right choices. This does not mean the solution must be entirely server-driven. Rather, server-side agency should be included in the problem framing.
7. Skills as a possible dependency — and why David is skeptical
Tapan asked whether discovery/grouping metadata could attach to skills, since skills are already a kind of progressive disclosure mechanism. The idea would be: skills contain metadata describing which MCP primitives belong to them, clients discover skills,
enabling a skill reveals tools/resources/prompts, MCP can piggyback on a mechanism that some agents already support.
David was not categorically opposed, but he was skeptical. His concern was that skills carry assumptions beyond simple metadata, including execution environment assumptions and other tricky semantics. If those are stripped away, a skill becomes little more than a metadata wrapper. David summarized the risk as “metadata into metadata into metadata”: if MCP already has a metadata layer, why bury discovery metadata inside another metadata-bearing object? He also emphasized that if this mechanism is meant to eventually move into core MCP rather than remain an extension forever, taking a dependency on skills may be architecturally undesirable.
8. Protocol design philosophy: solve an existing problem, not a speculative future one
Tapan asked how to reconcile this work with the principle that MCP should standardize existing patterns rather than invent speculative mechanisms. David clarified that he does not see this work as inventing a future problem. People already have the problem today: tool overload, tool search limitations, programmatic tool calling, lack of server-side control, context pressure,
and client inconsistency. The group is trying to define the MCP-native equivalent of patterns people are already using.
David contrasted this with protocol efforts that try to solve problems ten years in advance, using IPv6 as an example of a protocol that attempted to anticipate too much and struggled with adoption. His advice was to focus on the existing pain and describe why it matters now.
9. The problem statement must come before the solution
David repeatedly emphasized that the group needs a strong problem statement before proposing a mechanism. He said the group currently has several proposals because people are solving slightly different problems. If the group cannot agree on a shared problem, it may need to split into sub-groups and bring separate proposals to core maintainers. However, he also warned that narrower groups make weaker cases. A protocol change is more compelling if it solves the shared needs of multiple major server authors or ecosystems. David specifically noted that Kurtis’s and Sam’s problems are complementary: Kurtis brings the large multi-product server / server-author-agency case. Sam brings the tool overload / agent behavior / context efficiency case. Combining those into one coherent problem statement would likely make the proposal stronger.
10. What evidence would strengthen the case?
David encouraged the group to include quantitative evidence wherever possible. Examples of useful evidence: percentage of users on models that do not support tool search,adoption rates of MCP servers with large tool counts, how often users disable or avoid large MCP servers, how often agents fall back to CLIs instead of MCP tools, rough proportions rather than sensitive absolute numbers, data from other large servers such as AWS-style high-tool-count servers. The goal is to avoid presenting this as only “Google has this issue” or “GitHub has this issue.” The stronger argument is that this is a broad MCP ecosystem problem affecting multiple kinds of servers and clients.
11. Relationship to core maintainers
The group should not wait until it has a perfect proposal before engaging core maintainers. David’s advice was: Write the problem statement. Bring it to core maintainers early. Do not lead with a solution. Ask whether this is a problem worth solving in MCP.
Use feedback to shape the solution space. David noted that the group likely has more support now than it did during the earlier grouping discussion. .
12. Naming and working group structure
David said he would rename the effort away from “primitive grouping.” The proposed direction is to make it a sub-group under a broader core primitives working group, but the exact name should avoid prematurely committing to a solution. Possible naming directions included: discovery, filtering, primitive discovery, core primitives discovery, context/problem-oriented naming.
David cautioned that names like “filtering” or “grouping” may encode a solution too early. Since the group is still identifying the problem, the name should stay broad enough to include discovery, selection, filtering, or other mechanisms.
13. Timeline and urgency
David said the timeline is tight if the group wants to ship something as an extension by the end of the current cycle.
The recommended sequence is: over the next 2–3 weeks, consolidate Curtis’s and Sam’s use cases into a written problem statement. Include quantitative or semi-quantitative evidence. Present the problem statement to core maintainers early.
Get a temperature check before committing to a solution. Then move quickly toward a concrete extension proposal.
The group should aim for the mechanism to begin as an extension, but David’s long-term view is that this kind of mechanism, if successful, might eventually belong in core MCP.
14. Meeting cadence and async collaboration
The group discussed increasing cadence. Weekly meetings were proposed, following the model of the transports working group.
Tapan is responsible for setting up a new recurring weekly meeting cadence and polling for times that work across time zones.
Time-zone constraints: Curtis has limited availability Tuesday–Thursday mornings Pacific due to India-time-zone work.
Monday and Friday Pacific mornings may be more viable. Sam is in a difficult time zone for many US-centered meetings. Some participants suggested not forcing everyone into one synchronous slot. Sam suggested an async-friendly model:
possibly hold parallel time-zone-friendly sessions, keep detailed meeting notes, use notes to hand off context between groups, avoid making any one person’s time zone a blocker. The group agreed that high-quality meeting notes are essential if they run parallel or staggered sessions.
All reactions