Primitive Grouping WG Meeting Notes - December 15, 2025 #1986
Replies: 2 comments 8 replies
-
Yes. Most json serialization libraries...by default...create copies of objects (like Tool, Resource, Prompt, etc) when they attempt to serialize multiple references to the same object.
No, that's not what I'm saying. What I'm saying is: there are well-known/established techniques for efficient json serialization of object graphs...and what we are talking about is serializing an object graph (a tree structure...where a Tool references a group, and that group references a parent group recursively, etc). Example: Jackson (Java serialization library for the current mcp-java-sdk) has an annotation called @JsonIdentityInfo. At serialization time, the first time a given instance of an object (e.g. Group) is encountered for serialization it assigns a unique id (integer in the default configuration), and serializes that object instance to the stream. Every subsequent time a given object is encountered an integer reference (value of '@id' field) is written to the stream instead of making a new copy (as it normally would do). So if 10 tools are defined to be in the same mcp-server-created Group, the first reference to the Group will be serialized (title, description, name, meta), and given a new property (called '@id' by default) with a value of 1. All of the other 9 references to t 10000 hat group (the other 9 Tools in that group) will not be copied to the stream, but instead represented by the number 1. On deserialization on mcp client the reverse occurs, and the output of the client parsing of the json stream is an object graph (tree) where in-memory references between instance represent the object graph (just as on the server). I've been using and testing @JsonIdentityInfo for the last few months with the Group enhancements to the mcp-java-sdk as described in this this post. This technique (serialization time addition of an '@id' field to the stream to get efficient serialization of tree structures is not limited to Jackson/Java. I've spent time with Pydantic (python sdk json schema lib) and I think it would be possible to do the same thing (for interoperability across languages) but I don't know the library well enough to implement it yet. I've also looked at the javascript json library as well as a couple of others, and all json libraries provide the means to customize the serialization of classes/types, so at worst it would mean someone providing a custom serializer for the Group type (only) in each language sdk once upon introduction of the Group primitive. There is also an open source library called JavaScript object graphs or jsog that has implemented in multiple languages the same serialization/deserialization strategy as @JsonIdentityInfo. So again: this (efficient object graph/tree structure serialization) is a very solvable problem technically, with well-known and already heavily used open implementations. I also looked for standardization (e.g. from json schema standard) of this approach and did not find it. If there already is a spec/standard for this approach then that would be much better but I wasn't able to find one. I'm not primarily involved in the json/json schema specification world, so I may have just not looked in the right place or with the right people.
Hopefully the above makes what I'm proposing clearer. Yes, dealing with the serialization/deserialization consequences of using json references make take some implementation work in the sdks. But FWIW, even without Group hierarchy, the same efficiency problem exists (just with 10 Tools all referencing the same Group...i.e. with no parent). That's due to the fact that Group is a collection of other objects. I'm happy to describe/detail/live demo the Java impl of the Group proposal as described here |
Beta Was this translation helpful? Give feedback.
-
|
The JSON going across the line between an MCP server and client is the serialized form. Leaving the server, the JSON matches the schema. When received on the client, it is validated against the schema again. Any inserted decorations with To implement such a mitigation would require that clients and servers implement further serialization transformation before sending and then undo that on the client after sending, presumably with an add on library following a standard and most importantly, implemented in all languages of current and future SDKs. Otherwise SDK authors will additionally have to implement this de-duplication serialization logic themselves as well. In short, every SDK would have to change the way it sends data on the wire because of this one simple decision: that the While it might be possible to mitigate the inefficient JSON graph with extra processing by client and server, I don't think it's worth the effort. We need an unassailable rationale for why that graph needs to be so complex. Otherwise we need to reduce the complexity rather than seek mitigations for its existence. Plus playing with the on-the-wire format of a protocol is not something to be done lightly. It certainly makes backward compatibility an issue. What happens when a client implementing an older version of the spec (which didn't implement special deserialization logic) talks to a newer server that is using that de-duping serialization? Now your server needs to make sure when it negotiates protocol version with an older client, that it doesn't attempt that extra serialization. |
Beta Was this translation helpful? Give feedback.
-
So...that's why @JsonIdentityInfo and jsog are (small) enhancements on both the sender/generator and receiver/parser side. Would you please just click on this link and read the entire readme? They explain it pretty well.
Yeah, you've just described what jsog and @JsonIdentityInfo (Jackson) do. Jsog has impls in Java, Python, Ruby and Typescript already built and tested. Adding on other impls in other languages is straightforward (I volunteer).
No...like I said in my comments, even without the Group.parent field (tree structure for groups) the same efficiency problem exists: One Group instance (no parent) with 200 Tools. Serialize those 200 tools (via listTools()) and you will have 200 copies of the single group in the stream. My point is that this efficiency problem exists whether you have Group.parent references or not. Since groups are collections, and collections are references to other primitives (Tools, Resources, Prompts), this problem exists. It would be worse with hierarchy (since you have more references...and the tree/object graph is larger), but all it takes is a collection of primitives for the ser/deser efficiency problem to exist. I suggest giving it a try in your favorite language as I did here.
As above, this problem exists whether Group.parent is present or not (e.g. 200 copies of a single Group).
As discussed, removing Group.parent is reducing complexity. But as I said, that doesn't fix this problem. It's a problem that exists for anything that tries to ser/deserialize object references (e.g. a list). The Group.parent/hierarchy just makes a more complex structure (tree instead of list). In my view a nice thing about the JsonIdentityInfo and jsog impls is that they solve the efficiency problem (along with the cycles problem) no matter how complicated the object graph is (i.e. for lists and trees). So...fixing for lists/collections would fix for trees. |
Beta Was this translation helpful? Give feedback.
-
The tool definition should list groups by name not full definitions. It would be copies of the name. On connect, the client fetches the groups and listens for changes, thereby being reliably aware of the latest group graph as published by the server at all times. Thereafter, it can look them up by name when a tool (prompt, resource, or task) list response references them. |
Beta Was this translation helpful? Give feedback.
-
I agree that this is another way to do things...i.e.:
In my opinion...in protocol and sdk impl terms...this is more complicated than what I've proposed because it requires another request/response in the protocol...for a group/collection primitive (i.e. listGroups). It also has other efficiency costs/implications of its own (e.g. empty/unused/un-referenced groups will have to be removed/cleaned up on server...or they will waste bandwidth). Additionally, if hierarchical groups are to come in at some future point, this approach gets drastically more complicated, and/or the json reference inefficiency issue reappears. However, I am open to having this be an alternative in the proposal. Please feel free to write it up and we will add it. In my view, the fundamental reason for the reference serialization inefficiency wrt json is that grouping is a data structure (i.e. a list/no hierarchy, or a tree/hierarchy) and data structures are modeled as references aka pointers. Some way to communicate these data structures from mcp server -> mcp client is therefore required. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting discussion. I've been exploring a different angle: rather than grouping tools, what if skills compose other skills? This gives you hierarchy without a separate Group primitive - the composition IS the structure. It also solves the non-determinism problem because LLMs see fewer tools at each decision point (only the level they need). I've put together a proposal here: agentskills/agentskills#13 Would be curious if this addresses the underlying need you're exploring. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @edu-ap. Skills isn't an MCP primitive. Our goal is to provide grouping for primitives. |
Beta Was this translation helpful? Give feedback.
-
Agree with @cliffhall ...the goal of the current effort is to provide grouping for existing MCP primitives (both groups of a single type...e.g. toolgroups, as well as groups of multiple types...e.g. groups with n tools, k prompts, etc). In case you weren't aware, a previous version of the proposal included the notion of hierarchical groups via a Group.parent property...which allowed hierarchical composition as well. All to say that I also think that hierarchical collections (trees) are likely to be important for structuring MCP primitives. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you both very much for the clarification! I've been following this discussion and the related #1567 thread, and I'm curious about one aspect: what criteria determine when something should be a sub-group vs a sibling group? For example, if I have tools web-search, pdf-save, and research (where research internally uses web-search and pdf-save), should these be:
I've been exploring a complementary approach in the Agent Skills space: composition-based hierarchy where skills explicitly declare what other skills they use, and level is determined by control flow patterns: The key insight is that this gives hierarchy semantic meaning; a Level 3 skill contains orchestration logic, not just more tools. And it provides testable criteria for classification rather than subjective grouping decisions. Full proposal with examples: agentskills/agentskills#13 I'm wondering if these level criteria could be applicable to MCP Groups as well, or if the Group primitive is intentionally kept semantics-free to allow flexibility? Would love to learn more about the thinking on hierarchy criteria, is there prior discussion I should read? |
Beta Was this translation helpful? Give feedback.
-
My answer: This is a design decision for the MCP server developer/designer.
My answer is: Let the dev community experiment and see what works well for what use cases (e.g. multi person workflows, etc) and what doesn't.
Right. I think server side dynamics (i.e. dynamic creation, 'refactoring' of collections/reassignment, hierarchical reorganization, as well as group/skills deletion should be enabled as much as possible/made as easy as possible for the mcp server developer.
Completely valid IMHO. Giving 'hierarchy semantic meaning' is relatively easy when structuring for a human user (and even that is not particularly easy...e.g. db/schema design), but when you are doing it for an LLM-as-user...that's tricky IMHO. RE: testable criteria for classification...I agree completely...I actually believe that it's going to take experimentation and usage info to decide what groupings/classifications 'make sense'.
My answer is that it's semantics-free to allow flexibility...and has 'description', 'title' group properties (llm hints)...along with description, title, etc for all primitives. As to what's the best info to put into the description...at what level in the hierarchy (when if there is a hierarchy), I'm an empiricist...i.e. I think that people/devs/mcp server developers will (hopefully) use intelligent criteria (i.e. real data, usage, even popularity for use cases) for deciding on how/what hierarchies make sense for their server. Another aspect to the server-side dynamics would be something like representing 'user trust' in terms of Groups. What if I had a personal MCP server that put prompts, resources, tools exposed into dynamically created groups that represented 'my trusted tools/services'. That's actually going to be my first MCP server after hierarchical groups are available...i.e. local storage of my individual (and locally stored) 'trust model' for tools, resources, and prompts.
There's almost too much discussion under the bridge :). Much of the original sep #1300 discussion was around hierarchy (it's value, etc). Much of complexity issues people had with the current proposal were/are around hierarchy...e.g. #1567 which I guess you have looked through. I'm still a strong believer that Group hierarchy (mcp server-side structuring of mcp primitives) has a lot of potential value for server-side organization, abstraction, classification, etc. Azure MCP has namespaces...which they are doing so they can provide some grouping for scaling a large number of tools/services being aggregated via gateways (e.g. for search/discovery/lookup/proxying, etc). I do think that if the non-hierarchical version of the Group primitive proposal is submitted and hopefully approved, that we should immediately open at least one discussion around Group hierarchy...both in implementation concerns (e.g. recursive schema definitions vs. other impls, serialization efficiency, scaling, etc) and in terms of 'grouping hierarchy design' concerns (i.e. what criteria make sense for creating hierarchical groupings, how to do dynamics wrt groupings an hierarchy). |
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.
-
Primitive Grouping WG Meeting Notes - December 15, 2025
Attendees
Discussion
We had a poll last week about whether to propose both implementations we'd been considering (Groups via a new primitive, and Groups as resources). There were only 6 votes, but Groups via a new primitive won. Therefore discussion centered on the current shape of this option as written.
Group hierarchies and the
parentfield implementationA big point of contention is the implementation of the
parentfield in this new primitive. It enables hierarchies of groups.@scottslewis is strongly in favor of an implementation where the field, in the JSON schema, is a reference to the Group definition. This means that the
parentfield of a JSON representation of a group would be another complete group object. This leads the problem of duplication on the wire. If a group has 10 children, then a list containing them would necessarily contain 11 duplicate definition of the parent. Scott's remedy for this is to urge implementers to use libraries or custom code that serializes/de-duplicates the list before sending, and reconstitutes on the other side. @cliffhall pointed out that this is an extra burden on SDK developers, and that we shouldn't include in an SEP, which is meant to define protocol, not implementation.@cliffhall is in favor of the
parentfield being a string containing the unique parent group name, that the client can use reconstruct hierarchy upon receipt of the group list.@scottslewis suggests that LLMs would want to have all the parent hierarchy of a referenced group in a tool, resource, or prompt definition. The discussion unearthed no clear reason why this would be the case.
Deferring group hierarchies
When it became clear that there would be no consensus on the hierarchy implementation, @cliffhall suggested that we defer group hierarchies to a follow-on SEP. The reasoning being that it has already taken up quite a bit of time in our meetings and we still don't have consensus about the approach. Meanwhile we do have consensus about the new primitive (sans
parent) and why groups would be a worthwhile addition to the protocol. It would be a shame if we wasted more time on this aspect and the whole concept of Groups as a new primitive were to be shot down when reviewed by the core maintainers.Everyone agreed, this would be a good way to resolve the current logjam and get closer to an SEP. @scottslewis agreed to revise his draft to remove the hierarchy support.
Beta Was this translation helpful? Give feedback.
All reactions