Skip to content

Commit 6134626

Browse files
committed
Add "A primitive's groups list as an array of Group instances not names" bullet to the Alternatives Considered section
1 parent 45bc352 commit 6134626

1 file changed

Lines changed: 4 additions & 2 deletions

File tree

seps/2084-primitive-groups.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -117,8 +117,6 @@ By listing a primitive's groups in a reserved `_meta` property, we ensure backwa
117117
},
118118
```
119119

120-
**Note:** The groups property is an array of strings representing group names, not group references. Since groups can be hierarchical, there would be unnecessary duplication of group definitions on the wire if passing references. Instead, a client can look up a group by name in the result of a `groups/list` result.
121-
122120
### Groups Discovery Method: groups/list
123121

124122
Request:
@@ -207,6 +205,10 @@ This specification proposal was selected for its ease of understanding since it
207205
This idea was discarded because it could lead to backward compatibility issues. For instance, if a server returned a tool, resource, etc, with this property to an older client which validated it against a strict schema that did not contain this property, it would most likely cause an error.
208206
Since this proposal spans all primitives, such a compatibility failure would be catastrophic.
209207

208+
209+
- **A primitive's groups list as an array of Group instances not names:** A variation of the proposed specification, but the schema would reference the Groups definition instead of being a string (group name). This means that full Group instances would appear in the primitive's group list, significantly increasing the token count when passed to an LLM without modification. Also, beacuse groups can be hierarchical, every child of a given group would carry a duplicate of the parent instance. There was discussion of mitigating the duplication on the line using libraries that perform a marshalling on send/receive, replacing the parent with a pointer to a single copy of the parent instance. This appeared to be unnecessary effort for no clear benefit, when a client can easily look up a group by name in the `groups/list` result.
210+
211+
210212
- **Groups as MCP Resources instead of new primitive:** A completely separate proposal where the group metadata is declared in MCP resources with a specific schema and mimeType, referenced by their URIs, e.g., `mcp://groups/{groupId}`. Servers MAY publish the group index at a URI which MUST be defined in the capabilities object during the server initialization. This proposal could reduce spec changes and implementation effort significantly, but it was not considered as intuitive.
211213

212214
## Security Implications

0 commit comments

Comments
 (0)